Re: [PATCH 2/2] ignorecase: Fix git mv on insensitive filesystems

From: David Turner <dturner@twopensource.com>
Date: May 8, 2014, 20:40 UTC
Message-ID: <1399581623.11843.105.camel@stross>
In-Reply-To: <xmqqha502ghc.fsf@gitster.dls.corp.google.com>

On Thu, 2014-05-08 at 12:54 -0700, Junio C Hamano wrote:

Show 35 quoted lines

> dturner@twopensource.com writes:
> 
> > From: David Turner <dturner@twitter.com>
> >
> > Make it possible to change the case of a filename on a
> > case-insensitive filesystem using git mv.  Change git mv to allow
> > moves where the destination file exists if the destination file has
> > the same name as the source file ignoring case.
> >
> > Signed-off-by: David Turner <dturner@twitter.com>
> > ---
> >  builtin/mv.c                | 3 ++-
> >  t/t6039-merge-ignorecase.sh | 2 +-
> >  2 files changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/builtin/mv.c b/builtin/mv.c
> > index 45e57f3..f4d89d0 100644
> > --- a/builtin/mv.c
> > +++ b/builtin/mv.c
> > @@ -202,7 +202,8 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
> >  			}
> >  		} else if (cache_name_pos(src, length) < 0)
> >  			bad = _("not under version control");
> > -		else if (lstat(dst, &st) == 0) {
> > +		else if (lstat(dst, &st) == 0 &&
> > +			 (!ignore_case || strcasecmp(src, dst))) {
> 
> Hmm, I would find it easier to read if it were:
> 
> 		... if (lstat(dst, &st) == 0 &&
>                 	!(ignore_case && !strcasecmp(src, dst))) {
> 
> That is, "it is an error for dst to exist, unless we are on a case
> insensitive filesystem and src and dst refer to the same file.", but
> maybe it is just me.

I personally dislike the double negative. I also considered breaking it out into a little function with a self-documenting name -- does that sound better?

Show 6 quoted lines

> More importantly, what is the end-user visible effect of this
> change?  Is it fair to summarize it like this?
> 
>     On a case-insensitive filesystem, "mv hello.txt Hello.txt"
>     always trigger the "dst already exists" error, because both
>     names refer to the same file to MS-DOS, requiring the user to

                                     ^^^^^^
(I have not actually tested on Windows; I tested on the Mac since that's
what I have handy)

>     pass the "--force" option.  Allow it without "--force".

Yes.

Show 11 quoted lines

> Overwriting an existing file with "mv hello.txt Hello.txt" on a case
> sensitive filesystem *is* an unusual operation, and that is the
> reason why we require "--force" to make sure that the user means it.
> I have a slight suspicion that the same "mv hello.txt Hello.txt" on
> a case insensitive filesystem, where two names are known (to the end
> user of such a filesystem) to refer to the same path would equally
> be a very unusual thing to do, and such an operation may deserve a
> similar safety precaution to make sure that the user really meant to
> do so by requiring "--force".
> 
> So, I dunno.

The argument against --force is that git's behavior should not significantly differ between sensitive and insensitive filesystems (where possible). I do not see a case-changing rename as unusual on a case-insensitive filesystem; these filesystems typically preserve case, and a user might reasonably care about the case of a filename either for aesthetic reasons or for functionality on sensible filesystems (e.g. developers who work on Macs but deploy on GNU/Linux, as is quite common).

The Mac's interface itself provides conflicting evidence: on one hand, we might expect git mv to work like plain mv: nothing special is needed to do a case-changing mv). On the other hand, in the Finder, attempting a case-changing rename causes an error message (which there is no way to get around other than the two-rename dance). I read this as "ordinary users never intentionally change the case of files, but developers sometimes do", but that's not the only possible reading.

I myself am not actually a Mac user; I simply support a bunch of Mac users (which is where the merge bug came from). So I don't know what Mac users would prefer. Maybe there are some on the git mailing list?

I also have not tried on Windows. I put in an email to the one Windows-using friend I can think of to ask her to give Windows Explorer (or whatever it's called these days) a try. My guess (based on a quick Google search) would be is that it works without error, but I will send an update if I hear otherwise.