On Mon, Apr 11, 2016 at 12:48:22PM -0700, Junio C Hamano wrote: > "Michael S. Tsirkin" <m...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
