2009/8/20 Taryn East <span dir="ltr"><<a href="mailto:teast@globalpersonals.co.uk">teast@globalpersonals.co.uk</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><br><div class="gmail_quote">2009/8/20 Chris Mear <span dir="ltr"><<a href="mailto:chris@feedmechocolate.com" target="_blank">chris@feedmechocolate.com</a>></span><div><div></div><div class="h5"><br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">

<div>2009/8/20 Taryn East <span dir="ltr"><<a href="mailto:teast@globalpersonals.co.uk" target="_blank">teast@globalpersonals.co.uk</a>></span><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">


<br><br><div><div></div><div><div class="gmail_quote"><div>2009/8/20 Chris Mear <span dir="ltr"><<a href="mailto:chrismear@gmail.com" target="_blank">chrismear@gmail.com</a>></span><br></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">



<div>On 20 Aug 2009, at 12:38, Taryn East wrote:<div><br>
<br>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
I do/did... but you can't use gitk to make patches... which would have made sense to me. In my mind I could "cherry pick" the commits I wanted in the patch and that would be nice... but it doesn't work that way :P<br>




<br>
In the end I basically hand-copied the SHA1 ids of the commits I'd made (because there was all the cruft in there from rails/rails... pages and pages of it that had been done in the meantime) and then used those to feed into git-log -p for the patch.<br>




</blockquote>
<br></div></div><div>
Ah. Were you working directly on the master branch, and then doing git pull to get up-to-date?<br>
<br>
In other words, does gitk look like this:<br>
<br>
<a href="http://feedmechocolate.com/stuff/mergingmaster.png" target="_blank">http://feedmechocolate.com/stuff/mergingmaster.png</a></div></blockquote><div><br>yep - that's it exactly :) <br><br></div><div>
<blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">


If so, git pull would be doing merges for you, which isn't what you want -- it ends up with the interleaved scenario you seem to be describing.</blockquote></div><div><br>cool - so at least I know how I got into the opriginal mess... and now I know how to work on a branch.<br>



<br><br>So as long as I work on a fork what would be the steps to making a patch?<br><br>branch... commit, commit, commit, pull+rebase... then what? <br><br>form-patch for all commits in the branch? <br>would that apply to the upstream (ie rails/rails) or just my fork?<br>


</div></div></div></div></blockquote><div><br></div><div>Yup, that's right. The key step is that when you do:</div><div><br></div><div>rebase master</div><div><br></div><div>that 'master' needs to be the latest commit in rails/rails. If you're pulling from rails/rails into your local master, then that'll be the case. Then you're all set to do:</div>


<div><br></div><div>git format-patch master --stdout > patch.diff</div></div></blockquote></div></div><div><br>there seems to be another implied "key", in the above, that being that you have to make patches as you go along (ie "make a patch from everything I've done so far up until the current head (after rebasing)") - you don't seem to be able to make a set of patches after this.<br>

If this is the case - why? If not - how would you do that?<br><br>Use case: you start work on a big feature - then you find out at alater point that your feature is actually two smaller features, one of which is acceptable and the other is debatable. So you need two patches.<br>
</div></div></blockquote><div><br></div><div>You can just pass a range to git format-patch to get a patch just for a specific sequence of commits. Of course, that depends on each feature's commits being all together, and no commits containing work that applies to both features. To get neat patches/commits like this, you can do full-scale rewriting of history with rebase's --interactive option. It lets you specify commits you'd like to 'edit', and you can reorder the list of commits as you please.</div>
<div><div><br></div><div>Then, there's the question of how independent the features are, and whether you really want to keep them together on one branch.</div><div><br></div><div>If the features were somewhat dependent on each other (e.g. one acceptable feature, plus some debatable additions that build on that and don't make sense to be applied to master on their own), then I'd keep it all on one branch, organise them using rebase --interactive, then pass ranges to git format-patch to get a separate patches for each feature's commits.</div>
<div><br></div></div><div>If it turned out I'd actually been mixing work on two utterly independent features, then I probably want to split them into two separate branches. Starting with the above reorganisation, a rebase --onto can be used to grab one feature's commits from the tip of my branch and shove them over into a branch of their own off master.</div>
<div><br></div><div>Rewriting history is sometimes seen as the evil voodoo of Git, and it does sound awfully involved at first. But it's really just an in-system equivalent of tidying up messy commits before submission by manually editing patches, with the advantage that you get to keep your new tidy history. And you can always 'undo' using git reflog.</div>
<div><br></div><div>Chris</div><div><br></div></div>