Merge or Cherry-Pick?

[Dawit A]

On Wed, Feb 2, 2011 at 2:02 AM, Kevin Ottens <ervin at kde.org> wrote:
> On Wednesday 2 February 2011 07:21:44 Dawit A wrote:
>> On Wed, Feb 2, 2011 at 12:58 AM, John Tapsell <johnflux at gmail.com> wrote:
>> >> But how would a similar work flow except there are multiple fixes
>> >> present in the local repo ? How would you push only a single fix in
>> >> such case ?
>> >
>> > git rebase -i origin   #Bring up a list of your changes.
>> >
>> > <Reorder them in the editor so that the commit you want to push is at
>> > the top of the list, save>
>> >
>> > <Fix any conflicts that might have arisen because you reordered the
>> > commits>
>> >
>> > git pull --rebase   #make sure we are up to date
>> >
>> > git log      #copy the SHA of the commit you want to push up to
>> >
>> > git push origin SHA:head   #paste the SHA that you just copied where I
>> > wrote "SHA"
>> >
>> >
>> > Does that make sense?  There are other ways to do it, but this way
>> > avoids most of the common problems.
>>
>> Yes. Great. IMHO that type of documentation is what is needed in techbase.
>>
>> One question though... why would i need to do git rebase -i origin if
>> I always do git pull --rebase in the first place ? Wouldn't simply
>> following the steps you mentioned after "git pull --rebase" suffice
>> since I am going to be using the commit SHA to do the push ?
>
> Because the order matters. git will push everything up to the commit with the
> SHA1 passed as parameter. git rebase -i allows you to reorder your commits
> first.

Ahh... I see. It is push everything upto that commit, not just push
that commit. Ouch! That is almost as much a hassle as the convoluted
method I am following now. Do not commit anything that is not ready to
be pushed into my own local branch. Use git stash to save the
uncommited changes before doing the pull --rebase and apply the
stashed changes after doing the push...