Re: [PATCH 1/4] rebase -i: add ack action

["Michael S. Tsirkin" <mst@redhat.com>]

On Mon, Apr 11, 2016 at 12:48:22PM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > Repost, sorry about the noise.
> >
> > On Mon, Apr 11, 2016 at 05:36:45PM +0200, Johannes Schindelin wrote:
> >> Hi Michael,
> >> 
> >> On Mon, 11 Apr 2016, Michael S. Tsirkin wrote:
> >> 
> >> > So far I only see examples of adding footers. If that's all we can think
> >> > up, why code in all this genericity?
> >> 
> >> Because as far as I can see, the only benefitor of your patches would be
> >> you.
> >> 
> >> Ciao,
> >> Johannes
> >
> > This seems unlikely.  Just merging the patches won't benefit me directly
> > - I have maintained them in my tree for a couple of years now with very
> > little effort.  For sure, I could benefit if they get merged and then
> > someone improves them further - that was the point of posting them - but
> > then I'm not the only benefitor.
> >
> > The workflow including getting acks for patches by email is not handled
> > well by upstream git right now.  It would surprise me if no one uses it
> > if it's upstream, as you seem to suggest.  But maybe most people moved
> > on and just do pull requests instead.
> 
> I doubt I would use this in its current form myself.
> 
> Patch series I receive are all queued on their own separate topic
> branches, and having to switch branches only to create a fake empty
> commit to record received Acked-by and Reviewed-by is a chore that
> serves only half of what needs to be done.

Interesting. An empty commit would be rather easy to create on any
branch, not just the current one, using git-commit-tree.
Does it sounds interesting if I teach
git ack to get an active branch as a parameter?


> Once I decide to switch
> back to the topic branch after receiving Acked-by and Reviewed-by,
> I'd rather "rebase -i" to directly record them at that point, with
> "reword".
> 
> If the "trailers" stuff is packaged into an easier-to-use format to
> use with "git commit --amend", I may use that together with "exec"
> to automatically add these while doing so, but again, I do not see
> any need for fake empty commits out of received e-mails in the
> resulting workflow.
> 
> That does not at all mean nobody other than Michael would use it,
> though.