[LRUG] git question

[Murray Steele]

2009/8/20 Taryn East <teast at globalpersonals.co.uk>

>
>
> 2009/8/20 Chris Mear <chris at feedmechocolate.com>
>
> 2009/8/20 Taryn East <teast at globalpersonals.co.uk>
>>
>>>
>>>
>>> 2009/8/20 Chris Mear <chrismear at gmail.com>
>>>
>>>> On 20 Aug 2009, at 12:38, Taryn East wrote:
>>>>
>>>>  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
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Ah. Were you working directly on the master branch, and then doing git
>>>> pull to get up-to-date?
>>>>
>>>> In other words, does gitk look like this:
>>>>
>>>> http://feedmechocolate.com/stuff/mergingmaster.png
>>>>
>>>
>>> yep - that's it exactly :)
>>>
>>>  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.
>>>
>>>
>>> cool - so at least I know how I got into the opriginal mess... and now I
>>> know how to work on a branch.
>>>
>>>
>>> So as long as I work on a fork what would be the steps to making a patch?
>>>
>>> branch... commit, commit, commit, pull+rebase... then what?
>>>
>>> form-patch for all commits in the branch?
>>> would that apply to the upstream (ie rails/rails) or just my fork?
>>>
>>
>> Yup, that's right. The key step is that when you do:
>>
>> rebase master
>>
>> 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:
>>
>> git format-patch master --stdout > patch.diff
>>
>
> 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.
> If this is the case - why? If not - how would you do that?
>
> 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.
>

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.

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.

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.

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.

Muz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20090820/848dbed8/attachment.html>