"Johannes Schindelin via GitGitGadget" <gitgitgadget@xxxxxxxxx>
writes:
> This patch series completes the support for all rebase options in the
> builtin rebase, e.g. --signoff, rerere-autoupdate, etc.
>
> It is based on pk/rebase -in-c-3-acts.
... which in turn was based on pk/rebase-in-c-2-basic that just got
rerolled, so I would assume that you want pk/rebase-in-c-3-acts I
have rebased on top of the result of applying the updated 2-basic
series.
I've rebuilt the collection of topics up to pk/rebase-in-c-6-final
with these two updated series twice, once doing it manually, like I
did the last time, and another using "rebase -i -r" on top of the
updated pk/rebase-in-c-4-opts. The resulting trees match, of
course.
I did it twice to try out how it feels to use "rebase -i -r" because
I wanted to make sure what we are shipping in 'master' behaves
sensibly ;-)
Two things I noticed about the recreation of the merge ...
Reminder to bystanders. We need to merge ag/rebase-i-in-c
topic on top of pk/reabse-in-c-5-test topic before applying
a patch to adjust rebase to call rebase-i using the latter's
new calling convention. The topics look like
- pk/rebase-in-c has three patches on master
- pk/rebase-in-c-2-basic builds on it, and being replaced
- pk/rebase-in-c-3-acts builds on 2-basic (no update this time)
- pk/rebase-in-c-4-opts builds on 3-acts, and being replaced
- pk/rebase-in-c-5-test builds on 4-opts (no update this time)
- js/rebase-in-c-5.5 builds on 5-test and merges ag/rebase-in-c
topic before applying one patch on it (no update this time)
- pk/rebase-in-c-6-final builds on 5.5 (no update this time)
and we are replacing 2-basic with 11 patches and 4-opts with
18 patches.
... using "rebase -i -r" are that
(1) it rebuilt, or at least offered to rebuild, the entire side
branch, even though there is absolutely no need to. Leaving
"pick"s untouched, based on the correct fork point, resulted in
all picks fast forwarded, but it was somewhat alarming.
(2) "merge -C <original merge commit> ag/rebase-i-in-c" appeared as
the insn to merge in the (possibly rebuilt) side branch. And
just like "commit -C", it took the merge message from the
original merge commit, which means that the summary of the
merged side branch is kept stale. In this particular case, I
did not even want to see ag/rebase-i-in-c topic touched, so I
knew I want to keep the original merge summary, but if the user
took the offer to rewrite the side branch (e.g. with a "reword"
to retitle), using the original merge message would probably
disappoint the user.
I think (1) actually is a feature. Not everybody is an integrator
who does not want to touch any commit on the topic branch(es) while
rebuilding a single-strand-of-pearls that has many commits and an
occasional merge of the tip of another topic branch. It's just that
the feature does not suit the workflow I use when I am playing the
top-level integrator role.
I am not sure what should be the ideal behaviour for (2). I would
imagine that
- I do want to keep the original title the merge (e.g. "into
<target branch>", if left to "git merge" to come up with the
title during "rebase -i" session, would be lost and become "into
HEAD", which is not what we want);
- I do want to keep the original commentary in the merge (e.g. what
you would see in "git log --first-parent master..next" that gives
summary of each topic getting merged) so that I can update it as
needed; but
- I do want the topic summary fmt-merge-msg produces to be based on
the updated side branch.
I am not sure if the last item can reliably be filtered out of the
original and replaced with newly generated summary. If we can do
so, that would be ideal, I guess.
Another observation was that after rebuiding pk/rebase-in-c-6^0 on
top of the updated pk'/rebase-in-c-4 using "rebase -i -r", I of
course still needed to "branch -f" to update pk/rebase-in-c-5,
js/reabse-in-c-5.5, and pk/rebase-in-c-6 branches to point at
appropriate commits. I do not think it is a good idea to let
"rebase -i" munge these dependent branches by default, but it might
be worth considering it as an option. Since I want to be more in
control of what happens to the tips of topic branches, I did not
mind at all having to run "branch -f" and having the chance to run
"diff" before doing so, but at the same time, that means doing these
manually in steps building 5 on 4, 5.5 on 5 and then 6 on 5.5,
instead of building 6 on top of 4 using "rebase -i" and then tagging
the intermediate states, gives me more control without forcing me
more work.
I guess that is the answer to a question you asked earlier, which I
haven't answered so far because I didn't have a good grasp of where
my preference was coming from when it was asked. Now I know, so...
