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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 12, 2022, 15:37 UTC
Message-ID: <xmqq8royibor.fsf@gitster.g>
In-Reply-To: <pull.1247.v4.git.1657631225.gitgitgadget@gmail.com>

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

Show 17 quoted lines

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

Show 19 quoted lines

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