On July 21, 2022 11:40 AM, Konstantin Ryabitsev wrote: >On Thu, Jul 21, 2022 at 11:29:20AM -0400, rsbecker@xxxxxxxxxxxxx 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
