[LRUG] git question

[Chris Mear]

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.
>

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.

Then, there's the question of how independent the features are, and whether
you really want to keep them together on one branch.

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.

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.

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.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20090820/579ce414/attachment-0003.html>