Re: b4 submit ready for beta testing

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Jul 19, 2022 at 11:38:25AM -0400, James Bottomley wrote:
> On Tue, 2022-07-19 at 12:34 -0300, Jason Gunthorpe wrote:
> > On Tue, Jul 19, 2022 at 09:01:36AM -0400, James Bottomley wrote:
> > > On Mon, 2022-07-18 at 15:17 -0300, Jason Gunthorpe 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.
> > > > 
> > > > It would be nice to use merge commits to mark the series
> > > > boundary,
> > > > but IMHO, the tooling is poor for this.
> > > 
> > > The problem with empty commit is that a lot of the projects I
> > > contribute to can be pains about only taking one or two commits in
> > > a series, which means I use rebase to figure out the exactness of
> > > what they've done and drop included commits.  I can't keep this
> > > behaviour and work with empty commits.
> > 
> > Why not? rebase works fine with empty commits.
> 
> Because I don't want a load of non-cover letter empty commits in my
> repo.  The problem is the current behaviour is all or nothing and I
> want elimination of commits that did have code but now don't but not
> elimination of the empty commit for the cover letter.

I still don't get it. Today git rebase will preserve a empty commit
cover letter with no special option. So are you unhappy with how git
rebase is working?

I've done the workflow you describe and have not ended up with empty
commits. In the first pass git rebase will remove commits that are
already applied by using the patch-id, these commits don't even show
up in the todo you can see with 'git rebase -i'

If rebase does apply a commit and the merge resolution leaves it
empty, I'm pretty sure it goes ahead and discards it.

Jason