# git-pull - strange (copy/rename) messages ?! 9 messages from 2005-11-01 to 2005-11-02. Participants: Duncan Mac Leod, Linus Torvalds, Junio C Hamano, Daniel Barkalow, Petr Baudis. Thread: https://gitlist.dev/t/2290 ## Duncan Mac Leod, 2005-11-01 15:40 Subject: git-pull - strange (copy/rename) messages ?! Message-ID: <43678C73.1080601@excelsior-online.org> URL: https://gitlist.dev/e/43678C73.1080601%40excelsior-online.org ``` One Team-Member of our dev.-team has deleted one file called Graphics/PaletteGroups.cs in our shared git repository. As I updated my working dir with git-pull I noticed some strange messages... What do these many copy and rename messages below the summary '14 files changed, 933 insertions(+), 263 deletions(-)' mean ???? Updating from f0df62e7b60c468852d4617505876515f9b305d7 to 8c18245869a9447329dedb4a4cd59d103ee6dbfe. Fast forward AssemblyInfo.cs | 2 BaseObjects/Modules.cs | 235 ++++++++ Graphics/PaletteCategories.cs | 12 Plot/Dialogs/Dialog.cs | 12 Plot/Dialogs/DialogEntry.cs | 12 Plot/Dialogs/DialogSection.cs | 14 Plot/Journals/Journal.cs | 12 Plot/Journals/JournalEntry.cs | 12 Plot/Journals/JournalSection.cs | 14 Runtime/CompilerServices/eScriptCompiler.cs | 12 Runtime/Scripting/Script.cs | 12 Runtime/Scripting/ScriptLibrary.cs | 14 doc/excelsior_corelib.xml | 784 ++++++++++++++++++++------- excelsior_corelib.csproj | 49 ++ 14 files changed, 933 insertions(+), 263 deletions(-) copy Graphics/{PaletteGroups.cs => PaletteCategories.cs} (80%) copy Graphics/PaletteGroups.cs => Plot/Dialogs/Dialog.cs (75%) copy Graphics/PaletteGroups.cs => Plot/Dialogs/DialogEntry.cs (74%) copy Graphics/PaletteGroups.cs => Plot/Dialogs/DialogSection.cs (64%) copy Graphics/PaletteGroups.cs => Plot/Journals/Journal.cs (75%) copy Graphics/PaletteGroups.cs => Plot/Journals/JournalEntry.cs (73%) copy Graphics/PaletteGroups.cs => Plot/Journals/JournalSection.cs (64%) copy Graphics/PaletteGroups.cs => Runtime/CompilerServices/eScriptCompiler.cs (74%) copy Graphics/PaletteGroups.cs => Runtime/Scripting/Script.cs (75%) rename Graphics/PaletteGroups.cs => Runtime/Scripting/ScriptLibrary.cs (64%) thx in advance, duncan ``` ## Linus Torvalds, 2005-11-01 16:10 Subject: Re: git-pull - strange (copy/rename) messages ?! Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0511010801370.27915%40g5.osdl.org In-Reply-To: <43678C73.1080601@excelsior-online.org> ``` On Tue, 1 Nov 2005, Duncan Mac Leod wrote: > > One Team-Member of our dev.-team has deleted one file called > Graphics/PaletteGroups.cs in our shared git repository. > > As I updated my working dir with git-pull I noticed some strange messages... > > What do these many copy and rename messages below the summary '14 files > changed, 933 insertions(+), 263 deletions(-)' mean ???? First off, you should realize that whenever git says "copy" or "rename", it never actually tracked the data at that level. git itself never did a copy or rename operation at all, it just tracked your data contents. However, the normal "git pull" will show purely for your edification what git thinks the other end did to get to that data content. And it does so with copy and rename detection enabled, so in this case it says: > copy Graphics/{PaletteGroups.cs => PaletteCategories.cs} (80%) > copy Graphics/PaletteGroups.cs => Plot/Dialogs/Dialog.cs (75%) > copy Graphics/PaletteGroups.cs => Plot/Dialogs/DialogEntry.cs (74%) > copy Graphics/PaletteGroups.cs => Plot/Dialogs/DialogSection.cs (64%) > copy Graphics/PaletteGroups.cs => Plot/Journals/Journal.cs (75%) > copy Graphics/PaletteGroups.cs => Plot/Journals/JournalEntry.cs (73%) > copy Graphics/PaletteGroups.cs => Plot/Journals/JournalSection.cs (64%) > copy Graphics/PaletteGroups.cs => Runtime/CompilerServices/eScriptCompiler.cs (74%) > copy Graphics/PaletteGroups.cs => Runtime/Scripting/Script.cs (75%) > rename Graphics/PaletteGroups.cs => Runtime/Scripting/ScriptLibrary.cs (64%) Which means that git notices that there are a number of new files, and the new files all bear a striking resemblance to one file that was deleted. So it tells you that the new files are probably copies of the old one (with one final "rename", since the old file doesn't actually exist any more). Which may or may not be true, of course. But even if it's not "true", it's still interesting information - it is a totally objective "those new files look like the old file" thing. In other words, it tells you something true about the file contents. To some degree it would be much more interesting to have "--find-copies-harder" enabled (which it isn't), which gives better copy information for new files (it also looks at _unchanged_ old files). However, that's prohibitively expensive for big projects, so it's not on by default. Btw, Junio, I thought "git pull" was only supposed to do rename detection, not copy detection. Linus ``` ## Junio C Hamano, 2005-11-01 17:43 Subject: Re: git-pull - strange (copy/rename) messages ?! Message-ID: <7vbr149sbs.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vbr149sbs.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Linus Torvalds writes: > Btw, Junio, I thought "git pull" was only supposed to do rename > detection, not copy detection. Sorry, but what do you mean by "only rename detection but not copy detection" in this case? When you have "ce A B; ce A C; ce A D;... ; mv A Z", (ce is like cp but "copy+edit") where B-Z are all new files and A disappears from the result, trying to detect renames would end up detecting copies without extra processing; B through Z are rename destination candidates, and A is a rename source candidate (there may be others), and it turns out that B-Z all look like A. Would it be easier to read if we say A was renamed to B, and A was renamed to C, and A was renamed to D, ...? I think the current output is easier to understand than that. B-Y gets labelled as copy of A and Z gets labelled as rename. ``` ## Daniel Barkalow, 2005-11-01 22:03 Subject: Re: git-pull - strange (copy/rename) messages ?! Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0511011646070.25300%40iabervon.org In-Reply-To: <7vbr149sbs.fsf@assigned-by-dhcp.cox.net> ``` On Tue, 1 Nov 2005, Junio C Hamano wrote: > Linus Torvalds writes: > > > Btw, Junio, I thought "git pull" was only supposed to do rename > > detection, not copy detection. > > Sorry, but what do you mean by "only rename detection but not > copy detection" in this case? > > When you have "ce A B; ce A C; ce A D;... ; mv A Z", (ce is like > cp but "copy+edit") where B-Z are all new files and A disappears > from the result, trying to detect renames would end up detecting > copies without extra processing; B through Z are rename > destination candidates, and A is a rename source candidate > (there may be others), and it turns out that B-Z all look like > A. > > Would it be easier to read if we say A was renamed to B, and A > was renamed to C, and A was renamed to D, ...? I think the > current output is easier to understand than that. B-Y gets > labelled as copy of A and Z gets labelled as rename. I think it's more confusing for the system to report Z differently from other things, because there's nothing special about what it found, except that Z happens to be last. I think it would be easiest to read as: Rename A => B (80%) C (85%) D (75%) ... Z (90%) (Although I don't know if the results come out of the system sorted that way; obviously, if there are different removed things, mixing them together would be ambiguous in this format) -Daniel *This .sig left intentionally blank* ``` ## Petr Baudis, 2005-11-01 23:06 Subject: Re: git-pull - strange (copy/rename) messages ?! Message-ID: <20051101230635.GA1431@pasky.or.cz> URL: https://gitlist.dev/e/20051101230635.GA1431%40pasky.or.cz In-Reply-To: ``` Dear diary, on Tue, Nov 01, 2005 at 11:03:26PM CET, I got a letter where Daniel Barkalow told me that... > On Tue, 1 Nov 2005, Junio C Hamano wrote: > > Would it be easier to read if we say A was renamed to B, and A > > was renamed to C, and A was renamed to D, ...? I think the > > current output is easier to understand than that. B-Y gets > > labelled as copy of A and Z gets labelled as rename. > > I think it's more confusing for the system to report Z differently from > other things, because there's nothing special about what it found, except > that Z happens to be last. I agree, but I'd prefer it to be labelled as a copy+remove instead of a rename in case it is ambiguous. Just a simple rule - if the file was removed and you get multiple rename candidates, mark all of them as 'copy'. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## Junio C Hamano, 2005-11-01 23:24 Subject: Re: git-pull - strange (copy/rename) messages ?! Message-ID: <7vu0ew6jf3.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vu0ew6jf3.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Daniel Barkalow writes: > I think it's more confusing for the system to report Z differently from > other things, because there's nothing special about what it found, except > that Z happens to be last. What would we get for a simple "mv A B and nothing else" case if we follow your proposal and Pasky's? What about "cp A B and nothing else" case? ``` ## Petr Baudis, 2005-11-01 23:36 Subject: Re: git-pull - strange (copy/rename) messages ?! Message-ID: <20051101233647.GC1431@pasky.or.cz> URL: https://gitlist.dev/e/20051101233647.GC1431%40pasky.or.cz In-Reply-To: <7vu0ew6jf3.fsf@assigned-by-dhcp.cox.net> ``` Dear diary, on Wed, Nov 02, 2005 at 12:24:32AM CET, I got a letter where Junio C Hamano told me that... > Daniel Barkalow writes: > > > I think it's more confusing for the system to report Z differently from > > other things, because there's nothing special about what it found, except > > that Z happens to be last. > > What would we get for a simple "mv A B and nothing else" case if > we follow your proposal and Pasky's? What about "cp A B and > nothing else" case? In case of my proposal, you get the mv and cp as usual, since there are no multiple rename candidates for A. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't. ``` ## Daniel Barkalow, 2005-11-01 23:39 Subject: Re: git-pull - strange (copy/rename) messages ?! Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.64.0511011834050.25300%40iabervon.org In-Reply-To: <7vu0ew6jf3.fsf@assigned-by-dhcp.cox.net> ``` On Tue, 1 Nov 2005, Junio C Hamano wrote: > Daniel Barkalow writes: > > > I think it's more confusing for the system to report Z differently from > > other things, because there's nothing special about what it found, except > > that Z happens to be last. > > What would we get for a simple "mv A B and nothing else" case if > we follow your proposal and Pasky's? What about "cp A B and > nothing else" case? My suggestion for "mv A B" would be: Rename A => B (n%) Same as the current thing, except with a line break and indentation before the arrow. For "cp A B": Copy A => B (n%) I think the only difference should be the line with "A" on it, and the difference should only depend on whether A still exists. -Daniel *This .sig left intentionally blank* ``` ## Junio C Hamano, 2005-11-02 00:35 Subject: Re: git-pull - strange (copy/rename) messages ?! Message-ID: <7v8xw751kc.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v8xw751kc.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20051101233647.GC1431@pasky.or.cz> ``` Petr Baudis writes: > In case of my proposal, you get the mv and cp as usual, since there are > no multiple rename candidates for A. I think showing things the Pasky way may be the easiest to understand for this particular case and for the simplest case. The original one would become something like this: copy Graphics/{PaletteGroups.cs => PaletteCategories.cs} (80%) copy Graphics/PaletteGroups.cs => Plot/Dialogs/Dialog.cs (75%) ... copy Graphics/PaletteGroups.cs => Runtime/Scripting/Script.cs (75%) copy Graphics/PaletteGroups.cs => Runtime/Scripting/ScriptLibrary.cs (64%) delete Graphics/PaletteGroups.cs That is, if you are interested in Plot/Dialogs/Dialog.cs, you know where it came from. If you are interested in Graphics/PaletteGroups.cs, you can tell it disappeared. That is, you need to look at only one line to know what funny things happened to one path. However, I suspect that this requires moderate amount of surgery on the diff output routine (the last stage). I have a feeling that git-apply may also need to be told about it when applying such a patch. The biggest drawback doing things the Pasky way would be that the textual diff would need to contain the whole file removal of Graphics/PaletteGroups.cs. Do we want to bloat the output for this? I personally do not think it is worth it. We could cheat by only changing the git-apply --summary side, to implement either Pasky or Daniel proposal, but that would make output from 'git-diff -p | git-apply --summary' and 'git-diff -r --name-status -r' inconsistent, which I'd rather avoid. I think all three (i.e. current, Pasky, Daniel) logically make sense, and it is to a certain degree just a matter of personal taste. Let's try doing nothing for now and see if people get used to it ;-). ```