> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
