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:
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
From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:10
Linus Torvalds [off-list ref] 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.
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:42:10
On Tue, 1 Nov 2005, Junio C Hamano wrote:
Linus Torvalds [off-list ref] writes:
quoted
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*
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:10
Dear diary, on Tue, Nov 01, 2005 at 11:03:26PM CET, I got a letter
where Daniel Barkalow [off-list ref] told me that...
On Tue, 1 Nov 2005, Junio C Hamano wrote:
quoted
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.