<br><br><div class="gmail_quote">2009/8/20 Chris Mear <span dir="ltr"><<a href="mailto:chris@feedmechocolate.com">chris@feedmechocolate.com</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">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 class="h5"><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><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>
<br>Cheers,<br>Taryn<br></div></div>