1

We are providing a significant contribution to an Apache project: let us call this

upstream/master

Our work is going to be a large chunk of contributions at one time instead of a more gentle/incremental approach: therefore, our branch has multiple months of divergence from upstream/master. Two months ago we did a lengthy/painful rebase to pick up all of the intervening changes from upstream/master and apply to our branch.

Now we want to rebase off of upstream/master again. If we simply use

git rebase [-i] upstream/master

Then in that case it appears we would need to re-merge EVERYTHING from the dawn of our new branch . This means that we would need to re-apply the lengthy/painful rebase from two months ago before even beginning to merge the last two months of work.

Are there any options from git to inform git to "start with the rebase/merge we did two months ago" - instead of duplicating that effort?

In any case we will still need to do the manual merge of the latest portion of our work. But the above process is obviously not sustainable - given there is still significant work to be completed before we do commit back to upstream/master

WestCoastProjects
  • 58,982
  • 91
  • 316
  • 560
  • If [`rerere`](http://git-scm.com/blog/2010/03/08/rerere.html) was enabled before that long/painful rebase, yes. Otherwise, you may be out of luck. – jub0bs Dec 29 '14 at 20:42
  • @Jubobs Thanks, we are looking at rerere now - at the least to enable it for future work. BTW feel free to make that an answer and I will upvote it. Will not accept just yet - maybe someone else has additional suggestions.. but upvotes are good for you too. – WestCoastProjects Dec 29 '14 at 20:53
  • 2
    I don't think any of the conflicts from where upstream was the first rebase will repeat. Is having all the recent upstream changes retroactively applied to every single commit you ever made eon this branch really worth it here? I'd seriously consider a straight merge here. – jthill Dec 29 '14 at 20:57
  • @javadba I can't think of an answer that wouldn't be too general. However, I wrote [an answer to a related question](http://stackoverflow.com/questions/25670519/git-rebase-preserve-merges-fails/25671230#25671230) a while back; feel free to upvote it if you find it useful :) – jub0bs Dec 29 '14 at 20:59
  • @Jubobs I upvoted your other answer. However, I do not fully understand the following section: "The --preserve-merges flag tells git-rebase to reconstruct merge commits in the rebased branch; it does not record conflict resolutions for future use." I am wondering if we can try the --preserve-merges? – WestCoastProjects Dec 29 '14 at 21:19
  • @javadba No. The `--preserve-merges` flag is described thus in the [`git-rebase` man page](https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html): *Instead of ignoring merges, try to recreate them.* It doesn't give rebase the ability of remembering how merge conflicts were resolved. It won't help you here. – jub0bs Dec 29 '14 at 21:23
  • I added a note to that other answer, I'll add a modified (more detailed) version of it here too. What I think you want is a git command that will: (1) turn on rerere, (2) "redo" a conflicted operation (merge or cherry-pick), and (3) "re-resolve" the conflicted operation using the commit that previously resolved the "being re-done" conflicted operation. With rerere set, that resolution gets recorded. You can now throw out the "redone" stuff, as the whole point of this was to get the resolution recorded. – torek Dec 29 '14 at 22:08
  • @torek Which answer are you referring to? – jub0bs Jan 16 '15 at 18:43
  • @Jubobs: uh. No idea now. There WAS something at that point... – torek Jan 16 '15 at 18:51

0 Answers0