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