Skip to contentSkip to conversation

Not understanding with git wants to copy one file to another

DISCUSSION Harry Putnam 3 participants 7 messages Aug 10, 2017 – Aug 14, 2017

lore
Share & tools
lore
#0 lore raw

I ran into a line in git commit ouput I had not see before

#copied: d0/etc/hosts -> misc/old-readerHOSTvcs-files/etc/hosts

So googling I learned that this might happen if git thinks the two files are the same.

I was pretty sure they were not the same so checked them>

<inside git repo>

diff d0/etc/host misc/old-readerHOSTvcs-files/etc/hosts

The output is a bit long but shows them being quite different.

Some 2 dozen or so lines that dramatically differ.

Here are two that are at least kind of similar but would never be seen as the same:

< 192.168.1.43 m2.local.lan m2 # 00-90-F5-A1-F9-E5

Quoted 1 line

192.168.1.43 m2.local.lan m2 # win 7

Not to mention they are quite different lines as well.

So what is going on and what should I be looking at?

#1 lore raw
Quoted 20 lines · Harry Putnam

I ran into a line in git commit ouput I had not see before

#copied: d0/etc/hosts -> misc/old-readerHOSTvcs-files/etc/hosts

So googling I learned that this might happen if git thinks the two files are the same.

I was pretty sure they were not the same so checked them>

<inside git repo>

diff d0/etc/host misc/old-readerHOSTvcs-files/etc/hosts

The output is a bit long but shows them being quite different.

Some 2 dozen or so lines that dramatically differ.

Here are two that are at least kind of similar but would never be seen as the same:

Quoted 6 lines

< 192.168.1.43 m2.local.lan m2 # 00-90-F5-A1-F9-E5

Quoted 1 line

192.168.1.43 m2.local.lan m2 # win 7

Not to mention they are quite different lines as well.

So what is going on and what should I be looking at?

The diff machinery has a threshold for when it assumes a copy/move of a file. (e.g. "A file is assumed copied when at least 55% of lines are equal")

https://git-scm.com/docs/git-diff

See -C and -M option.

git-status seems to use this machinery as well, but does not expose the options?

#2 lore raw
Quoted 1 line · Stefan Beller

On Thu, Aug 10, 2017 at 10:03 AM, Harry Putnam <[email protected]> wrote:

[...]

Quoted 5 lines · Harry
Quoted 5 lines

Here are two that are at least kind of similar but would never be seen as the same:

< 192.168.1.43 m2.local.lan m2 # 00-90-F5-A1-F9-E5

Quoted 1 line

192.168.1.43 m2.local.lan m2 # win 7

Stefan B replied:

Quoted 10 lines

The diff machinery has a threshold for when it assumes a copy/move of a file. (e.g. "A file is assumed copied when at least 55% of lines are equal")

https://git-scm.com/docs/git-diff

See -C and -M option.

git-status seems to use this machinery as well, but does not expose the options?

Well, now I'm even more confused. What actually happens? Is either file changed? Is only one file kept?

On the surface it sounds like complete anathema to what git is all about.

However, I know a tool this sophisticated is not doing something just outright stupid... so must be really missing the point here.

I get the way you can make -M stricter or not... but I didn't call git-diff to see that copy thing comeup.

I called git commit.

There must be some way to set stricter guidlines to calling things copies.

But then I must really not get it because it still seems almost silly to consider one file a copy of another if only 55% is the same.

What am I missing?

#3 lore raw
Quoted 31 lines · Harry Putnam
Quoted 1 line · Stefan Beller

On Thu, Aug 10, 2017 at 10:03 AM, Harry Putnam <[email protected]> wrote:

[...]

Quoted 5 lines · Harry
Quoted 5 lines

Here are two that are at least kind of similar but would never be seen as the same:

< 192.168.1.43 m2.local.lan m2 # 00-90-F5-A1-F9-E5

Quoted 1 line

192.168.1.43 m2.local.lan m2 # win 7

Stefan B replied:

Quoted 10 lines

The diff machinery has a threshold for when it assumes a copy/move of a file. (e.g. "A file is assumed copied when at least 55% of lines are equal")

https://git-scm.com/docs/git-diff

See -C and -M option.

git-status seems to use this machinery as well, but does not expose the options?

Well, now I'm even more confused. What actually happens? Is either file changed? Is only one file kept?

On the surface it sounds like complete anathema to what git is all about.

Quoted 7 lines

However, I know a tool this sophisticated is not doing something just outright stupid... so must be really missing the point here.

I get the way you can make -M stricter or not... but I didn't call git-diff to see that copy thing comeup.

I called git commit.

Ah. Sorry for confusing even more.
By pointing out the options for git-diff, I just wanted to point out that such a mechanism ("rename/copy detection") exists.

The output of git-status is similar to a dry run of git-commit, and apparently this detection is used there.

Quoted 3 lines

There must be some way to set stricter guidlines to calling things copies.

Well from Gits perspective it is really hard to tell if it was a copy, or if it was similar incidentally (because the format/content of these files happen to follow some strict guidelines).

The user could have moved/copied a file outside of Git (instead of git-mv, you'd use tools provided by your operating system to copy a file). Or the user could have written a file that is similar by chance.

However that doesn't really matter, as Git tracks the content, and not how the file evolved.

Consider the copy/move/rename detection as a heuristic, that wants to help the user, but may be mistaken.

Quoted 6 lines

But then I must really not get it because it still seems almost silly to consider one file a copy of another if only 55% is the same.

What am I missing?

https://www.reddit.com/r/git/comments/3ogkk1/beginner_disable_rename_detection/

"Rename detection is just GUI sugar".

#4 lore raw

Stefan Beller <[email protected]> writes:

[...]

Quoted 3 lines

Ah. Sorry for confusing even more.
By pointing out the options for git-diff, I just wanted to point out that such a mechanism ("rename/copy detection") exists.

[...]

Quoted 6 lines
Quoted 2 lines

What am I missing?

https://www.reddit.com/r/git/comments/3ogkk1/beginner_disable_rename_detection/

"Rename detection is just GUI sugar".

Thanks there is a nice full explanation at the cited url.

What is still a bit puzzling is that in that same commit, there are files that are true copies of each other, just in different locations, But nothing pops up about them in a git commit.

#5 lore raw
Quoted 17 lines · Harry Putnam

Stefan Beller <[email protected]> writes:

[...]

Quoted 3 lines

Ah. Sorry for confusing even more.
By pointing out the options for git-diff, I just wanted to point out that such a mechanism ("rename/copy detection") exists.

[...]

Quoted 5 lines
Quoted 2 lines

What am I missing?

https://www.reddit.com/r/git/comments/3ogkk1/beginner_disable_rename_detection/

Quoted 8 lines
Quoted 1 line

"Rename detection is just GUI sugar".

Thanks there is a nice full explanation at the cited url.

What is still a bit puzzling is that in that same commit, there are files that are true copies of each other, just in different locations, But nothing pops up about them in a git commit.

The heuristic to find the renames/copies only looks at modified files to be fast(, the assumption is that each commit only touches few files, but the project consists of a lot of files).

For that git-diff knows about '--find-copies-harder' that looks at all files even those not modified. This would point out the true copies, I would assume.

I don't think we'd want to include the '--find-copies-harder' flag to status or commit, as it may take some time in large projects.

#6 lore raw
Quoted 31 lines · Stefan Beller
Quoted 17 lines · Harry Putnam

Stefan Beller <[email protected]> writes:

[...]

Quoted 3 lines

Ah. Sorry for confusing even more.
By pointing out the options for git-diff, I just wanted to point out that such a mechanism ("rename/copy detection") exists.

[...]

Quoted 5 lines
Quoted 2 lines

What am I missing?

https://www.reddit.com/r/git/comments/3ogkk1/beginner_disable_rename_detection/

Quoted 8 lines
Quoted 1 line

"Rename detection is just GUI sugar".

Thanks there is a nice full explanation at the cited url.

What is still a bit puzzling is that in that same commit, there are files that are true copies of each other, just in different locations, But nothing pops up about them in a git commit.

The heuristic to find the renames/copies only looks at modified files to be fast(, the assumption is that each commit only touches few files, but the project consists of a lot of files).

Quoted 6 lines

For that git-diff knows about '--find-copies-harder' that looks at all files even those not modified. This would point out the true copies, I would assume.

I don't think we'd want to include the '--find-copies-harder' flag to status or commit, as it may take some time in large projects.

Yeah, thanks for helping in this discussion.