Shawn Pearce <spearce@xxxxxxxxxxx> writes: > On Wed, Feb 23, 2011 at 10:56, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Johan Herland <johan@xxxxxxxxxxx> writes: >> >>> Are there better suggestions on how to deal with this? >> >> Just from the top off my head, perhaps you can go to the same route as >> symbolic link support on filesystems that are not symlink-capable? > > I don't know how that helps here Junio. On those systems we write a > text file holding the symlink contents. That text file name is at > least still unique in the working directory. Heh, I probably should have more explicitly hinted that I was suggesting to rename, e.g. foo-1.txt, when checking out conflicting paths. I chose not to be precise because I knew readers were intelligent enough to read what's between my lines themselves ;-). Just like a text file that records link target is useless as a symlink, such a file would be useless for its original purpose (e.g. renaming xt_TCPMSS.c to xt_tcpmss-1.c to avoid a collision with xt_tcpmss.c would not help when its associated Makefile wants to build xt_TCPMSS.o and xt_tcpmss.o next to each other), just like your "treat everybody the same way and make that a directory" approach. I think two things are sensible to do, are relatively low hanging fruits, and are of low risk: - break checkout on such a tree on incapable filesystems; and - per project configuration (or attribute given to paths underneath a particular directory) that forbids or warns addition of case colliding paths to the index; enforce it at write_index() codepath; and - if we choose to just warn in the second item above instead of downright forbidding, barf in cache_tree_update() codepath when the per project configuration (or attribute) triggers upon case colliding paths, to prevent a commit from being made. I think "warn at add time, fail at write-tree time" is more preferrable, as it might be more convenient if you can add hello.c while you still have HELLO.c in the index as long as you do not forget to remove HELLO.c from the index before making your next commit. -- 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