> The following DAG is created by the commands below:
quoted text
> 
>   -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.)

quoted text
> 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



--
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