{"thread":{"id":"9291","subject":"Submit/Workflow question","startedAt":"2007-07-29T15:56:54Z","lastAt":"2007-07-29T17:21:27Z","messageCount":5,"participants":["David Kastrup","J. Bruce Fields","Jason Sewall"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"48990","messageId":"85abtfw6d5.fsf@lola.goethe.zz","threadId":"9291","inReplyTo":null,"subject":"Submit/Workflow question","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-29T15:56:54Z","receivedAt":"2007-07-29T15:56:54Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\nSuppose that I have created a half-baked patch A suiting my personal\nneeds and went on from there, having something like\n\n...->A->B->...\n\nNow at some point of time I decide that really A should be made fit\nfor submission. Basically, I'd want to do\ngit-reset --hard A\n[edit some]\ngit-commit --amend -a\ngit-format-patch HEAD~1\n\nin order to arrive at a nice submittable patch. However, I don't want\nto lose B and the following stuff, and the resulting HEAD should\ninclude the improved of A (it is fine if that needs additional steps,\nand it is fine if it is just HEAD that gets the fixed version, not B).\n\nSo how to do this? Branch at A^, rebase on A, fix the stuff, commit\nwith --amend -a, rebase on master, rename the temporary branch to\nmaster (killing the old master), format and submit the patch?\n\nOr is there some bad thinko in there? Or is this too complicated?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48992","messageId":"856443w626.fsf@lola.goethe.zz","threadId":"9291","inReplyTo":"85abtfw6d5.fsf@lola.goethe.zz","subject":"Re: Submit/Workflow question","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-29T16:03:29Z","receivedAt":"2007-07-29T16:03:29Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"David Kastrup writes:\n\n> Suppose that I have created a half-baked patch A suiting my personal\n> needs and went on from there, having something like\n>\n> ...->A->B->...\n>\n> Now at some point of time I decide that really A should be made fit\n> for submission. Basically, I'd want to do\n> git-reset --hard A\n> [edit some]\n> git-commit --amend -a\n> git-format-patch HEAD~1\n>\n> in order to arrive at a nice submittable patch. However, I don't want\n> to lose B and the following stuff, and the resulting HEAD should\n> include the improved of A (it is fine if that needs additional steps,\n> and it is fine if it is just HEAD that gets the fixed version, not B).\n>\n> So how to do this? Branch at A^, rebase on A, fix the stuff, commit\n> with --amend -a, rebase on master, rename the temporary branch to\n> master (killing the old master), format and submit the patch?\n>\n> Or is there some bad thinko in there? Or is this too complicated?\n\nUh, too many rebases.\n\nI mean:\n\nBranch at A^, merge A, fix the stuff, commit with --amend -a, merge\nmaster, rename the temporary branch to master (killing the old\nmaster), format and submit the patch?\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48991","messageId":"20070729160347.GA26637@fieldses.org","threadId":"9291","inReplyTo":"85abtfw6d5.fsf@lola.goethe.zz","subject":"Re: Submit/Workflow question","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-07-29T16:03:47Z","receivedAt":"2007-07-29T16:03:47Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Sun, Jul 29, 2007 at 05:56:54PM +0200, David Kastrup wrote:\n> \n> Suppose that I have created a half-baked patch A suiting my personal\n> needs and went on from there, having something like\n> \n> ...->A->B->...\n> \n> Now at some point of time I decide that really A should be made fit\n> for submission. Basically, I'd want to do\n> git-reset --hard A\n> [edit some]\n> git-commit --amend -a\n> git-format-patch HEAD~1\n> \n> in order to arrive at a nice submittable patch. However, I don't want\n> to lose B and the following stuff, and the resulting HEAD should\n> include the improved of A (it is fine if that needs additional steps,\n> and it is fine if it is just HEAD that gets the fixed version, not B).\n> \n> So how to do this? Branch at A^, rebase on A,\n\nJust branch on A. Or actually I just check out A at this point (leaving\nme not on any branch).\n\n> fix the stuff, commit\n> with --amend -a, rebase on master, rename the temporary branch to\n> master (killing the old master), format and submit the patch?\n\nI'm not completely sure I follow that sequence, but something like that\nshould work. A similar approach:\n\n\thttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html#modifying-one-commit\n\nI do something pretty close to what's described there, except I\ngenerally just cut and paste SHA1's instead of making the temporary tag.\n\n--b.\n"},{"id":"48993","messageId":"851werw5wh.fsf@lola.goethe.zz","threadId":"9291","inReplyTo":"20070729160347.GA26637@fieldses.org","subject":"Re: Submit/Workflow question","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-07-29T16:06:54Z","receivedAt":"2007-07-29T16:06:54Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"\"J. Bruce Fields\" writes:\n\n> On Sun, Jul 29, 2007 at 05:56:54PM +0200, David Kastrup wrote:\n>> \n>> Suppose that I have created a half-baked patch A suiting my personal\n>> needs and went on from there, having something like\n>\n> I'm not completely sure I follow that sequence, but something like that\n> should work. A similar approach:\n>\n> \thttp://www.kernel.org/pub/software/scm/git/docs/user-manual.html#modifying-one-commit\n>\n> I do something pretty close to what's described there, except I\n> generally just cut and paste SHA1's instead of making the temporary tag.\n\nThanks.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"48999","messageId":"31e9dd080707291021y5fd258ccobc4fa30e23a9880a@mail.gmail.com","threadId":"9291","inReplyTo":"85abtfw6d5.fsf@lola.goethe.zz","subject":"Re: Submit/Workflow question","fromName":"Jason Sewall","fromEmail":"jasonsewall@gmail.com","sentAt":"2007-07-29T17:21:27Z","receivedAt":"2007-07-29T17:21:27Z","isPatch":false,"sender":{"key":"jasonsewall@gmail.com","avatar":null},"body":"On 7/29/07, David Kastrup wrote:\n>\n> Suppose that I have created a half-baked patch A suiting my personal\n> needs and went on from there, having something like\n>\n> ...->A->B->...\n>\n> Now at some point of time I decide that really A should be made fit\n> for submission.\n\nWhat I do in this sort of situation varies on how good I was about\nkeeping A and B \"independent\"; first of all, let's assume you're not\non 'master', you're on 'some-feature' (and if you weren't, it's easy\nto make it a branch, tho you might have to rebase the branch to the\npoint on master where the patch is meaningful to others, and\noptionally rewind master to keep it clean)\n\nsome-feature: A->B->...\n /\nmaster: ->W->X->Y->Z\n\nIf I really want to edit *just* A and not use any of B at all, then\nthe excellent rebase -i would do the job - you may want to rebase to\nZ, or if A weren't the first commit exclusive to your branch, you\ncould rebase to whatever that is...\n\nThe point is that rebase -i will let you say \"edit just A, just apply\nB afterwards\" and it will rewrite history for you after you fix A, and\nthen it will try to apply B on top of A, and so on until you're done.\n\nSometimes, rebase -i doesn't cut it for me, (because I didn't make my\ncommits cleanly separated, or perhaps because I haven't totally\nexplored rebase) - then I do it the \"old-fashioned way\" which it the\nway this was usually done before rebase -i. I make a temporary branch\noff of master called (apply-some-feature) and I start generating diffs\nbetween this new branch and some-feature. A apply them, sometimes\nreaching across commits and so forth, and commit the changes in nice,\nclean format. When I'm done, *I* usually merge these onto master (if\nits my own project) but if you were going to make it into a patch, I\nwould probably just replace some-feature with apply-some-feature.\n\nIt's probably pretty self-evident, but (git) diff (and some sort of\nvisual patch-applier) is pretty powerful and you can generate very\n\"narrow\" diffs to look at just the parts you want to for a given step\nin this process. And of course, you can use to to make sure that at\nthe end, apply-some-feature and some-feature's HEADS have the same\ntree (or not, if you chose to omit some debugging stuff as I often\ndo).\n\nBy the way, the way Bruce suggested was fine too, I just though I'd\nshare what I do in this sort of situation (and I do it often because I\nalways forget to make my commits clean the first time)\n\nJason\n"}]}