{"thread":{"id":"32427","subject":"recommendation for patch maintenance","startedAt":"2012-12-21T14:45:03Z","lastAt":"2012-12-21T22:17:11Z","messageCount":6,"participants":["Manlio Perillo","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"205334","messageId":"50D475EF.6060303@gmail.com","threadId":"32427","inReplyTo":null,"subject":"recommendation for patch maintenance","fromName":"Manlio Perillo","fromEmail":"manlio.perillo@gmail.com","sentAt":"2012-12-21T14:45:03Z","receivedAt":"2012-12-21T14:45:03Z","isPatch":false,"sender":{"key":"manlio.perillo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6217088?v=4"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nHi.\n\nI would like to have advices about some possible workflows to use when\nmaintaining a patch, that can evolve over the time (fixing bugs, and\napplying advices from reviewers).\n\nIn my case I have a single commit to maintain.\n\n\nThe workflow I use now is this:\n\n  1) create a topic branch, e.g. mp/complete-path\n  2) write code\n  3) commit\n  4) format-patch --output=mp/complete-patch master\n  5) review the patch\n  6) send-email\n\nwhen I need to update the patch:\n\n  1) modify code\n  2) commit --amend\n  3) format-patch --subject-prefix=\"PATCH v<n>\" \\\n     --output=mp/complete-patch master\n  4) edit patch to add a list of what was changed\n  5) review the patch\n  6) send-email\n\n\nThis is far from ideal, since all my local changes are lost.\nAnother problem is that when I found some trivial error in 5), I need to\ncall format-patch again, loosing the \"what's changed list\".\n\n\nA possible solution is to:\n\n1) create a \"public\" topic branch, e.g. mp/complete-patch\n2) create the associated \"private\" topic branch, e.g.\n   mp/complete-patch/private\n...\n\nChanges are committed to the private branch.\nWhen I need to update the patch:\n\n  1) update code\n  2) commit new changes; the commit message will contain the\n     \"what's changed\" list to be used for the new version of the patch\n  3) checkout <public branch>\n  4) merge --squash <private branch>\n\nNow I have my full history, and the \"what's changed list\" is saved in\nthe private commits.\n\n(not tested)\n\n\nWhat is the workflow you usually use?\n\n\nThanks   Manlio\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.10 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\n\niEYEARECAAYFAlDUde4ACgkQscQJ24LbaUSqOwCfZON5f9mdAYkvACim802JGFhP\n5W8An1Y7WXgsH/Q/p1/0jVMo1dJ3HwwO\n=Xydn\n-----END PGP SIGNATURE-----\n"},{"id":"205348","messageId":"7vvcbv1grr.fsf@alter.siamese.dyndns.org","threadId":"32427","inReplyTo":"50D475EF.6060303@gmail.com","subject":"Re: recommendation for patch maintenance","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-21T17:01:12Z","receivedAt":"2012-12-21T17:01:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Manlio Perillo <manlio.perillo@gmail.com> writes:\n\n> I would like to have advices about some possible workflows to use when\n> maintaining a patch, that can evolve over the time (fixing bugs, and\n> applying advices from reviewers).\n>\n> In my case I have a single commit to maintain.\n>\n>\n> The workflow I use now is this:\n>\n>   1) create a topic branch, e.g. mp/complete-path\n>   2) write code\n>   3) commit\n>   4) format-patch --output=mp/complete-patch master\n>   5) review the patch\n>   6) send-email\n>\n> when I need to update the patch:\n>\n>   1) modify code\n>   2) commit --amend\n>   3) format-patch --subject-prefix=\"PATCH v<n>\" \\\n>      --output=mp/complete-patch master\n>   4) edit patch to add a list of what was changed\n>   5) review the patch\n>   6) send-email\n>\n> This is far from ideal, since all my local changes are lost.\n\nNot offering any answer, but it is unclear to me what local changes\nyou are losing here.  Care to explain?\n"},{"id":"205352","messageId":"50D49C81.5060007@gmail.com","threadId":"32427","inReplyTo":"7vvcbv1grr.fsf@alter.siamese.dyndns.org","subject":"Re: recommendation for patch maintenance","fromName":"Manlio Perillo","fromEmail":"manlio.perillo@gmail.com","sentAt":"2012-12-21T17:29:37Z","receivedAt":"2012-12-21T17:29:37Z","isPatch":false,"sender":{"key":"manlio.perillo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6217088?v=4"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nIl 21/12/2012 18:01, Junio C Hamano ha scritto:\n> Manlio Perillo <manlio.perillo@gmail.com> writes:\n> \n>> I would like to have advices about some possible workflows to use when\n>> maintaining a patch, that can evolve over the time (fixing bugs, and\n>> applying advices from reviewers).\n>>\n> [...]\n>> when I need to update the patch:\n>>\n>>   1) modify code\n>>   2) commit --amend\n>>   3) format-patch --subject-prefix=\"PATCH v<n>\" \\\n>>      --output=mp/complete-patch master\n>>   4) edit patch to add a list of what was changed\n>>   5) review the patch\n>>   6) send-email\n>>\n>> This is far from ideal, since all my local changes are lost.\n> \n> Not offering any answer, but it is unclear to me what local changes\n> you are losing here.  Care to explain?\n\nI lose the history of all the changes I have made to produce the final\nversion of a patch.\n\nSince for every new version of a patch I do a commit --amend, I can not\nsee, as an example, the changes I have made between x and y versions of\na patch.\n\nOf course the commits are not really lost, but I have to search them\nusing the reflog.\n\n\nThanks   Manlio\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.10 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\n\niEYEARECAAYFAlDUnIAACgkQscQJ24LbaUTf0QCfX9WtA+/GLzVWDJFPbLMCPucJ\nbKQAnj0HJuQs9SVCPV/TlDXcpGDqIqfD\n=lhZ5\n-----END PGP SIGNATURE-----\n"},{"id":"205359","messageId":"7vip7v1d96.fsf@alter.siamese.dyndns.org","threadId":"32427","inReplyTo":"50D49C81.5060007@gmail.com","subject":"Re: recommendation for patch maintenance","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-21T18:17:09Z","receivedAt":"2012-12-21T18:17:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Manlio Perillo <manlio.perillo@gmail.com> writes:\n\n> I lose the history of all the changes I have made to produce the final\n> version of a patch.\n>\n> Since for every new version of a patch I do a commit --amend, I can not\n> see, as an example, the changes I have made between x and y versions of\n> a patch.\n>\n> Of course the commits are not really lost, but I have to search them\n> using the reflog.\n\nYeah, these days with \"rebase -i\" that does not leave individual\nsteps as separate reflog entries, for an easy series, you can do\nthings like:\n\n    $ git rebase -i ;# work on polishing the series\n    $ git show-branch -g ;# view where it diverged\n    $ git diff HEAD~4 @{1}~4\n\nOf course you can plan ahead (this is what I usually do when working\non a series that is not \"how about this\" throw-away patch I send to\nthis list all the time) and name the topic \"topic-v1\", fork the new\nround \"topic-v2\", \"topic-v3\", etc. and do things like\n\n    $ sh -c 'git diff topic-v2~$1 topic-v3~$1' - 4\n\n(the point being that then you do ^P or whatever shell command\nhistory mechanism to recall that line, edit \"4\" to \"3\" and rerun the\ncomparison for other corresponding ones).\n\nOn a related but different front, I've been thinking about improving\nthe \"format-patch --subject-prefix\" mechanism to make it even easier\nto use.  With the current interface, when you prepare your reroll,\nyou would do:\n\n    $ git format-patch --cover-letter \\\n        --subject-prefix='PATCH v4' -o ./+mp master\n\nand end up overwriting the patches from the previous round (if their\nsubject did not change).  You will always overwrite the cover\nbecause its subject never changes and that is where the filename is\ntaken from.\n\nWhat if we added another option, say --reroll $n (or -v$n), to let\nyou write:\n\n    $ git format-patch --cover-letter -v4 -o ./+mp master\n\nthat produces output files named like:\n\n    ./+mp/v4-0000-cover-letter.txt\n    ./+mp/v4-0001-git-completion.bash.add-support-for-pa.txt\n\nwith the subject '[PATCH v4]' prefix?\n\nThen you can transplant the cover letter material from the cover\nletter from the older iteration to the new cover letter in your\neditor, and sending them out will become\n\n    $ git send-email ... ./+mp/v4-*.txt\n\nHmm?\n"},{"id":"205373","messageId":"50D4D511.4010003@gmail.com","threadId":"32427","inReplyTo":"7vip7v1d96.fsf@alter.siamese.dyndns.org","subject":"Re: recommendation for patch maintenance","fromName":"Manlio Perillo","fromEmail":"manlio.perillo@gmail.com","sentAt":"2012-12-21T21:30:57Z","receivedAt":"2012-12-21T21:30:57Z","isPatch":false,"sender":{"key":"manlio.perillo@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6217088?v=4"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nIl 21/12/2012 19:17, Junio C Hamano ha scritto:\n> [...]\n> Of course you can plan ahead (this is what I usually do when working\n> on a series that is not \"how about this\" throw-away patch I send to\n> this list all the time) and name the topic \"topic-v1\", fork the new\n> round \"topic-v2\", \"topic-v3\", etc. and do things like\n> \n>     $ sh -c 'git diff topic-v2~$1 topic-v3~$1' - 4\n> \n> (the point being that then you do ^P or whatever shell command\n> history mechanism to recall that line, edit \"4\" to \"3\" and rerun the\n> comparison for other corresponding ones).\n> \n\nThanks, this seems fine.\nMaybe topic-v2 --> topic/v2 (it looks better to me).\n\n> On a related but different front, I've been thinking about improving\n> the \"format-patch --subject-prefix\" mechanism to make it even easier\n> to use.\n>\n> [...]\n>\n> What if we added another option, say --reroll $n (or -v$n), to let\n> you write:\n> \n>     $ git format-patch --cover-letter -v4 -o ./+mp master\n> \n> that produces output files named like:\n> \n>     ./+mp/v4-0000-cover-letter.txt\n>     ./+mp/v4-0001-git-completion.bash.add-support-for-pa.txt\n> \n> with the subject '[PATCH v4]' prefix?\n> \n\nI think it is a good idea to reduce the things one have to do by hand.\nI, too, was thinking something similar, with a -v$n option.\n\nAnd, from these few days I have started to follow the mailing list, it\nseems that '[PATCH v$n'] is the standard practice.\n\n\nBy the way, I would also like to be able to set the default value for\nthe --output option in config file; something like:\n\n  [format]\n  output = +mp/$(git symbolic-ref --short HEAD)\n\nwhere the string will be processed by the shell:\n\n   sh -c 'printf \"+mp/$(git symbolic-ref --short HEAD)'\"\n\nNote that printf is POSIX, and the standard suggests to use it instead\nof echo:\nhttp://pubs.opengroup.org/onlinepubs/9699919799/utilities/echo.html\n\nI have read the affected source code, and it should not be too hard.\nWhat do you think?\n\nI should be able to hack the patch in the weekend, but I'm not sure it\nwill be accepted.\n\n> Then you can transplant the cover letter material from the cover\n> letter from the older iteration to the new cover letter in your\n> editor, and sending them out will become\n> \n>     $ git send-email ... ./+mp/v4-*.txt\n> \n> Hmm?\n\nSeems good.\n\n\nRegards   Manlio\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.10 (GNU/Linux)\nComment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/\n\niEYEARECAAYFAlDU1REACgkQscQJ24LbaUT5dgCgismeh+R3B26otuBIXRf/VUiq\n+5gAoIR56wVfs8Vw8AAWtim4aor97MXN\n=DfeG\n-----END PGP SIGNATURE-----\n"},{"id":"205379","messageId":"CAPc5daXp4cYG_Qy3_n__nSw4F_u73evzm7P1in_74Rs42mNSrg@mail.gmail.com","threadId":"32427","inReplyTo":"50D4D511.4010003@gmail.com","subject":"Re: recommendation for patch maintenance","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-12-21T22:17:11Z","receivedAt":"2012-12-21T22:17:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"On Fri, Dec 21, 2012 at 1:30 PM, Manlio Perillo\n<manlio.perillo@gmail.com> wrote:\n>\n> By the way, I would also like to be able to set the default value for\n> the --output option in config file; something like:\n>\n>   [format]\n>   output = +mp/$(git symbolic-ref --short HEAD)\n>\n> where the string will be processed by the shell:\n>\n>    sh -c 'printf \"+mp/$(git symbolic-ref --short HEAD)'\"\n\nMy knee-jerk reaction is that, while it might make sense to give an\noption to allow users to use a dedicated directory per branch, I am\nnot interested in that form; especially the part that lets the users too\nlong a rope to hang themselves with by allowing an arbitrary shell\nexpansions goes against my taste.\n\nBut you *can* prove me wrong; read on.\n\n> I should be able to hack the patch in the weekend, but I'm not sure it\n> will be accepted.\n\nYou got it backwards, just like many other new people who come and go on\nthis list. If something is very useful, you'd work on it even if the result may\nnot appear immediately in the upstream, and you'd keep maintaining a local\nfork so that you can keep benefiting from it, once you have written such a\nuseful feature (whatever it is). If even the original \"itch-holder\"\ndoes not think\nthat the benefit from his change outweighs the cost of such an effort, why\nshould *I* carry it in my tree?\n\nThe goal of a contributor who comes up with an idea, gets \"It doesn't sound\nlike a good idea\" during the review but disagrees and believes in his idea\nought to be to prove the reviewer(s) wrong by polishing the idea and the\nimplementation so much that the upstream comes begging for your change ;-)\n\nThe core part of the change to add --reroll $n option should be straight-forward\nand will involve a few functions in builtin/log.c, but the existing\ncode is so badly\nstructured that it probably needs a couple of \"preparatory steps\" patch to clean\nup the API between internal functions on that codepath, before the real change\ncan be made, I think.\n"}]}