Thanks even if that's what scared me :)
The draw is very simple comparing to the reality (much more merge points) and
rebase will require lot of conflicts resolutions but now I'm sure that's what I
have to do.
Grégory
Johannes Sixt wrote:
Grégory Romé schrieb:
Thanks Santi but I have a problem, due to the fact that the commit which
has an impact on my code is in origin/master or first-origin/master
When bisect checkout a commit from those branch I have none of my own
modifications... So I can' test if my code is good or bad excepted if I
can merge my commits in the bisect branch...
ᐁ
first-origin/master *---A---------B----------------o------C-
\ \ \
origin/master ----------B'----------U-----------C'-
\ \ \
master ------------U'----------C''-
C" is the commit that merges upstream changes into your changes. You are
saying that your changes alone (before the merge) are good, and that
upstream before the merge is also good (since it doesn't contain your
changes, it is good by definition, more or less). That indeed means that
the merge commit is the first bad one; i.e., this is exactly the situation
that the user manual describes.
You should do:
$ git checkout -b tmp master # master is at C"
$ git rebase origin/master
$ git bisect start tmp orgin/master
That is, you rebuild your history on top of origin/master in a linear
fashion. (If you had merge conflicts in U', then you will see them again.)
Then you bisect the linearized history. This will point you to the bad
commit and you will understand what is going wrong.
With this new knowledge, go back to master (C") and fix the problem.
-- Hannes
--
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