Martin Langhoff <martin.langhoff@gmail.com> writes:
Well, obviously you could resolve them ;-). But if you are
rebasing just to reduce trivial mini-merges, it might make more
sense to honestly record the merge if the rebase involves
conflict resolution. After all, the reason rebase got conflicts
is because the development trail by somebody else that has been
already committed to the shared "master" branch overlapped what
you were doing in your "master" branch, isn't it?
In your message you indicated that you use "format-patch" piped
to "am". I think that is a better approach than "rebase" these
days; the conflict can be handled easier with that approach, and
if you use "--3way" flag you do not even have to worry about
patches in your branch that is already there in the shared
"master" (your "origin") branch.
So instead of running "git rebase origin" at this point, I may
do something like this [*1*]:
$ git-reset --hard origin
$ git-format-patch -k --stdout origin ORIG_HEAD | git am -3 -k
The first step rewinds my "master" (the original is stored in
ORIG_HEAD), and the second step extracts the commits that were
in my master but not in origin in a patch form, an replay them
on top of the "master" (which was rewound to "origin").
"git-am" would stop at the first unapplicable patch if there is
a conflict, leaving the conflicting patch in .dotest/patch.
I have to fix it up before going further. Here is how.
1. "git am" 3-way fallback would have kicked in, because I have
all the blobs the patch is supposed to apply to, and my
working tree and index is in a state just like when I am
resolving a conflicting merge after a pull. Clean up the
conflict in the working tree, build-test and all as usual.
2. Run "git diff HEAD >.dotest/patch" to record what the patch
should have been if it were to apply cleanly on top of the
previous state. If I did a noteworthy adjustment to the
patch, I might also edit .dotest/final-commit to update the
commit log message.
3. Then reset the working tree and index before the failed
application of this patch with "git reset --hard".
After that:
$ git am -3
would let me restart from that commit that did not replay well.
This was recently added by Linus to help git-merge do that:
git-read-tree --trivial -m -u $O $A $B
The command exits with a non-zero status, without touching index
nor working tree, when the merge is not "truly trivial".
Otherwise it does its thing -- the trivial in-index merge is
done, files in working tree updated and the only thing left for
you to do is to create a commit having parent $A and $B.
Would that help?
[Footnote]
*1* This is what the "make rebase restartable" comment in TODO
list is about, and I wanted to rewrite "rebase" to do exactly
these two commands, but I got distracted ;-).
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
