RE: On-branch topic description support?

From: rsbecker@nexbridge.com <rsbecker@nexbridge.com>
Date: Jul 21, 2022, 15:57 UTC
Message-ID: <010301d89d1a$8cdc54b0$a694fe10$@nexbridge.com>
In-Reply-To: <20220721153955.lnfqfilri24i2yw6@meerkat.local>

On July 21, 2022 11:40 AM, Konstantin Ryabitsev wrote:

Show 18 quoted lines

>On Thu, Jul 21, 2022 at 11:29:20AM -0400, rsbecker@nexbridge.com wrote:
>> I might be missing something here, but could not a description follow
>> similar semantics to how git describe works on tags? Anchor the
>> description on the commit where the branch was spawned, then determine
>> the appropriate description based on things like --first-parent.
>> Again, I'm probably in the weeds.
>
>I think the trouble is that "commit where the branch was spawned" is not reliable
>due to:
>
>- rebasing the work on a different branch
>- reordering commits (including the first commit in the series)
>
>This is the main reason why I actually want to stick the empty commit with the
>cover letter not at the tip of the branch, but at the start of the series, so as to
>clearly demarcate where the series of commits we're interested in starts (at least
>while the author is working on them -- when it sent off upstream that commit can
>get removed/moved).

That process may be more suitable outside the git team where merge --squash is commonplace and the whole series goes into next, main, maint as a single commit as the empty commit will simply vanish. Although, with that said, for the git team's committer process, having a starting point commit in the history also has some obvious advantages, for example, starting and ending points in history for git bisect when things go terribly wrong. --R