On Mon, May 11, 2015 at 09:54:15AM -0700, Junio C Hamano wrote: > Christian Couder <christian.couder@xxxxxxxxx> writes: > > > On Mon, May 11, 2015 at 6:33 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> Jeff King <peff@xxxxxxxx> writes: > >> > >>> I'd argue for simply never showing the diff (dropping the "opt.diff = 1" > >>> line from bisect.c:show_diff_tree), but that is mostly my personal > >>> opinion. > >> > >> Yeah, I think that is sensible. It may even be OK to just give a > >> "log --oneline". > > > > Or maybe we could let the user configure the diff options or even the > > command used when the first bad commit is found? > > That is a separate discussion. I do not mind but I doubt many > people would use it (I was tempted to say "doubt anybody would", but > then was reminded how many people use Git, and toned it down), as > long as we have a good default. And I thought that this discussion > was about coming up with a good-enough default. agreed > 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. I think printing the full 40 chars once is reasonable, but twice in 2 lines seems a bit excessive. I was thinking of changing the format to be the first bad commit is $(git log -1 <bad sha1>) > 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). Well, if you just finished bisecting you are probably on a commit close to the first bad one so it probably will be fast. However I don't really like that idea because what I generally want to do is read the patch so having the hash printed so I can copy it and run git show -p $hash or something is nice. Though I guess if the first bad commit is checked out you can just skip the copy paste and use HEAD. Trev -- 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