Re: [PATCH v4 0/1] receive-pack: optionally deny case clone refs

[Junio C Hamano <gitster@pobox.com>]

Ronnie Sahlberg <sahlberg@google.com> writes:

> It gets even more hairy :
> If the server has A/a and a/b and you clone it it becomes A/a and A/b
> locally. Then you push back to the server and you end up with three
> refs on the server:  A/a A/b and a/b.

That is part of the transition in deployment.  David who wants to
forbid A/a and a/b mixed in his project will surely correct the
situation at the server end so "somebody fetches A/a and a/b and
ends up with A/a and A/b" will not happen.  They will fetch A/a and
A/b.

If a user is with an older Git and he has his own a/c, fetching A/a
and A/b from a corrected central repository will still give the user
a/a and a/b, but then pushing it back will be forbidden.  The user's
repository needs to be fixed and installation of Git needs to be
updated to the version with an equivalent of David's "optionally
deny" feature implemented for the fetching side, so that the user
notices the local a/c is bad and not allowed within the context of
his project, deletes it and recreates it as A/c before he can fetch
A/a and A/b from the central repository.

I agree that the transition may be painful, but as long as the
desired semantics is "If you have A/a, you are not allowed to have
a/a or a/b", it cannot be avoided---in that sense, I view it as a
lower priority issue.

Having said that, it may indicate that the desired semantics above
may not be the optimal one.  Perhaps the flag might want to be "on
this platform, we cannot do case sensitive refs, so pretend as if
all refs are lowercase" instead.  I suspect that such a flag may
allow smoother transition than what has been proposed.

Underlying refs "A/a" and "a/b" can stay as they are in David's
central repository, but ref enumeration with the flag enabled will
return a/a and a/b, and these are the names that will be fetched by
the users.  If the user had an existing A/c, then fetching these
will still create A/a and A/b locally, but pushing them back will,
under that flag enabled, be turned into updates to a/a, a/b, and a/c
on the central server side with updated Git.

I dunno.