git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
MTMichael S. Tsirkin <mst@redhat.com>
Date
Apr 12, 2016, 07:51 UTC
Message-ID
<20160412104133-mutt-send-email-mst@redhat.com>
In-Reply-To
<vpqr3ebnc9w.fsf@anie.imag.fr>
On Mon, Apr 11, 2016 at 10:03:39PM +0200, Matthieu Moy wrote:
Show 46 quoted lines
> "Michael S. Tsirkin" <mst@redhat.com> writes:
> 
> > 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.
> 
> This "modify a branch without checking-it out" makes me think of "git
> notes". It may make sense to teach "git rebase -i" to look for notes in
> rebased commits and append them to the commit message when applying.
> Just an idea, not necessarily a good one ;-).
Two things making it harder
	- machinery to look for commits is part of git rebase anyway
	- notes are expected to come after --- at the moment
Show 6 quoted lines
> > Does it sounds interesting if I teach
> > git ack to get an active branch as a parameter?
> 
> I think "ack" is not a good name for this feature: you use it to append
> "Acked-by", but it can be used to append any trailer (for example,
> Reviewed-by: would make complete sense too).
Yes - I use it to append all trailers.
> I think using a better name
> would help the discussion (to remove the "it's my use-case" biais).
> Perhaps "append"?
Or "trailer".
> -- 
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
Previous: Matthieu MoyNext: Junio C Hamano
Message 10 of 17 in “support for ack commits”
  1. 0/4 support for ack commitsMichael S. Tsirkin, Apr 10, 2016
  2. 1/4 rebase -i: add ack actionMichael S. Tsirkin, Apr 10, 2016
  3. Johannes SchindelinApr 11, 2016
  4. Michael S. TsirkinApr 11, 2016
  5. Johannes SchindelinApr 11, 2016
  6. Michael S. TsirkinApr 11, 2016
  7. Junio C HamanoApr 11, 2016
  8. Michael S. TsirkinApr 11, 2016
  9. Matthieu MoyApr 11, 2016
  10. Michael S. TsirkinApr 12, 2016
  11. Junio C HamanoApr 12, 2016
  12. Michael S. TsirkinApr 12, 2016
  13. Junio C HamanoApr 12, 2016
  14. Christian NeukirchenApr 11, 2016
  15. 2/4 git-rebase: document ackMichael S. Tsirkin, Apr 10, 2016
  16. 3/4 rebase: test ackMichael S. Tsirkin, Apr 10, 2016
  17. 4/4 git-ack: record an ackMichael S. Tsirkin, Apr 10, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.