git bisect with temporary commits

* git bisect with temporary commits
@ 2015-12-14 16:37 Florian Bruhin
  2015-12-14 18:08 ` Andreas Schwab
  0 siblings, 1 reply; 9+ messages in thread
From: Florian Bruhin @ 2015-12-14 16:37 UTC (permalink / raw)
  To: git; +Cc: r.seitz

[-- Attachment #1: Type: text/plain, Size: 2251 bytes --]

Hi!

Today I bisected a bug which required cherry-picking an (unrelated)
compile fix later in the history so I could test the commits.

After testing a commit, I didn't reset to the commit before the
cherry-picked one, which seemed to work well, but doesn't in my minimal
example:

    $ git init
    $ echo 'good and does not compile' > file
    $ git add file && git commit -m 'good and does not compile'
    $ echo again >> file && git commit -am 'still good and does not compile'
    $ echo 'bad and compiles' > file && git commit -am 'bad and compiles'
    $ git log --oneline --decorate
    97f9214 (HEAD, master) bad and compiles
    981e109 still good and does not compile
    753ed25 good and does not compile

Now I start bisecting and cherry-pick the compile fix in master:

    $ git bisect start
    $ git bisect bad master
    $ git bisect good master~2  # 753ed25
    Bisecting: 0 revisions left to test after this (roughly 0 steps)
    [981e1093dae24b37189bcba2dd848b0c3388080c] still good and does not compile
    florian@ws042:~/tmp/bisect1$ git cherry-pick master
    [detached HEAD b49872b] bad and compiles
     Date: Mon Dec 14 17:26:51 2015 +0100
      1 file changed, 1 insertion(+), 2 deletions(-)

Now when trying to say it's good (and forgetting to remove the
temporary commits), I get this:

    $ git bisect good
    Bisecting: a merge base must be tested
    [981e1093dae24b37189bcba2dd848b0c3388080c] still good and does not compile

Is this intended behaviour? Shouldn't git either do a reset to the
commit we're currently bisecting, or warn the user as it was probably
unintended to add new commits?

Currently it seems bisect just treats the current HEAD as good, and
then the bisect algorithm tries to (I think) select a commit between
the currently bisected one and the (temporary) HEAD?

When I used it today, it actually seemed to work well until I hit an
*actual* merge base, and then it started to bisect something
unexpected, which got me a bit confused ;)

Florian

-- 
http://www.the-compiler.org | me@the-compiler.org (Mail/XMPP)
   GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc
         I love long mails! | http://email.is-not-s.ms/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread