From: Matthieu Moy <Matthieu.Moy@grenoble-inp•fr>
To: "Michael S. Tsirkin" <mst@redhat•com>
Cc: Junio C Hamano <gitster@pobox•com>,
Johannes Schindelin <Johannes.Schindelin@gmx•de>,
git@vger•kernel.org, bafain@gmail•com, sunshine@sunshineco•com
Subject: Re: [PATCH 1/4] rebase -i: add ack action
Date: Mon, 11 Apr 2016 22:03:39 +0200 [thread overview]
Message-ID: <vpqr3ebnc9w.fsf@anie.imag.fr> (raw)
In-Reply-To: <20160411225222-mutt-send-email-mst@redhat.com> (Michael S. Tsirkin's message of "Mon, 11 Apr 2016 22:55:27 +0300")
"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 ;-).
> 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). I think using a better name
would help the discussion (to remove the "it's my use-case" biais).
Perhaps "append"?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
next prev parent reply other threads:[~2016-04-11 20:04 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-10 13:54 [PATCH 0/4] support for ack commits Michael S. Tsirkin
2016-04-10 13:54 ` [PATCH 1/4] rebase -i: add ack action Michael S. Tsirkin
2016-04-11 11:02 ` Johannes Schindelin
2016-04-11 11:24 ` Michael S. Tsirkin
2016-04-11 15:36 ` Johannes Schindelin
2016-04-11 16:41 ` Michael S. Tsirkin
2016-04-11 19:48 ` Junio C Hamano
2016-04-11 19:55 ` Michael S. Tsirkin
2016-04-11 20:03 ` Matthieu Moy [this message]
2016-04-12 7:51 ` Michael S. Tsirkin
2016-04-12 16:07 ` Junio C Hamano
2016-04-12 16:33 ` Michael S. Tsirkin
2016-04-12 20:00 ` Junio C Hamano
2016-04-11 12:05 ` Christian Neukirchen
2016-04-10 13:54 ` [PATCH 2/4] git-rebase: document ack Michael S. Tsirkin
2016-04-10 13:54 ` [PATCH 3/4] rebase: test ack Michael S. Tsirkin
2016-04-10 13:54 ` [PATCH 4/4] git-ack: record an ack Michael S. Tsirkin
-- strict thread matches above, loose matches on Subject: below --
2014-05-18 21:17 [PATCH 0/4] ack recoding in commit log Michael S. Tsirkin
2014-05-18 21:17 ` [PATCH 1/4] rebase -i: add ack action Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=vpqr3ebnc9w.fsf@anie.imag.fr \
--to=matthieu.moy@grenoble-inp$(echo .)fr \
--cc=Johannes.Schindelin@gmx$(echo .)de \
--cc=bafain@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=mst@redhat$(echo .)com \
--cc=sunshine@sunshineco$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox