Hi,
On Sat, Jan 15, 2011 at 8:33 AM, Aaron S. Meurer <asmeurer@xxxxxxxxx> wrote:
> First off, do you guys have an issue tracker?
No, we don't. We use the mailing list.
> I asked on IRC, and someone told me that he didn't think you did, and to just post here. After searching your websites, as far as I can tell he was right, though this is amazing to me that you can handle a project like this without an issue tracker. If you guys really do, then sorry. I would rather post this there than here (though if you really do, please make it more findable!)
>
> I just noticed this error/bug:
>
> git checkout test
> git bisect start
> <do some bisecting>
> git branch -D test
> <finish bisecting>
> git bisect reset
>
> And it gives an error, because test has been deleted. This is in 1.7.3.5. Now, I looked through the log of the current master of git to see if anything has been done about this, and all I noticed was the commit 3bb8cf88247db5, which essentially improves the error message.
>
> Now, this is good, because it seemed to me above that I was stuck bisecting until I recreated the test branch. I did not realize the git bisect <commit> syntax until later.
You mean "git bisect reset <commit>".
> But this has brought me to bother you guys about something that has been bugging me for a while. I hate git bisect reset. 90% of the time I do not want to go back to where I started bisecting. I would much prefer to just have a git bisect stop command, which just stops the bisecting process, but leaves me where I am (like a shortcut to git bisect reset HEAD). This would be much more symmetric with git bisect start.
If more people want it, yeah, we can create such a shortcut. But you
can also use a git alias for that.
> While we are on the topic of bisecting, I have another issue. Can we remove the restriction that a "bad" commit come after a "good" commit? I'd say about 70% of the time I use bisect to find a commit that fixes a bug, not breaks it. Whenever this happens, I have to bend my mind over backwards to remind myself that the good behavior is really "bad" and the bad behavior is really "good". Is there a reason that git bisect can't just introspect from which comes earlier and which comes later to see which is "good" or "bad" (instead of just raising an error when they are in the "wrong" order)?
Yeah, many people find it difficult to reverse the meaning of "bad"
and "good" when looking for a fix. There were some suggestions at some
points to do something about it. Some of the suggestions were to use
some aliases for "good" and "bad", but there was no agreement. Other
suggestions had a patch attached but the patch was not good enough or
something.
Anyway, the restriction is that the "bad" commit cannot be an ancestor
of a "good" commit. But the "good" commits need not be all ancestors
of the "bad" commit. For example if you have a "master" branch and a
"dev" branch that was forked from the "master" branch at one point,
like that:
A-B-C-D-E <-- master
\F-G <-- dev
you can use one of the branch as "bad" and the other one as "good".
And that means that in this case we cannot automatically reverse the
meaning of "good" and "bad".
So if we ever implement a "--reverse" mode, I think that the best we
could do if we detect that a "bad" commit is an ancestor of a "good"
commit is to suggest the use of this "--reverse" mode. Or we could ask
and use this mode if the answer is yes.
Best regards,
Christian.
--
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