Re: RFD: Handling case-colliding filenames on case-insensitive filesystems

[Johan Herland <johan@herland.net>]

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, <johan@herland.net>
www.herland.net