From: Johan Herland Date: Thu, 24 Feb 2011 00:58:24 GMT Subject: Re: RFD: Handling case-colliding filenames on case-insensitive filesystems Message-ID: <201102240158.24363.johan@herland.net> In-Reply-To: <7vfwre8sax.fsf@alter.siamese.dyndns.org> On Wednesday 23 February 2011, Junio C Hamano wrote: > 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 Wouldn't that be a regression from the current state (where the poor user in a case-insensitive worktree can at least "git rm" the offending files, and keep working without assistance from a case-sensitive worktree)? What about giving a warning on checkout, instead, explaining the problem, and advising that - for now - the user can remove the offending files with "git rm"? > - 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 support making this a per-project configuration that will trigger at tree- creation (i.e. commit) time. I would even argue that the default should be to warn about (though maybe not refuse) case-colliding filenames, since they are either (a) directly harmful for cross-platform projects, or (b) probably unwanted in most projects anyway. Having a per-project configuration sure beats trying to solve the problem in a hook script (using "pre-commit" introduces the logistical problem making sure everybody installs/enables the hook, whereas using "update" requires (precious) server runtime, triggers too late in the developer's workflow (forcing developer to amend/rebase), and probably confuses newbie developers as well). > 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. Agreed. ...Johan -- Johan Herland, www.herland.net