{"thread":{"id":"38261","subject":"About my git workflow; maybe it's useful for others","startedAt":"2014-12-30T00:22:07Z","lastAt":"2015-04-22T20:38:31Z","messageCount":5,"participants":["Stefan Beller","Thiago Farina"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"254175","messageId":"CAGZ79kaK-uRAE9-rH=-5t8djAw5e9rwkPjZuw=+XWEq+V6R5Yg@mail.gmail.com","threadId":"38261","inReplyTo":null,"subject":"About my git workflow; maybe it's useful for others","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2014-12-30T00:22:07Z","receivedAt":"2014-12-30T00:22:07Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"Hi,\n\nso I have been sending commits to the git mailing list occasionally\nfor quite some time. In the last couple of weeks I send more and more\npatches to the mailing list as it's part of my job now. Here is a\ncollection of practices I am following (or want to follow) and they\nseem to be effective.\n\nMost of this is already documented in various documents in Documentation/*\nand this email is no news for the regular contributors. It may help new comers\nthough.\n\n* Split patches up into logical pieces as you go.\n\nIt's easy to go wild and after hours of hacking you have implemented a cool new\nfeature. This the natural flow of hacking as it's the most fun. But\nthis approach\nis not easy to be reviewed. So let me explain how reviewing works in\nthe git project.\n\n Reviewing works in the git project is quite liberal, anybody\nis encouraged to\n comment on patches flying by. Junio, the maintainer then\ndecides which patches\n he picks up and merges them into the various stages of git\n(pu, next, master, maint).\n The decision which patches are worth for inclusion is based on\nthe amount of discussion\n by the community and generally a patch only makes it if a\nconcensus is met.\n\n* git send-email is the only email client I trust for sending patches\n\n While mail clients such as Thunderbird or the gmail interface are optimized\n to be used by everyday people it behaves differently than you would expect.\n For example these mail clients may convert tabs to white spaces depending on\n the configuration. The default configuration is usually not sane.\n To avoid that I tend to use git send-email only when sending patches\nto the list.\n\n Here is my setup:\n git send-email needs a SMTP client to talk to a server, as I am using Ubuntu\n I need to \"apt-get install msmtp\". Then there is a configuration file\n.msmtprc which reads:\n\n defaults\n tls on\n # this may be different in other distributions:\n tls_trust_file /usr/share/ncat/ca-bundle.crt\n logfile ~/.msmtp.log\n account gmail\n host smtp.gmail.com\n port 587\n from @gmail.com\n auth on\n user @gmail.com\n password \n # Set a default account\n account default : gmail\n\n The git configuration for sending email via msmtp is\n git config --global sendemail.smtpserver /usr/bin/msmtp\n git config --global sendemail.smtpuser \n git config --global sendemail.from \n\n* Keep notes between different versions of your patch\n\n Look into the man page of git notes for the configuration variables. The only\n thing requried should be\n\n git config notes.rewriteRef refs/notes/*\n\n to enable keeping notes during a rebase.\n\n* Make sure you're not embarassed by the patches you send out\n\n I fail this talking point often. Write a patch or incorporate\n just a one line fix and send it off to the list. What could go wrong?\n\n One line fixes and small patches tend to look so easy that you forget\n to compile check or run the test suite, which then promptly breaks.\n To prevent such disasters, I want to do a:\n git rebase origin/master --exec=make --exec=\"make test\"\n before sending the patch series to the list.\n\n* Wait with sending out iterations of patches\n \"patience is a virtue I do not have\"\n\n So you successfully send your patches to the mailing list. By\nsuccessful I both\n mean it worked technically as well as you got actually reviews and comments.\n Usually the comments are feedback how to improve the patch. Now it's easy to\n fall in the trap and fix all the problems the reviewers point out and resend\n the patches again to the list again.\n\n Waiting for roughly 24 hours helps a lot I found out. This brings\nyou the following\n advantages:\n * You may get more comments from people in other time zones.\nGit contributors\n are quite international folks. So it would be impolite to not wait for\n everyone to at least have a look at it. They might be\nsleeping currently.\n * You will find yourself reviewing your patches twice. Once after fixing\n all the problems the review unveiled and once again before sending out\n the new iteration of the patch series.\n\nStefan\n"},{"id":"259829","messageId":"CACnwZYf6-Fh0JZeJZ4j3QOyqRF_2-NKJB06Wh20ipsRmrRN+qw@mail.gmail.com","threadId":"38261","inReplyTo":"CAGZ79kaK-uRAE9-rH=-5t8djAw5e9rwkPjZuw=+XWEq+V6R5Yg@mail.gmail.com","subject":"Re: About my git workflow; maybe it's useful for others","fromName":"Thiago Farina","fromEmail":"tfransosi@gmail.com","sentAt":"2015-04-22T19:38:01Z","receivedAt":"2015-04-22T19:38:01Z","isPatch":false,"sender":{"key":"tfransosi@gmail.com","avatar":"https://avatars.githubusercontent.com/u/970071?v=4"},"body":"On Mon, Dec 29, 2014 at 10:22 PM, Stefan Beller wrote:\n> Hi,\n>\n> so I have been sending commits to the git mailing list occasionally\n> for quite some time. In the last couple of weeks I send more and more\n> patches to the mailing list as it's part of my job now. Here is a\n> collection of practices I am following (or want to follow) and they\n> seem to be effective.\n>\n> Most of this is already documented in various documents in Documentation/*\n> and this email is no news for the regular contributors. It may help new comers\n> though.\n>\n> * Split patches up into logical pieces as you go.\n>\n> It's easy to go wild and after hours of hacking you have implemented a cool new\n> feature. This the natural flow of hacking as it's the most fun. But\n> this approach\n> is not easy to be reviewed. So let me explain how reviewing works in\n> the git project.\n>\n> Reviewing works in the git project is quite liberal, anybody\n> is encouraged to\n> comment on patches flying by. Junio, the maintainer then\n> decides which patches\n> he picks up and merges them into the various stages of git\n> (pu, next, master, maint).\n> The decision which patches are worth for inclusion is based on\n> the amount of discussion\n> by the community and generally a patch only makes it if a\n> concensus is met.\n>\n> * git send-email is the only email client I trust for sending patches\n>\nIMO, sending email is the easiest part.\n\nThe hard begins when you have to edit your patch and resend with the\nreviewers' feedback incorporated. For me that is the most tricky and\nhard part to get right, specially when using GMail as an email client.\n\nHow do you handle that part of the process?\n\n-- \nThiago Farina\n"},{"id":"259833","messageId":"CAGZ79ka1U8SP-7b_Jbm--1j1sz0iHKd+v-WNCASAXH+kystefA@mail.gmail.com","threadId":"38261","inReplyTo":"CACnwZYf6-Fh0JZeJZ4j3QOyqRF_2-NKJB06Wh20ipsRmrRN+qw@mail.gmail.com","subject":"Re: About my git workflow; maybe it's useful for others","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-04-22T19:50:17Z","receivedAt":"2015-04-22T19:50:17Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Apr 22, 2015 at 12:38 PM, Thiago Farina wrote:\n>>\n> IMO, sending email is the easiest part.\n>\n> The hard begins when you have to edit your patch and resend with the\n> reviewers' feedback incorporated. For me that is the most tricky and\n> hard part to get right, specially when using GMail as an email client.\n>\n> How do you handle that part of the process?\n\nI try to have as much in git as possible.\n\nSo when the reviews trickle in, I change my commits (in git) accordingly\nvia rebase and edit and lots of fixup commits. I use git notes\nto keep track of changes from one version to another.\n\nHaving the \"changes of the changes\" in the git notes, I am (in theory)\nalways able to kick out a new version of the patch series with\n\n rm 00* # delete old patches\n git format-patch --notes --coverletter somebranch...HEAD\n edit 0000-cover-letter.patch\n git send-email 00* --to=mailing list --to=John@doe.org --cc=Max@Mustermann.de\n\nwhich is only a few steps, so there is not much to go wrong here.\n\nFor me the biggest thing is to know when to send out new patches.\n(Do I sleep over it and review it again myself,\nor do I just gun it, believing my patches are good this time?)\n\n\n>\n> --\n> Thiago Farina\n"},{"id":"259836","messageId":"CACnwZYcD7ryJqM+85wxka+ViqOfy51bOgyetUEdgY1pcQPJv=A@mail.gmail.com","threadId":"38261","inReplyTo":"CAGZ79ka1U8SP-7b_Jbm--1j1sz0iHKd+v-WNCASAXH+kystefA@mail.gmail.com","subject":"Re: About my git workflow; maybe it's useful for others","fromName":"Thiago Farina","fromEmail":"tfransosi@gmail.com","sentAt":"2015-04-22T19:57:06Z","receivedAt":"2015-04-22T19:57:06Z","isPatch":false,"sender":{"key":"tfransosi@gmail.com","avatar":"https://avatars.githubusercontent.com/u/970071?v=4"},"body":"On Wed, Apr 22, 2015 at 4:50 PM, Stefan Beller wrote:\n> On Wed, Apr 22, 2015 at 12:38 PM, Thiago Farina wrote:\n>>>\n>> IMO, sending email is the easiest part.\n>>\n>> The hard begins when you have to edit your patch and resend with the\n>> reviewers' feedback incorporated. For me that is the most tricky and\n>> hard part to get right, specially when using GMail as an email client.\n>>\n>> How do you handle that part of the process?\n>\n> I try to have as much in git as possible.\n>\n> So when the reviews trickle in, I change my commits (in git) accordingly\n> via rebase and edit and lots of fixup commits. I use git notes\n> to keep track of changes from one version to another.\n>\n> Having the \"changes of the changes\" in the git notes, I am (in theory)\n> always able to kick out a new version of the patch series with\n>\n> rm 00* # delete old patches\n> git format-patch --notes --coverletter somebranch...HEAD\n> edit 0000-cover-letter.patch\n> git send-email 00* --to=mailing list --to=John@doe.org --cc=Max@Mustermann.de\n>\nIs that capable of keeping the next patch set in the same thread that\nstarted when you sent the initial patch? Otherwise things get\ndisconnected.\n\n-- \nThiago Farina\n"},{"id":"259846","messageId":"CAGZ79kb2z+CbHhqrB9xW85n_33V8=iYV3jGf9pCNDX181tm3JA@mail.gmail.com","threadId":"38261","inReplyTo":"CACnwZYcD7ryJqM+85wxka+ViqOfy51bOgyetUEdgY1pcQPJv=A@mail.gmail.com","subject":"Re: About my git workflow; maybe it's useful for others","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-04-22T20:38:31Z","receivedAt":"2015-04-22T20:38:31Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Apr 22, 2015 at 12:57 PM, Thiago Farina wrote:\n> On Wed, Apr 22, 2015 at 4:50 PM, Stefan Beller wrote:\n>> On Wed, Apr 22, 2015 at 12:38 PM, Thiago Farina wrote:\n>>>>\n>>> IMO, sending email is the easiest part.\n>>>\n>>> The hard begins when you have to edit your patch and resend with the\n>>> reviewers' feedback incorporated. For me that is the most tricky and\n>>> hard part to get right, specially when using GMail as an email client.\n>>>\n>>> How do you handle that part of the process?\n>>\n>> I try to have as much in git as possible.\n>>\n>> So when the reviews trickle in, I change my commits (in git) accordingly\n>> via rebase and edit and lots of fixup commits. I use git notes\n>> to keep track of changes from one version to another.\n>>\n>> Having the \"changes of the changes\" in the git notes, I am (in theory)\n>> always able to kick out a new version of the patch series with\n>>\n>> rm 00* # delete old patches\n>> git format-patch --notes --coverletter somebranch...HEAD\n>> edit 0000-cover-letter.patch\n>> git send-email 00* --to=mailing list --to=John@doe.org --cc=Max@Mustermann.de\n>>\n> Is that capable of keeping the next patch set in the same thread that\n> started when you sent the initial patch? Otherwise things get\n> disconnected.\n\nWhen typing it out quickly I forgot the --in-reply-to=\noption for the git send-email\ncommand. The identifier needs to be looked u0p manually, which is\nstill a pain point in my workflow.\n\n>\n> --\n> Thiago Farina\n"}]}