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

From: Johan Herland <johan@herland.net>
Date: Feb 24, 2011, 00:58 UTC
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"?

Show 8 quoted lines

>  - 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