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