Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >> And in that spirit, I think the patch you replied with aims to go in >> the right direction, by providing the core functionality when in a >> repository while avoiding breaking such a script outside of one >> (though I do not understand it fully yet). > > Given that, is it safe for me to ignore this earlier one > >> For what it's worth, I don't agree with this repurposing of >> "check-ref-format --branch" at all. > > as reacting to the patch without reading what it does? Are you saying I should have ignored the commit message? Recording future plans via the commit message is part of what the patch does, after all. >> Junio C Hamano wrote: >>> (e.g. a wrapper to "git >>> clone" that wants to verify the name it is going to give to the "-b" >>> option), and a check desired in such a context is different from >>> (and is stricter than) feeding refs/heads/$name to the same command >>> without the "--branch" option. >> >> Can you say more about this example? E.g. why is this hypothetical >> wrapper unable to rely on "git clone -b"'s own error handling? > > If I have to guess what you meant, perhaps the Porcelain wanted to > diagnose bad parameter that would be rejected _before_ letting clone > spend cycles and possibly network bandwidth? > > But this was my way of rephrasing an earlier example you used while > objecting to Peff's change [...] > so my answer to the question in the message I am directly responding > to would be "You tell me." ;-) Hm. Does the example in https://public-inbox.org/git/20171017070808.plddffhzdobyekmo@xxxxxxxxxxxxxxxxxxxxxxxxx/ make it clearer? The goal of such a script is *not* error handling --- that is just a pleasant side-benefit. It is to be able to handle all branch specifiers from the user (and even a default branch that is not from the user) uniformly. Thanks, Jonathan
