Re: [PATCH v4 00/12] rebase: update branches in multi-part topic

From: Elijah Newren <newren@gmail.com>
To: Derrick Stolee <derrickstolee@github.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	Derrick Stolee via GitGitGadget <gitgitgadget@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	Taylor Blau <me@ttaylorr.com>,
	Jeff Hostetler <git@jeffhostetler.com>,
	Phillip Wood <phillip.wood123@gmail.com>
Subject: Re: [PATCH v4 00/12] rebase: update branches in multi-part topic
Date: Sat, 16 Jul 2022 13:56:34 -0700	[thread overview]
Message-ID: <CABPp-BFe7tWVe2v2y_QXJ_yDD8DDqApkvFAyVx-ACXkb-CcNsw@mail.gmail.com> (raw)
In-Reply-To: <73311eba-244b-3c88-d0b9-f97f426f1de6@github.com>

On Thu, Jul 14, 2022 at 7:50 AM Derrick Stolee <derrickstolee@github.com> wrote:
>
> On 7/12/22 11:37 AM, Junio C Hamano wrote:> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > This is a tangent, but may serve as some food for thought.
> >
> > When I queue (or develop myself) a topic that depends on another
> > topic, I often do
> >
> >     $ git checkout --detach vX.Y.Z ;# choose an appropriate base
> >     $ git merge --into derived-topic base-topic
> >     $ develop develop (or "git am")
> >
> > which would end up in
> >
> >     vX.Y.Z -----M---A---B---C derived-topic
> >                /
> >      base-topic
> >
> > so that "git log --first-parent --oneline master.." would show the
> > commits in the topic plus the fact that it depends on which other
> > topic recorded in a single merge commit.  A topic that depends on
> > two or more topics can be handled the same way.
> >
> > One good thing about this arrangement, unlike the "totally linear"
> > one depicted at the top of your cover letter, is that it is easier
> > to rebuild each topic independently and the first-parent view is
> > still useful.  If you futz with the base topic in a totally linear
> > history, "log --decorate" of the derived topic would no longer tell
> > you where the old iteration of the base topic ended.
> >
> > It would be very nice to see the update-ref feature (or something
> > like that) makes it easy to deal with such a topology, too.
>
> Your topology is an interesting one, but --update-refs isn't limited to
> linear history.
>
> (Begin aside)
>
> One goal of this feature is to make it easier to manage the topics that
> are being juggled in friendly forks. For example, git-for-windows/git and
> microsoft/git have some topics that evolve version-to-version but might be
> cleaned up and sent upstream. Both of these forks use 'git rebase
> --rebase-merges=rebase-cousins' when consuming new upstream versions to
> keep the merge structure of these new topics. However, we lose the branch
> names and need to reconstruct them from the context of the merge commits.
>
> With --update-refs, we can automatically rewrite the branches that are
> included in these individual topics. That might make it simpler to extract
> a series to send upstream.
>
> One test in this series does test such a case with the --rebase-merges
> option.
>
> (End aside)
>
> Back to your topology, I wonder what your rebase command looks like when
> tracking those topics.
>
> The goal of --update-refs is to help rebase multiple branches at the same
> time, and with your example here, it would imply you want to rebase both
> dependent topics.
>
>  Before:
>
>   A---B----C---M---Q1---Q2---Q3 <-- refs/heads/Q
>    \          /
>     P1--P2--P3 <-- refs/heads/P
>
>  After rebasing both topics simultaneously (with 'git rebase --update-refs
>  C' while Q is checked out):
>
>   A---B---C---D---P1---P2---P3---Q1---Q2---Q3
>                             ^              ^
>                         refs/heads/P  refs/heads/Q
>
> But it seems what you mean to say is to update the merge commit M, which
> means that the 'P' branch above has been updated independently of the 'Q'
> branch, so we need to update 'Q' after-the-fact. I'm not sure what that
> rebase would look like, indepdendent of updating refs.

Since this is an aside, I'll take a chance to talk about stuff I'm
working on.  After

  git replay --onto main --contained main..Q

(where "--contained" seems to be similar to rebase's --update-refs
option, in that it assumes all refs pointing to history being
rewritten should also be updated), or the more explicit

  git replay --onto main ^main P Q

and assuming 'main' has one additional commit 'D' on top of 'C', you'd see

   A---B---C---D-----------M---Q1---Q2---Q3 <-- refs/heads/Q
               \          /
                P1--P2--P3 <-- refs/heads/P

In other words, both P and Q would be replayed but with relative
topology preserved.  Also, important changes in M (conflict fixups or
semantic fixes, etc.) would be preserved -- at least that's the plan.

> Do you have an example rebase command that manipulates the commits the
> way you want? Then I can better understand how the --update-refs could fit
> in with that. (Or maybe the point of your tangent is that there isn't an
> option.)

This would be nice.

> If instead we thought about an example like re-rolling the 'next' branch
> entirely on top of the 'master' branch, then we have an example that is
> closer to the friendly fork example. (I know this isn't a realistic
> scenario since we don't rewrite the commits already merged to 'next', but
> it's an interesting stress test.)
>
> While having 'next' checked out, I ran
>
>   git rebase -i --update-refs --rebase-merges=rebase-cousins master

Re-rolling 'next' might not be realistic, but re-rolling 'seen' isn't
quite as far fetched.  I think it'd be more likely to use
no-rebase-cousins, so:

    git checkout seen && git rebase -i --update-refs
[--rebase-merges=no-rebase-cousins] next

or

    git replay -i --contained --keep-base next..seen

> and it updated all of the branches currently in the region master..next.
> I've attached the output of
>
>   git -c log.excludeDecoration="refs/remotes/*" \
>         log --oneline --graph --boundary master..next
>
> just to show what this looks like.

One example that I thought might be useful, is tweaking a single topic
in 'seen', and updating 'seen' to reflect those updates.  This would
be something like

    git replay --keep-base --first-parent ^next seen topic_branch

Which would show you all the commits in the first-line history of
next..topic_branch plus the first-line history of next..seen, and let
you tweak that todo list.