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

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

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 11, 2016, 19:48 UTC
Message-ID
<xmqqlh4krkop.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20160411184535-mutt-send-email-mst@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
Show 26 quoted lines
> 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. 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.

Previous: Michael S. TsirkinNext: Michael S. Tsirkin
Message 7 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.