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

>
> 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.

> 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

> 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.