0

There are many posts / questions / blogs about git rebase workflow. The following is what I understood and performed:

Rebase the local master to upstream

git fetch upstream
git rebase upstream/master
git reset --hard upstream/master

Rebase the fork master to upstream

git push origin +master

So far so good .. Now: attempt to Rebase the local branch to local master

git checkout strlen
git rebase -i HEAD~50  
# In the interactive I do a bunch of fixups and move the latest branch commit to the top

Some merge conflicts: so let us try to resolve them git status

# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#   both modified:      sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/SqlParser.scala
#   both modified:      sql/core/src/test/scala/org/apache/spark/sql/SQLQuerySuite.scala
#   both modified:      sql/hive/src/main/scala/org/apache/spark/sql/hive/HiveQl.scala

So let's do the manual merge and then add them:

meld sql/catalyst/src/main/scala/org/apache/spark/sql/catalyst/SqlParser.scala
meld sql/core/src/test/scala/org/apache/spark/sql/SQLQuerySuite.scala
meld  sql/hive/src/main/scala/org/apache/spark/sql/hive/HiveQl.scala
git add -a
git rebase -i --continue

Now here is the spot I get confused: the rebase now still complains about the same three files requiring a merge. But now it shows the merge conflict is due to an earlier commit on the same branch (strlen). But why? The rebase should have only had ONE merge conflict - tops - per file. Why are multiple merge conflicts happening on the same files?

WestCoastProjects
  • 58,982
  • 91
  • 316
  • 560
  • The `-i` flag that you're using in the rebase command makes it an interactive rebase. Judging from your question that's not what you want. – Patrik Oldsberg Aug 04 '14 at 16:57
  • 2
    Short not-quite-answer: rebase copies commits one at a time; a merge conflict in an "early" commit often remains a conflict in later commits. It's quite common to have conflicts persist all throughout. However, if you set `git rerere` (reuse recorded resolution), that often automates the fixing-up. – torek Aug 04 '14 at 17:00
  • @PatrikOldsberg I have updated the OP to describe how I am using (and do want) rebase -i. – WestCoastProjects Aug 04 '14 at 19:19
  • @torek My concern is that there are a half dozen commits in my branch - all of which touch the same set of files. The final commit has the .. well.. final version. That is what I want. Clearly going through 6 merges means I did something wrong in my process - we should instead be going directly to the end result. – WestCoastProjects Aug 04 '14 at 19:21
  • @torek The rerere looks interesting regardless: I am going to do "git config --global rerere.enabled true" – WestCoastProjects Aug 04 '14 at 20:06

1 Answers1

0

I have modified the workflow a bit to the following:

git pull --rebase origin mybranch

git rebase --continue

git push -f origin mybranch

WestCoastProjects
  • 58,982
  • 91
  • 316
  • 560