Re: Dealing with an upstream cherry-picked branch

From: Avery Pennarun <apenwarr@gmail.com>
Date: Mar 15, 2010, 23:39 UTC
Message-ID: <32541b131003151639o173669a7v4b3b4c13bc7e153@mail.gmail.com>
In-Reply-To: <76718491003151407p3cdecf8fx1ddebf19ce304f83@mail.gmail.com>

On Mon, Mar 15, 2010 at 4:07 PM, Jay Soffian <jaysoffian@gmail.com> wrote:

Show 14 quoted lines

> On Mon, Mar 15, 2010 at 2:46 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
>>> Jay Soffian wrote:
>>> (c) Create a new branch at point Ma and cherry-pick only the local
>>> commits from local-master past point Ma. This essentially gives me the
>>> clean local-master I would've had if I'd been doing (1) all along.
>>
>> This will work, but the short form for exactly the same operation is:
>>
>>        git checkout -b local-b local-master
>>        git rebase --onto upstream-master upstream-a
>
> Are you sure that will skip the merges into local-master from
> upstream-a? I didn't think so and it's not my recollection based on
> using --onto previously.

It should. The --onto option is rather confusing to get right, and because git is pretty smart, sometimes the rebase will end up doing what you want (maybe with some extra conflicts) *despite* using the wrong (or no) --onto option.

Basically, the 'upstream-a' option above means "remove everything that's in upstream-a" and then the --onto option means "and then paste what's left on top of upstream-master". Since your merge commits only add things from upstream-a, they too should be left out of the rebase.

Sometimes I find this gets confusing. You can often sort it out by using 'rebase -i' (with otherwise the same options as above) and tweaking it a little. But the upstream-a commits should definitely all be gone.

Have fun,

Avery