Re: Why rebase with preserve merges asks for merged commits

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 21, 2008, 13:14 UTC
Message-ID: <alpine.LSU.1.00.0803211410310.4124@racer.site>
In-Reply-To: <20080321125650.GA4587@alea.gnuu.de>

Hi,

On Fri, 21 Mar 2008, Jörg Sommer wrote:

Show 16 quoted lines

> Think of the following situation:
> 
> M----------U          to-be-preserved
>  \          \
>   `--A---B---+---C    squash-and-preserve-merges
> 
> When I do a rebase M..C with preserve merges I can decide about all commits
> including U which came in with the merge.
> 
> U  pick 9604163 unrelated
> A  pick 5ef0364 SaPM-1
> B  pick 22aadcf SaPM-2
> +  pick 828f7d8 Merge branch 'to-be-preserved' into squash-and-preserve-merges
> C  pick 2a15a54 SaPM-3
> 
> Why I can decide about the commit U from the branch to-be-preserved?

Well, -p obviously does not take the commits (it takes a superset in your case) you would expect it to take. I am not sure if that is always the correct thing to assume, though.

In the short run, you can do it manually by

	$ git checkout B
	$ git rebase --onto branch1 M
	$ git merge U
	$ git cherry-pick C

Ciao, Dscho

P.S.: Oh, BTW, just as in German, you have to put the verb before a subject in an English question.