<br><div class="gmail_quote">2009/8/20 Taryn East <span dir="ltr"><<a href="mailto:teast@globalpersonals.co.uk">teast@globalpersonals.co.uk</a>></span><br><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>What I'd do here is create 2 other branches (off master); one for each patch. Then for each patch-branch I'd cherry-pick the commits from my original work branch that provide the functionality for that patch. Then proceed as previously described. </div>
<div><br></div><div>Assuming the 2 patches are actually inter-related and the split into 2 patches is not because they're actually 2 completely different features I'd probably still keep doing all the work in the main branch and then cherry-pick the commits I need for each patch to their patch-branches. If the features are independent though, I'd just delete the original main branch and continue working on the features in their individual patch-branches. </div>
<div><br></div><div>This might seem like overkill, or awfully round-about, but it does mean you keep the work, patches and master all separate, which is something I like. It's probably possible to do it all with one branch and crazy git-fu though.</div>
<div><br></div><div>For creating the actual patches I prefer a single commit, so I'd create further branches from my patch-branches and squash the diff between the patch-branch and master into it and use it for the purposes for git format-patch. Once the patch is generated you can delete this merge-squash branch. Again, this might be possible without the extra merge-squash branch, but I'm not nearly git-y enough.</div>
<div><br></div><div>Muz</div></div><br>