On Tue, May 12, 2015 at 1:43 PM, Christian Couder <christian.couder@xxxxxxxxx> wrote: > On Tue, May 12, 2015 at 7:11 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Christian Couder <christian.couder@xxxxxxxxx> writes: >> >>> On Mon, May 11, 2015 at 6:54 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>> >>>> To be bluntly honest, I think the current one is sufficient as a >>>> good-enough default. The first thing I would do after seeing that >>>> message is to either "git checkout <commit-object-name>" or "git >>>> show <commit-object-name>", and the current full 40-hex output gives >>>> me an easier mouse-double-click target than the proposed abbreviated >>>> one, so in that sense the original proposal may even be a usability >>>> regression. >>> >>> Yeah, it might also be a regression if some users have scripts that >>> depend on the current behavior. >>> ... >>>> It is tempting to say that the output can be eliminated by always >>>> checking out the first-bad-commit (i.e. only when the last answer >>>> that led to the first-bad decision was "good", do a "git checkout" >>>> of that bad commit), but in a project where a branch switching is >>>> not instantaneous, that might be problematic (unless the first step >>>> the user would have done is to check it out anyway, of course). >>> >>> Yeah, and speaking of regressions, elimiting the output might be a >>> more serious regression. >> >> I am getting somewhat annoyed by this line of thought. >> >> Who said bisect output is meant to be parseable and be read by >> scripts in the first place? If that were the case, we wouldn't be >> having this discussion thread in the first place. > > Well "git bisect run" is all about automating bisecting and we know > that some people have been using it for a long time. > > See for example this message from 2007: > > http://lkml.iu.edu/hypermail/linux/kernel/0711.1/1443.html > > where there is: > > "Today we can autonomouly > bisect build bugs via a simple shell command around "git-bisect run", > without any human interaction!" > > So it is reasonnable to wonder if some scripts might be parsing > the output. This reasoning sounds to me, that the lack of a plumbing counterpart to bisect(porcelain) made it a de facto plumbing command, which is unfortunate for discussing changes like these. So how to proceed here? * one way would be to ignore the scripts out there, "because it's porcelain, so nobody sane would have written a script using it anyway" but this attitude is not well perceived in the community I'd assume. * declare the current bisect command a plumbing layer command and introduce a new porcelain command, how about "git find" which can address a variety of issues such as also having the capability to find a fix instead of just regressions (make good/bad markers less confusing) Depending on the implementation this may be a lot of work -> copy/paste is fast and involves less work now, but more in the future -> or having a new plumbing-bisect header making calls from the porcelain to the plumbing bisect tool. -- 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