Re: Basename matching during rename/copy detection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux