git-pull - strange (copy/rename) messages ?!

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

On Tue, 1 Nov 2005, Duncan Mac Leod wrote:

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:

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

Linus Torvalds <torvalds@osdl.org> writes:

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.

On Tue, 1 Nov 2005, Junio C Hamano wrote:

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*

Dear diary, on Tue, Nov 01, 2005 at 11:03:26PM CET, I got a letter where Daniel Barkalow <barkalow@iabervon.org> told me that...

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'.

Daniel Barkalow <barkalow@iabervon.org> writes:

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?

Dear diary, on Wed, Nov 02, 2005 at 12:24:32AM CET, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

In case of my proposal, you get the mv and cp as usual, since there are no multiple rename candidates for A.

Petr Baudis <pasky@suse.cz> writes:

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 ;-).

On Tue, 1 Nov 2005, Junio C Hamano wrote:

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*