From 9c67d56e5b8c7b33f2c8660b4e3d85841f083e60 Mon Sep 17 00:00:00 2001 From: Mattias Andrée Date: Thu, 19 Sep 2013 16:04:55 +0200 Subject: try again MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Mattias Andrée --- using-git.texinfo | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) (limited to 'using-git.texinfo') diff --git a/using-git.texinfo b/using-git.texinfo index 9f19087..9fef442 100644 --- a/using-git.texinfo +++ b/using-git.texinfo @@ -835,6 +835,46 @@ file or stage the removal of it if it as been removed from the working directory. +Git trackes file renames implicitly, +so @command{git mv} is same thing as: + +@example +cp FILE NEW_NAME +git rm FILE +git add NEW_NAME +@end example + +This approach is flexible, but +it has some caveats. GNU Arch +keeps track files by giving +them unique identifier, this +solves the problem were you in +git can get an evil merge if +the pulled branch does not have +any common commits@footnote{Identified +with commit ID, not snapshots, +which reflects on more than the +file content.}, for example, +the pull patch was not made from +a clone repository or did not +contain commit history. Other +systems tracks renames explicitly +when a rename command is made, +that is worst because than mean +that you need to use the rename +commit, and evil merges are even +more probable. A problem will +merging when where is a rename +is that the changes are automerged +instead of creating a conflict, +you can get evil merges where +the content of the resulting file +refers to the files old name, +naturally this is still a problem +if another file depending on +the renamed file is edited in +parallel. + If you want to know the file staging difference between the index and working directory -- cgit v1.2.3-70-g09d2