{"thread":{"id":"9856","subject":"Mailing patch series'","startedAt":"2007-09-15T01:06:35Z","lastAt":"2007-09-15T16:44:26Z","messageCount":3,"participants":["Russ Brown","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"53086","messageId":"46EB301B.8050602@gmail.com","threadId":"9856","inReplyTo":null,"subject":"Mailing patch series'","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-15T01:06:35Z","receivedAt":"2007-09-15T01:06:35Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Hi,\n\nI've noticed the method of mailing series' of patches on this mailing\nlist, and I'd like to know a little more about how it's done, as I'm\nconsidering how well it might work for us as a workflow and review process.\n\nParticularly, where does the series of patches come from? Is this a\nusage scenario for stacked git (something else I don't fully understand\nthe rationale behind as yet)? I'm imagining the developer has a local\nbranch to which he commits his changes, and then rebases resulting in\nhis branches being at the end of the local branch. How are they then\nextracted and mailed out?\n\nMy next question, is supposing that the patches are reviewed and changes\nsuggested. How does the developer then go about amending, say the second\npatch and getting the subsequent ones rebased off that? I'm assuming\nthere's a nice clever way of doing it that doesn't involve manually\nmessing with individual patch files etc.\n\nPlease excuse my ignorance: I'm still getting my head around this. Once\nI do that I'm usually away and happy, but it takes a while for that\n'click' moment to hit me sometimes :)\n\nThanks.\n\n-- \n\nRuss\n"},{"id":"53087","messageId":"20070915023518.GX3099@spearce.org","threadId":"9856","inReplyTo":"46EB301B.8050602@gmail.com","subject":"Re: Mailing patch series'","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-09-15T02:35:18Z","receivedAt":"2007-09-15T02:35:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Russ Brown wrote:\n> I've noticed the method of mailing series' of patches on this mailing\n> list, and I'd like to know a little more about how it's done, as I'm\n> considering how well it might work for us as a workflow and review process.\n> \n> Particularly, where does the series of patches come from?\n\nUsually from Git itself, as in each Git commit is turned into its\nown email message by `git format-patch` which can then be sent by\n`git send-email` or your favorite mail client.\n\n> Is this a\n> usage scenario for stacked git (something else I don't fully understand\n> the rationale behind as yet)?\n\nYes, its one of them. When you are editing a series of patches that\nyou want someone to read as a linear \"conversation\" it can help to\nuse StGIT as you can reorder the commits (messages/patches) at will\nand edit any of them at any time. guilt is another excellent tool\nthat also can be used here.\n\nI actually just use core Git itself with `git rebase -i` when I need\nto perform ordering/editing before sending. I like the interface it\noffers, its fast enough for my needs, and well, I'm just so used to\nthe bare plumbing of Git that I think in terms of the DAG operators.\nI've heard wonderful things about both StGIT and guilt, but they\naren't this particular developer's cup of tea.\n\n> I'm imagining the developer has a local\n> branch to which he commits his changes, and then rebases resulting in\n> his branches being at the end of the local branch. How are they then\n> extracted and mailed out?\n\ngit-format-patch takes one of two variations of arguments: either\na single commit or a range of commits. The most common usage is\nin the single commit case.\n\nWhen given a single commit git-format-patch creates a message for\neach commit on the current branch that is after the supplied commit.\nThe second case (range of commits) it creates a message for each\ncommit in that range.\n\nSo when I start developing a topic I branch off Junio's master,\nwhich I happen to fetch into refs/remotes/jc/master (as I had\npreviously done `git remote add jc $url`):\n\n\tgit checkout -b fetch-pack-fixes jc/master\n\n jc/master\n fetch-patch-fixes\n /\n -o-o-o-B\n\nThen I do my development... and rebase against Junio before sending:\n\n\tgit fetch jc\n\n fetch-patch-fixes\n /\n -o-o-o-B-m1-m2-m3-m4-m5 jc/master\n \\ /\n o-o-o-o-o-o-o-o-o-C\n\n\tgit rebase jc/master\n\n -o-o-o-B jc/master fetch-patch-fixes\n \\ / /\n o-o-o-o-o-o-o-o-o-C-m1'-m2'-m3'-m4'-m5'\n\nNow I retest my series and send it to Junio:\n\n\tgit format-patch --stdout jc/master >mbox\n\tmutt -f mbox\n\nWhen mutt (my preferred mail client) starts it is loading a mailbox\nwith one email message per commit. Only the commits on my current\nbranch (m1'-m5') that don't appear in jc/master (my tracking branch\nof Junio's master) will be formatted into mbox. That is only my\nwork that I haven't sent yet.\n\nI (re)review each commit and then a macro sends the message on\nits way. To help me preaddress the emails I have the following\nin .git/config:\n\n\t[format]\n\t headers = \"To: Junio C Hamano \\n\"\n\t headers = \"Cc: git@vger.kernel.org\\n\"\n\nThat way the messages have proper To/Cc lines automatically entered\nand the mutt macro is really just to trigger sending the message.\n\nFinally I leave that branch alone. If I want to make further changes\nI actually fork off it and start a new branch:\n\n\tgit checkout -b fetch-pack-fixes2 fetch-pack-fixes\n\nAs now when I send this new branch I can use:\n\n\tgit format-patch --stdout fetch-pack-fixes >mbox\n\tmutt -f mbox\n\nTo send only the commits since the last series that I sent. If my\nwork is worthy these commits will eventually come back during a\nlater fetch from Junio. I look for my work using `git log` and\n`git cherry` and delete the branches that Junio has fully merged in.\n\nI don't actually quite use all of those commands by hand; I have a\nproper wrapper script that I've put together to automate remembering\nwhat I last sent, defaulting to \"jc/master\", and to run the pipeline\nof format-patch and mutt.\n\n> My next question, is supposing that the patches are reviewed and changes\n> suggested. How does the developer then go about amending, say the second\n> patch and getting the subsequent ones rebased off that? I'm assuming\n> there's a nice clever way of doing it that doesn't involve manually\n> messing with individual patch files etc.\n\nUse StGIT, guilt, or `git rebase -i jc/master` to go back and edit\nthe necessary patches in the series, then resubmit the entire series.\nOr just the changed ones and the later ones, depending on what got\nmerged upstream already.\n\nIf you edit something in a particular change you can cause\nmerge conflicts when the other commits are pushed on top/picked\n(terminology depending on your tool of choice). But you should\nthen get a merge conflict and be able to fix it up.\n\n-- \nShawn.\n"},{"id":"53131","messageId":"46EC0BEA.6060608@gmail.com","threadId":"9856","inReplyTo":"20070915023518.GX3099@spearce.org","subject":"Re: Mailing patch series'","fromName":"Russ Brown","fromEmail":"pickscrape@gmail.com","sentAt":"2007-09-15T16:44:26Z","receivedAt":"2007-09-15T16:44:26Z","isPatch":false,"sender":{"key":"pickscrape@gmail.com","avatar":null},"body":"Shawn O. Pearce wrote:\n> Russ Brown wrote:\n>> I've noticed the method of mailing series' of patches on this mailing\n>> list, and I'd like to know a little more about how it's done, as I'm\n>> considering how well it might work for us as a workflow and review process.\n>>\n>> Particularly, where does the series of patches come from?\n> \n> Usually from Git itself, as in each Git commit is turned into its\n> own email message by `git format-patch` which can then be sent by\n> `git send-email` or your favorite mail client.\n> \n\n\nShawn, thank you very much for your extremely detailed and helpful\nexplanation. It's given me plenty of food for thought!\n\nThanks again!\n\n-- \n\nRuss\n"}]}