Re: b4 submit ready for beta testing

[Jason Gunthorpe <jgg@ziepe.ca>]

On Mon, Jul 18, 2022 at 10:28:13PM +0200, Geert Uytterhoeven wrote:
> Hi Jason,
> 
> On Mon, Jul 18, 2022 at 8:17 PM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> > On Sun, Jul 17, 2022 at 12:02:18PM -0400, Konstantin Ryabitsev wrote:
> > > Perhaps, but I also have other reasons to like using an empty commit for this.
> > > For example, it makes it very easy to mark where exactly our series
> > > starts.
> >
> > It is a good point, but it is backwards to how alot of people have
> > been doing things already for a long time..
> >
> > Putting the commit last makes it work a lot more like the usual
> > merge-commit approach to preserve the cover letter. Particularly if
> > you open the branch in any of the web viewers for git, or gitk you get
> > a very nice view of the cover letter explaining the branch followed by
> > the usual code in reverse patch order.
> 
> So a tag does sound like a logical place to store the cover letter,
> as merging the tag already pulls in the tag description into the
> merge commit?

See 'git-tag(1)' "On Re-tagging" for a discussion on why changing tags
that have been pushed is a bad idea. There are many troublesome
behaviors here.

Tags are not a solution to store the cover letter during development..

> > It would be nice to use merge commits to mark the series boundary, but
> > IMHO, the tooling is poor for this.
> 
> Tou can use "git tag --points-at" to find out if you already have a tag
> pointing to a commit.

tags are also bad because they don't auto track - when I rebase a
series with an empty cover commit everything stays in order
automatically. I can even shuffle around where patches are in a
multi-series work and break up a series with new cover letters rather
trivially with git rebase.

If I use a tag I have to remember to update the tag after every
rebase. It is much more likely to break down.

Jason