Subject: Re: [PATCH v20 00/48] Use ref transactions

From: Junio C Hamano <[email-masked]>
Date: Tue, 08 Jul 2014 11:48:06 -0700

Michael Haggerty <[email-masked]> writes:

> Patches 01-19 -- ACK mhagger
> Patches 20-42 -- I sent various comments, small to large, concerning
> these patches
> Patch 43 -- Needs more justification if it is to be acceptable
> Patch 44 -- Depends on 43
> Patches 45-48 -- I didn't quite get to these, but...
>
> Perhaps it would be more appropriate for the rules about reference name
> conflicts to be enforced by the backend, since it is the limitations of
> the current backend that impose the restrictions.  Would that make sense?
>
> On the other hand, removing the restrictions isn't simply a matter of
> picking a different backend, because all Git repositories have to be
> able to interact with each other.

I'd say that "if you have foo/bar you cannot have foo" may have
started as an implementation limitation, but the interoperability
requirement with existing versions of Git and with existing
repositories makes it necessary to enforce it the same way as other
rules such as "you cannot have double-dots in name, e.g. foo..bar"
or "no branches whose name begins with a dash", neither of which
comes from any filesystem issues.  That a rule can be loosened with
one new backend does not at all mean it is a good idea to loosen it
"because we can" in the first place.

> I think it would be good to try to merge the first part of this patch
> series to lock in some progress while we continue iterating on the
> remainder.  I'm satisfied that it is all going in the right direction
> and I am thankful to Ronnie for pushing it forward.  But handling
> 48-patch series is very daunting and I would welcome a split.
>
> I'm not sure whether patches 01-19 are necessarily the right split
> between merge-now/iterate-more; it is more or less an accident that I
> stopped after patch 19 on an earlier review.  Maybe Ronnie could propose
> a logical subset of the commits as being ready to be merged to next in
> the nearish term?

Yeah, thanks for going through this, and I agree that we would be
better off merging the earlier part first.