Re: Basename matching during rename/copy detection

Johannes Schindelin [off-list ref] writes:

Have you checked the files? They are all some blobs in the test scripts. 

Yes, but how does it make any difference? You still want git to manage
them properly, don't you?

-- 
Matthieu

Hi,

On Thu, 21 Jun 2007, Matthieu Moy wrote:

Johannes Schindelin [off-list ref] writes:

quoted

Have you checked the files? They are all some blobs in the test scripts. 

Yes, but how does it make any difference? You still want git to manage
them properly, don't you?

Yes. And Git explicitely allows what I call stupid. And yes, those 
_identical_ files in the test suit should probably all be folded into 
single files, and the places where they are used should reference _that_ 
single instance.

Ciao,
Dscho

Johannes Schindelin wrote:

Yes. And Git explicitely allows what I call stupid. And yes, those 
_identical_ files in the test suit should probably all be folded into 
single files, and the places where they are used should reference _that_ 
single instance.
  

Two files that are identical in the current revision have not 
necessarily been identical from the beginning. Doing what you suggest 
will cause you to lose the history of all but one of those files.

Files can absolutely become identical in the real world. I know that for 
a fact because it happened to me just this week (see my "Directory 
renames" message from a few days ago.) Are you seriously suggesting that 
every time I unpack an update from a third party, I should go through it 
and see if they have changed any files such that the contents now match 
another file in my repository, and if so, I should remove all but one of 
the copies from my repository and have a build system create it instead? 
Then undo that work when I unpack another update and the files are no 
longer identical?

Well, no, I know you're not suggesting that, but it's the logical 
conclusion of the "it's stupid to ever have duplicate files" philosophy. 
While that approach certainly makes life easier for the version control 
system, it doesn't exactly make life easier for the *developer*, which 
is kind of the whole point of why we're here.

-Steve

Hi,

On Thu, 21 Jun 2007, Steven Grimm wrote:

Johannes Schindelin wrote:

quoted

Yes. And Git explicitely allows what I call stupid. And yes, those
_identical_ files in the test suit should probably all be folded into
single files, and the places where they are used should reference _that_
single instance.
  

Two files that are identical in the current revision have not necessarily
been identical from the beginning. Doing what you suggest will cause you to
lose the history of all but one of those files.

Files can absolutely become identical in the real world. I know that for a
fact because it happened to me just this week (see my "Directory renames"
message from a few days ago.)

No, that message did not convince me. It was way too short on the side of 
facts.

And no, I do not think that two unrelated files can get exactly the same 
content.

Be that as may, even _if_ there were such a case, I'd still try to reuse 
the same file in the working directory. Just because Git can deal 
efficiently with millions of identical files does not mean that a working 
directory can, or worse, human developers.

Ciao,
Dscho

Johannes Schindelin wrote:

No, that message did not convince me. It was way too short on the side of 
facts.
  

Short of posting multiple historical versions of the third-party source 
code in question, I'm not sure what I can do to convince you. And I'd 
rather not violate the license agreement on that code. I would have 
thought, though, that the fact that I supplied a detailed, reproducible 
test case with obviously broken behavior would itself have been pretty 
convincing.

The fact that not all projects contain any short files, or any files 
whose contents have ever been identical, does not cause git's behavior 
in that test case to be correct. "It's broken and unfixable" is one 
thing; "It's broken and we don't care" is another; and "It's broken and 
we care but it's not at the top of anyone's priority list to fix" is 
something else again. All of those are fine, but "If it's broken, you 
are stupid" and "If it's broken, it's a sign your project isn't real" 
are not.

Or, to take another tack on this entirely, it is not the proper function 
of a version control system to dictate the contents of the projects 
under its control. It should take whatever we humans throw at it and 
reproduce those contents faithfully with coherent, non-jumbled history. 
It should do so even if what we're throwing at it is completely stupid.

By the way, I'll toss out one more example of legitimate duplicate 
files, though admittedly one where you might not care so much about 
history jumbling: if you have a project that makes use of two GPL 
libraries or utilities whose source you want to keep locally, e.g. 
because you are making local modifications, you will have two copies of 
the GNU "COPYING" file. Neither one produced by a build system (or at 
least, not by *your* build system) and you are not permitted by the 
terms of the GPL to publish a copy of either piece of software without a 
verbatim copy of its license -- it says so right in section 1 of the GPL 
(the "keep intact" wording.) Removing one of those copies and expecting 
a build system to reconstruct it after someone clones your repository 
would arguably be a violation of the GPL.

-Steve