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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jul 8, 2014 at 11:48 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> 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.

ACK.

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

regards
ronnie sahlberg
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]