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

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

[Duncan Mac Leod]

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

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

[Linus Torvalds]

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

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

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> 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.

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

[Daniel Barkalow]

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

> Linus Torvalds <torvalds@osdl.org> 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*

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

[Petr Baudis]

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

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

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> 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?

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

[Petr Baudis]

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...
> Daniel Barkalow <barkalow@iabervon.org> 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.

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

[Daniel Barkalow]

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

> Daniel Barkalow <barkalow@iabervon.org> 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*

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

[Junio C Hamano]

Petr Baudis <pasky@suse.cz> 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 ;-).