From: Phillip Wood <phillip.wood123@gmail.com>
To: Warren He <pickydaemon@gmail.com>, git@vger.kernel.org
Cc: Warren He <wh109@yahoo.com>, Junio C Hamano <gitster@pobox.com>,
"Brian M. Carlson" <sandals@crustytoothpaste.net>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
Taylor Blau <me@ttaylorr.com>
Subject: Re: [PATCH] rebase: introduce --update-branches option
Date: Tue, 3 Sep 2019 13:19:04 +0100 [thread overview]
Message-ID: <713b055b-aaf2-4294-12d3-2941d53eac16@gmail.com> (raw)
In-Reply-To: <20190902234109.2922-1-wh109@yahoo.com>
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
>
next prev parent reply other threads:[~2019-09-03 12:19 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-02 23:41 [PATCH] rebase: introduce --update-branches option Warren He
2019-09-02 23:41 ` Warren He
2019-09-03 13:26 ` Johannes Schindelin
2019-09-07 23:44 ` [PATCH v2] " Warren He
2019-09-07 23:44 ` Warren He
2019-09-09 10:44 ` Phillip Wood
2019-09-09 14:13 ` Johannes Schindelin
2019-09-09 18:11 ` Junio C Hamano
2019-09-23 9:40 ` Phillip Wood
2019-09-03 0:50 ` [PATCH] " brian m. carlson
2019-09-03 1:21 ` Junio C Hamano
2019-09-03 1:39 ` Taylor Blau
2019-09-07 23:41 ` Warren He
2019-09-08 18:04 ` brian m. carlson
2019-09-03 12:19 ` Phillip Wood [this message]
2019-09-07 23:43 ` Warren He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=713b055b-aaf2-4294-12d3-2941d53eac16@gmail.com \
--to=phillip.wood123@gmail.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=pickydaemon@gmail.com \
--cc=sandals@crustytoothpaste.net \
--cc=wh109@yahoo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).