Re: [PATCH 1/3] Prepare for non-interactive merge-preserving rebase

The following DAG is created by the commands below:

  -A---B      master
    \
     C---M    topic
      \ /
       D

  git init
  echo 1 >foo
  git add foo
  git commit -m 'first on master'       # A
  echo 2 >>foo
  git commit -m 'second on master' foo  # B
  git checkout -b topic HEAD^
  echo 1 >bar
  git add bar
  git commit -m 'first on topic'        # C
  git checkout -b subtopic
  echo 1 >baz
  git add baz
  git commit -m 'first on subtopic'     # D
  git checkout topic
  git merge --no-ff subtopic            # M

If I now execute 'git rebase -p master topic', I get the following:

  -A---B            master
    \   \
     \   C'---M'    topic
      \      /
       C----D

Following up on this old thread, I can't get M' to have the old parent
D. I always see D change to D' and then topic is fast fowarded to D'
instead of an M' showing up. (I've tried 1.6.0.2, my rebase-i-p changes,
and sp/maint.)

But I would rather like to have the following:

  -A---B            master
        \
         C'---M'    topic
          \  /
           D'

Would such a behaviour possible at all?

Yes, I think it just takes the following patch:

--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh

@@ -251,7 +251,7 @@ pick_one_preserving_merges () {
                                GIT_AUTHOR_EMAIL="$GIT_AUTHOR_EMAIL" \
                                GIT_AUTHOR_DATE="$GIT_AUTHOR_DATE" \
                                output git merge $STRATEGY -m "$msg" \
-                                       $new_parents
+                                       --no-ff $new_parents

Applying this to either sp/maint or my rebase-i-p changes gets your
desired output.

With the only caveat being that the subtopic branch stays pointing at
the old D--since you are rebasing topic, it does not change where
subtopic points when rewriting D -> D'.

Musing, I could see moving subtopic being possible, definitely with git
sequencer, but also with a --other-branches-follow-rewrites flag of some
sort that, after rewriting hash1->hash2, just finds any local branches
pointing at hash1 and updates their refs to be hash2. Not that I'm
really suggesting it, but I don't think it would be that hard.

Anyway, subtopic still pointing at D aside, I think your desired output
makes sense, given you've explicitly told rebase to preserve merges. If
you wanted a non-ff M in the first place, I think passing along a
--no-ff to keep M' around is reasonable. And would otherwise be harmless.

I can write a test/patch for this unless you beat me to it or other
think it is unreasonable.

- Stephen