Re: On-branch topic description support?

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Jul 20 2022, Junio C Hamano wrote:

>  * When you are almost finished with the initial draft of your
>    topic, you'd write a cover letter, and record it as the log
>    message of an empty commit at the tip of the topic.

Isn't thu DAG topology of creating a merge that encompases the given
range a more clear marker for this sort of thing?

	# Create a topic branch
	git checkout -b topic -t origin/master
	for f in A B C; do echo $f >$f && git add $f && git commit -m$f; done

	# I forget if there a way to make the porcelain do this, not this or --ff...
	git merge @{u}
        # ... that's better!
	git reset --hard $(echo My CL here | git commit-tree -p @{u} -p HEAD HEAD:)

To steal and amend a diagram from git-merge(1), we now have turned this:


              A---B---C topic
             / 
        X---Y
             \
              master

Into this:

              A---B---C---M topic
             / \         /
        X---Y   ---------
             \
              master

I vaguely recall having actually used this for something in the past.

I tried now with "git rebase --rebase-merges -i", and it supports it
properly, i.e. I could re-arrange it so that it's:

              A---C---B---M topic
             / \         /
        X---Y   ---------
             \
              master

And it still gave me a merge commit whose parents were my branch tip,
and my @{upstream}.

The advantage of doing it this way is that it's obvious from the
topology what the lower bound of this "summary so far merge" is, with an
empty commit on top it:

 A) isn't distinguishable from other uses of empty commits, but this
     merge structure is rather unusual, so it sets it apart.

 B) You don't know what the lower bound is if your @{upstream} ref
    moves.

    I could see it being useful to e.g. offer to update the CL if
    there's conflicts, or if upstream has integrated part of my commits.