Re: [PATCH] bisect: print abbrev sha1 for first bad commit
From: Christian Couder <hidden>
Date: 2016-06-15 23:04:44
On Tue, May 12, 2015 at 7:11 PM, Junio C Hamano [off-list ref] wrote:
Christian Couder [off-list ref] writes:quoted
On Mon, May 11, 2015 at 6:54 PM, Junio C Hamano [off-list ref] wrote:quoted
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. ...quoted
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.