1

I'm trying to understand how git rebase handles merges. I thought that with -p, it would be able to rebase conflicting merge that would have already been resolved. But it seams like it doesn't.

Here is an example to illustrate the issue:

git init
touch a && git add . && git commit -m 'first commit'
git branch b
git branch c
echo 'a' >> a && git add . && git commit -m a

git checkout b
echo 'b' >> a && git add . && git commit -m b

git checkout master
git merge b
echo ab > a
git add .
git commit

git checkout c
touch c && git add . && git commit -m c

git checkout master
git rebase -p c

Here I get a conflict applying the merge commit. Can someone explain to me why ?

Tom Esterez
  • 21,567
  • 8
  • 39
  • 44

2 Answers2

2

No, -p just keeps the merge commits in the history instead of flattening them. The docs explicitly say that this doesn't help with manual merging:

(from the man page)

Merge conflict resolutions or manual amendments to merge commits are not preserved.

Paul Hicks
  • 13,289
  • 5
  • 51
  • 78
  • Nothing non-interactive that I can think of. Maybe you can produce diffs yourself and re-apply them? – Paul Hicks Mar 01 '16 at 03:57
  • Thanks, just posted another question to understand why it behaves like that: http://stackoverflow.com/questions/35714919/why-git-rebase-p-does-not-preserve-conflict-resolutions – Tom Esterez Mar 01 '16 at 04:54
0

For this you can use Git rere:

git config --global rerere.enabled true

The name stands for “reuse recorded resolution” and, as the name implies, it allows you to ask Git to remember how you’ve resolved a hunk conflict so that the next time it sees the same conflict, Git can resolve it for you automatically.

tshalif
  • 2,277
  • 2
  • 15
  • 10