On Tue, Jul 8, 2014 at 11:48 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Michael Haggerty <mhag...@alum.mit.edu> 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.
Ok, 01-19 is as good split as any.
If you merge just the 01-19 part of this series I will address
Michael's concerns and repost patches 20-48 as a separate series.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html