On Jan 17, 2011, at 2:38 AM, Christian Couder <christian.couder@xxxxxxxxx
> wrote:
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.
Well that's amazing to me. How on Earth fo you manage stuff?
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>".
Yes, of course. :)
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.
Can you alias "git bisect stop", or would you have to alias "git
bisect-stop"?
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
I don't understand how this can only be one way? Isn't this
symmetric? In other words, how is it different from
A-B-C-D-E <-- dev
\F-G <-- master
as far as bisect is concerned? Or maybe I am not entirely clear on
what you are saying.
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.
This would be an acceptable solution to me (--reverse with asking).
Aaron Meurer
--
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