On Mon, May 11, 2015 at 11:17 AM, Trevor Saunders <tbsaunde@xxxxxxxxxxxx> wrote:
> 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.
Only if you are operating within your local repository only. If you want
to check a build bot or another database for continuous builds or anything
outside your local repository you need the hash and not HEAD.
So I'd think
the first bad commit is
$(git log -1 <bad sha1>)
is fine.
>
> 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