Hi Junio, On Mon, 27 Nov 2017, Junio C Hamano wrote: > Jeff King <peff@xxxxxxxx> writes: > > > Again, maybe the bit above explains my viewpoint a bit more. I'm > > certainly sympathetic to the pain of upstreaming. > > > > I do disagree with the "no good reason" for this particular patch. > > > > Certainly you should feel free to present your hunches. I'd expect you > > to as part of the review (I'm pretty sure I even solicited your opinion > > when I sent the original patch). But I also think it's important for > > patches sent upstream to get thorough review (both for code and design). > > The patches having been in another fork (and thus presumably being > > stable) is one point in their favor, but I don't think it should trumps > > all other discussion. > > I haven't been following this subthread closely, but I agree. I > think your turning a narrow option that was only about status into > something that can be extended as a more general option resulted in > a better design overall. The --no-optional-locks feature is - hard to find, - in the current scenarios less desirable than a very concrete "do not write index.lock files in `git status`", - too simple to introduce to merit introducing it *before* a need for it arises that is larger than `git status --no-lock-index`, and you would still have to keep the latter because it is a very concrete and real use case that is unlikely to want to avoid other .lock files too. So while you two are happily on agreeing with one another, the reality is that this supposedly better design is nothing else than premature optimization. Ciao, Dscho
