Re: question concerning branches

From: Andreas Ericsson <ae@op5.se>
Date: Aug 20, 2009, 07:33 UTC
Message-ID: <4A8CFC44.8050707@op5.se>
In-Reply-To: <4a8c4ece@wupperonline.de>

Ingo Brueckl wrote:

Show 25 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
> 
>> This is one of the most useful features.
> 
> Wow. I'm sursprised to hear that, because I consider it at the moment as a
> very strange one.
> 
>> For example, it is an essential
>> part of supporting the workflow described here:
>>     http://gitster.livejournal.com/25892.html
> 
> Here is what I'd expect to do with git (described with my own words, not in
> git commands):
> 
> 1. commit the quick fix to the release branch
> 2. push this single commit to origin and master
> 
> Now that all branches have the commit a later push and pull should notice
> this and "skip" it.
> 
> This leads to a second question I have. Assuming I have three patches in my
> repo (#1, #2 and #3), is it possible to push only #2 (because it is a
> quick fix) and later, maybe after I committed #4, the rest, i.e. #1, #2 and
> #4?
>

If they're on different branches, yes. If they're on the same branch, no. This is because a commit in git is named uniquely not only by its contents, but also by its ancestry.

You can, however, run "git rebase --interactive" and re-order the commits before you push them, so that #2 becomes #1 and vice versa. Then you can push only #1 (the old #2) while leaving #2 (the old #1), #3 and #4 on your machine only. This involves knowing the commit identifier of #1 though. Assuming it's "deadbeef", you can update the remote branch "foo" to hold your new commit by running the following command:

  git push <remote> deadbeef:refs/heads/foo

HTH

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.