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

From: Junio C Hamano <gitster@pobox.com>
To: "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, johannes.schindelin@gmx.de, me@ttaylorr.com,
	Jeff Hostetler <git@jeffhostetler.com>,
	Phillip Wood <phillip.wood123@gmail.com>,
	Elijah Newren <newren@gmail.com>,
	Derrick Stolee <derrickstolee@github.com>
Subject: Re: [PATCH v4 00/12] rebase: update branches in multi-part topic
Date: Tue, 12 Jul 2022 08:37:56 -0700	[thread overview]
Message-ID: <xmqq8royibor.fsf@gitster.g> (raw)
In-Reply-To: <pull.1247.v4.git.1657631225.gitgitgadget@gmail.com> (Derrick Stolee via GitGitGadget's message of "Tue, 12 Jul 2022 13:06:53 +0000")

"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes:

> This series is based on ds/branch-checked-out.
> ...
> Updates in v4
> =============
>
> This version took longer than I'd hoped (I had less time to work on it than
> anticipated) but it also has some major updates. These major updates are
> direct responses to the significant review this series has received. Thank
> you!
>
>  * The update-refs file now stores "ref/before/after" triples (still
>    separated by lines). This allows us to store the "before" OID of a ref in
>    addition to the "after" that we will write to that ref at the end of the
>    rebase. This allows us to do a "force-with-lease" update. The
>    branch_checked_out() updates should prevent Git from updating those refs
>    while under the rebase, but older versions and third-party tools don't
>    have that protection.

Nice.

>  * The update-refs file is updated with every update to the todo-list file.
>    This allows for some advanced changes to the file, including removing,
>    adding, and duplicating 'update-ref' commands.
>  * The message at the end of the rebase process now lists which refs were
>    updated with the update-ref steps. This includes any ref updates that
>    fail.
>  * The branch_checked_out() tests now use 'git bisect' and 'git rebase' as
>    black-boxes instead of testing their internals directly.
>
> Here are the more minor updates:
>
>  * Dropped an unnecessary stat() call.
>  * Updated commit messages to include extra details, based on confusion in
>    last round.
>  * The HEAD branch no longer appears as a comment line in the initial todo
>    list.
>  * The update-refs file is now written using a lockfile.
>  * Tests now use test_cmp_rev.
>  * A memory leak ('path' variable) is resolved.

Interesting.

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.