From: Junio C Hamano Date: Wed, 02 Nov 2005 00:35:31 GMT Subject: Re: git-pull - strange (copy/rename) messages ?! Message-ID: <7v8xw751kc.fsf@assigned-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 ;-).