Hi Warren
On 03/09/2019 00:41, Warren He wrote:
Sometimes people have to rebase multiple related branches. One way to do that
quickly, when there are branches pointing to ancestors of a later branch (which
happens a lot if you try hard to pad your PR count on GitHub--I mean if you try
to make small, logically separate changes), is to rebase that later branch and
then reset ancestor branches to the rewritten commits. You just have to work
out which branches correspond to which of the new commits.
Here's an automated way to update those ancestor branches.
I think this would be really useful, but as it is implemented here it
only updates branch heads that are in the todo list. This means that if
I have a branch structure like
A - B (master)
|
C - E (topic-2)
|
D (topic-1)
and I do `git rebase --update-branches master topic1` Then topic-2 will
not be updated and if I do `git rebase --update-branches master topic2`
then topic-1 will not be updated even though C is updated in both cases
and is a common ancestor of topic-1 and topic-2. Conceptually to update
all the branches descended from a rewritten commit would require using
`git for-each-ref --contains $(git merge-base <upstream> <branch>)` and
then using `git rev-list <upstream>..<branch-head>` on each of those
refs to get the commits to generate the todo list.
Another case is applying fixup commits. In the example above if I squash
a fixup for C from either branch I probably want to update both the
branches descended from it.
One other thing is that if the user aborts the rebase then ideally we
don't want to update all the branches so it would be better to store the
updated heads as we go along and then update them all at the end of the
rebase. Worktrees add another complication as if one of the branches
that is to be updated is checked out in another worktree then we need
some way to deal with that. If there are no local changes in that
worktree then we could just update the local HEAD and working copy.
Best Wishes
Phillip
It's implemented as a function that processes a todo list, modeled after
`todo_list_add_exec_commands`. Currently steps are added as `exec git branch -f
<branchname>`, which comes with the caveat that they're not applied atomically
when it finishes rebasing.
If you were to use this feature to rebase `my-dev` onto `master` in this
situation:
```
A - B (master)
|\
| E (feat-e)
\ \
F | (feat-f)
\|
G (interim)
\
H (my-dev)
```
you'd get a todo list like this:
```
label onto
# Branch G
reset onto
pick 65945ab E
exec git branch -f feat-e
label G
reset onto
pick 4f0b0ad F
exec git branch -f feat-f
merge -C e50066c G # G
exec git branch -f interim
pick 539e556 H
```
Warren He (1):
rebase: introduce --update-branches option
Documentation/git-rebase.txt | 8 +++++
builtin/rebase.c | 13 ++++++--
sequencer.c | 68 ++++++++++++++++++++++++++++++++++++++-
sequencer.h | 6 ++--
t/t3431-rebase-update-branches.sh | 64 ++++++++++++++++++++++++++++++++++++
5 files changed, 154 insertions(+), 5 deletions(-)
create mode 100755 t/t3431-rebase-update-branches.sh
