{"thread":{"id":"25987","subject":"git format-patch should honor notes","startedAt":"2010-12-07T21:53:09Z","lastAt":"2010-12-08T11:15:40Z","messageCount":8,"participants":["Eric Blake","Junio C Hamano","Jeff King","Michael J Gruber","Johan Herland","Thomas Rast"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"157548","messageId":"4CFEACC5.70005@redhat.com","threadId":"25987","inReplyTo":null,"subject":"git format-patch should honor notes","fromName":"Eric Blake","fromEmail":"eblake@redhat.com","sentAt":"2010-12-07T21:53:09Z","receivedAt":"2010-12-07T21:53:09Z","isPatch":false,"sender":{"key":"eblake@redhat.com","avatar":"https://avatars.githubusercontent.com/u/32933908?v=4"},"body":"I'm just starting to experiment with 'git notes', because it seems to\nfit well with my workflow on several projects, except for one drawback.\n\nMy workflow is that I post patch series for upstream review via 'git\nsend-email'.  Often, that results in feedback that requires me to\namend/rebase my series, and post a v2 or v3 of the series.  By adding\n'git config notes.rewriteRef refs/notes/commits', I can add notes that\nwill carry across my rebase, and remind me what I changed in v2 (for\nexample, git notes add -m 'v2: fix foo, per mail xyz@example.com').\nThis is handy for me, and I think it is also handy for reviewers -\nsomeone who took the time to read through v1 should know what I changed\nin response to their comments, and only have to focus in on commits with\nchanges, rather than on the entire resent series.\n\nHowever, I think such review helps are informational only - that is, in\n'git send-email' parlance, they belong between the '-- ' and diffstat\nlines of the email, and not in the upstream commit.  After all, once my\nseries is finally accepted upstream, it will no longer be rebased, and\n'git bisect' sees only the final version.  I see no reason for the\ncommit message to carry the cruft of extra information that was only\nhelpful during reviewing the amended series, nor any reason why upstream\nshould carry around my notes.\n\nSo, what I'm missing is the ability for 'git send-email' (or more\nfundamentally, 'git format-patch') to be able to include contents of a\nparticular (set of) notes reference in each patch file it generates,\nwhere the note falls in the informative portion of the email, and is\nintentionally omitted from the upstream commit when someone else runs\n'git am' on my email.\n\n-- \nEric Blake   eblake@redhat.com    +1-801-349-2682\nLibvirt virtualization library http://libvirt.org\n\n"},{"id":"157550","messageId":"7vmxohnsik.fsf@alter.siamese.dyndns.org","threadId":"25987","inReplyTo":"4CFEACC5.70005@redhat.com","subject":"Re: git format-patch should honor notes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-12-07T22:10:43Z","receivedAt":"2010-12-07T22:10:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Blake <eblake@redhat.com> writes:\n\n> So, what I'm missing is the ability for 'git send-email' (or more\n> fundamentally, 'git format-patch') to be able to include contents of a\n> particular (set of) notes reference in each patch file it generates,\n> where the note falls in the informative portion of the email, and is\n> intentionally omitted from the upstream commit when someone else runs\n> 'git am' on my email.\n\nI do not know if \"should\" is the right word, but it certainly sounds like\nit would be nice to have such an option for the usecase you described.\n"},{"id":"157551","messageId":"20101207221151.GC1036@sigill.intra.peff.net","threadId":"25987","inReplyTo":"4CFEACC5.70005@redhat.com","subject":"Re: git format-patch should honor notes","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-12-07T22:11:52Z","receivedAt":"2010-12-07T22:11:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 07, 2010 at 02:53:09PM -0700, Eric Blake wrote:\n\n> My workflow is that I post patch series for upstream review via 'git\n> send-email'.  Often, that results in feedback that requires me to\n> amend/rebase my series, and post a v2 or v3 of the series.  By adding\n> 'git config notes.rewriteRef refs/notes/commits', I can add notes that\n> will carry across my rebase, and remind me what I changed in v2 (for\n> example, git notes add -m 'v2: fix foo, per mail xyz@example.com').\n> This is handy for me, and I think it is also handy for reviewers -\n> someone who took the time to read through v1 should know what I changed\n> in response to their comments, and only have to focus in on commits with\n> changes, rather than on the entire resent series.\n\nYeah, that is a workflow that some others have mentioned using here,\ntoo. And I think there is general agreement that notes should go after\nthe \"---\" in format-patch. We just need a working patch.\n\nThomas posted one in February:\n\n  http://article.gmane.org/gmane.comp.version-control.git/140819\n\nBut there were some issues and it never got polished. Michael suggested\nthat he does something similar here:\n\n  http://article.gmane.org/gmane.comp.version-control.git/140819\n\nbut there was no indication on whether it happens manually or if he has\na patch. I don't know if anything else has happened in that area. I'm\nsure if you feel like working on a patch it would be well received.\n\n-Peff\n"},{"id":"157584","messageId":"4CFF3FE4.4080104@warpmail.net","threadId":"25987","inReplyTo":"20101207221151.GC1036@sigill.intra.peff.net","subject":"Re: git format-patch should honor notes","fromName":"Michael J Gruber","fromEmail":"drmicha@warpmail.net","sentAt":"2010-12-08T08:20:52Z","receivedAt":"2010-12-08T08:20:52Z","isPatch":false,"sender":{"key":"drmicha@warpmail.net","avatar":null},"body":"Jeff King venit, vidit, dixit 07.12.2010 23:11:\n> On Tue, Dec 07, 2010 at 02:53:09PM -0700, Eric Blake wrote:\n> \n>> My workflow is that I post patch series for upstream review via 'git\n>> send-email'.  Often, that results in feedback that requires me to\n>> amend/rebase my series, and post a v2 or v3 of the series.  By adding\n>> 'git config notes.rewriteRef refs/notes/commits', I can add notes that\n>> will carry across my rebase, and remind me what I changed in v2 (for\n>> example, git notes add -m 'v2: fix foo, per mail xyz@example.com').\n>> This is handy for me, and I think it is also handy for reviewers -\n>> someone who took the time to read through v1 should know what I changed\n>> in response to their comments, and only have to focus in on commits with\n>> changes, rather than on the entire resent series.\n> \n> Yeah, that is a workflow that some others have mentioned using here,\n> too. And I think there is general agreement that notes should go after\n> the \"---\" in format-patch. We just need a working patch.\n> \n> Thomas posted one in February:\n> \n>   http://article.gmane.org/gmane.comp.version-control.git/140819\n> \n> But there were some issues and it never got polished. Michael suggested\n> that he does something similar here:\n> \n>   http://article.gmane.org/gmane.comp.version-control.git/140819\n> \n> but there was no indication on whether it happens manually or if he has\n> a patch. I don't know if anything else has happened in that area. I'm\n> sure if you feel like working on a patch it would be well received.\n> \n> -Peff\n\nI do it with \":r!git notes show\" in vim (after \"/---\"), which has the\nadvantage over \"format-patch --show-notes\" that the notes are not\nindented nor preceded by a \"Notes:\" header. (I wouldn't mind the\nlatter.) This is comfortable enough to have kept me from writing a patch.\n\nAlso, in order to be really useful, I would need a place to store the\ncover letter also. I was experimenting a while back with a design for\nannotating branchnames which \"basically\" worked but haven't had time to\nreally implement it. If I remember correctly, I had to set up some\n\"bogus\" refs to keep my notes from being garbage collected and was still\nfiguring out the best place to put them. I'll dig it up when I have time to.\n\nMichael\n"},{"id":"157589","messageId":"201012081112.12112.johan@herland.net","threadId":"25987","inReplyTo":"4CFF3FE4.4080104@warpmail.net","subject":"Re: git format-patch should honor notes","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2010-12-08T10:12:11Z","receivedAt":"2010-12-08T10:12:11Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 08 December 2010, Michael J Gruber wrote:\n> Also, in order to be really useful, I would need a place to store the\n> cover letter also. I was experimenting a while back with a design for\n> annotating branchnames which \"basically\" worked but haven't had time\n> to really implement it. If I remember correctly, I had to set up some\n> \"bogus\" refs to keep my notes from being garbage collected and was\n> still figuring out the best place to put them. I'll dig it up when I\n> have time to.\n\nI believe the last time the issue of adding notes to branch names was \ndiscussed, the consensus was that rather than using notes, they could \nbe stored using a custom entry in the config file, e.g.\n\n  git config branch.mybranch.description \"Description of mybranch\"\n\nI might have misremembered this, though.\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"157591","messageId":"4CFF5CD2.2000009@drmicha.warpmail.net","threadId":"25987","inReplyTo":"201012081112.12112.johan@herland.net","subject":"Re: git format-patch should honor notes","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-12-08T10:24:18Z","receivedAt":"2010-12-08T10:24:18Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johan Herland venit, vidit, dixit 08.12.2010 11:12:\n> On Wednesday 08 December 2010, Michael J Gruber wrote:\n>> Also, in order to be really useful, I would need a place to store the\n>> cover letter also. I was experimenting a while back with a design for\n>> annotating branchnames which \"basically\" worked but haven't had time\n>> to really implement it. If I remember correctly, I had to set up some\n>> \"bogus\" refs to keep my notes from being garbage collected and was\n>> still figuring out the best place to put them. I'll dig it up when I\n>> have time to.\n> \n> I believe the last time the issue of adding notes to branch names was \n> discussed, the consensus was that rather than using notes, they could \n> be stored using a custom entry in the config file, e.g.\n> \n>   git config branch.mybranch.description \"Description of mybranch\"\n> \n> I might have misremembered this, though.\n\nThey certainly \"could\". The question whether they \"should\" depends on\nwhat they are used for:\n\n- config is neither versioned nor easily shareable; perfect for your own\nscratch notes to go away once work is done\n\n- notes are versioned and can be shared (I don't need to tell you...);\nperfect for longer term annotations you want to keep\n\nNote that \"sharing\" here includes also pushing to your backup repo and\ncloning around. I'd certainly put patch series cover letters in the\nsecond category.\n\nMichael\n"},{"id":"157593","messageId":"201012081150.09424.johan@herland.net","threadId":"25987","inReplyTo":"4CFF5CD2.2000009@drmicha.warpmail.net","subject":"Re: git format-patch should honor notes","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2010-12-08T10:50:09Z","receivedAt":"2010-12-08T10:50:09Z","isPatch":false,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Wednesday 08 December 2010, Michael J Gruber wrote:\n> Johan Herland venit, vidit, dixit 08.12.2010 11:12:\n> > On Wednesday 08 December 2010, Michael J Gruber wrote:\n> >> Also, in order to be really useful, I would need a place to store\n> >> the cover letter also. I was experimenting a while back with a\n> >> design for annotating branchnames which \"basically\" worked but\n> >> haven't had time to really implement it. If I remember correctly,\n> >> I had to set up some \"bogus\" refs to keep my notes from being\n> >> garbage collected and was still figuring out the best place to put\n> >> them. I'll dig it up when I have time to.\n> >\n> > I believe the last time the issue of adding notes to branch names\n> > was discussed, the consensus was that rather than using notes, they\n> > could be stored using a custom entry in the config file, e.g.\n> >\n> >   git config branch.mybranch.description \"Description of mybranch\"\n> >\n> > I might have misremembered this, though.\n>\n> They certainly \"could\". The question whether they \"should\" depends on\n> what they are used for:\n>\n> - config is neither versioned nor easily shareable; perfect for your\n> own scratch notes to go away once work is done\n>\n> - notes are versioned and can be shared (I don't need to tell\n> you...); perfect for longer term annotations you want to keep\n>\n> Note that \"sharing\" here includes also pushing to your backup repo\n> and cloning around. I'd certainly put patch series cover letters in\n> the second category.\n\nTrue. I was wrong to equate cover letters with local-only branch name \ndescriptions.\n\nAs has been discussed before, you can use notes to store the cover \nletter, the question is which SHA-1 to attach it to.\n\nUsing a SHA-1 that doesn't exist in the repo (e.g. the SHA-1 of the \nbranch name) leaves the note vulnerable to 'git notes prune', but maybe \nthat is an acceptable restriction ('git notes prune' must be manually \ninvoked in any case). For extra safety, we could add a config option \nthat refuses 'git notes prune' for a given notes ref, something like:\n\n  git config notes.mynotes.refusePrune true\n\n\n...Johan\n\n-- \nJohan Herland, <johan@herland.net>\nwww.herland.net\n"},{"id":"157595","messageId":"201012081215.40809.trast@student.ethz.ch","threadId":"25987","inReplyTo":"20101207221151.GC1036@sigill.intra.peff.net","subject":"Re: git format-patch should honor notes","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-12-08T11:15:40Z","receivedAt":"2010-12-08T11:15:40Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jeff King wrote:\n> > My workflow is that I post patch series for upstream review via 'git\n> > send-email'.  Often, that results in feedback that requires me to\n> > amend/rebase my series, and post a v2 or v3 of the series.  By adding\n> > 'git config notes.rewriteRef refs/notes/commits', I can add notes that\n> > will carry across my rebase, and remind me what I changed in v2 (for\n> > example, git notes add -m 'v2: fix foo, per mail xyz@example.com').\n> \n> Yeah, that is a workflow that some others have mentioned using here,\n\nIncidentally it's what I wrote the rewriteRef support for :-)\n\n> too. And I think there is general agreement that notes should go after\n> the \"---\" in format-patch. We just need a working patch.\n> \n> Thomas posted one in February:\n> \n>   http://article.gmane.org/gmane.comp.version-control.git/140819\n> \n> But there were some issues and it never got polished.\n\nI got pretty frustrated with gfp being rather brittle.  It is very\nhard to insert anything anywhere in the output stream in such a way\nthat the output is not affected in any *other* scenario where this\noption is disabled.\n\nSo I think a good angle of attack if you want to hack around on this\nwould be to clean up gfp so that it becomes easier to work on, and/or\ncome up with a better/cleaner place to insert the notes support than I\nhad.\n\nThat being said, the version I still use just shifts around a linefeed\nafter the ---, IIRC, and so far nobody complained about that in\npractice ;-)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"}]}