Re: Why rebase with preserve merges asks for merged commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

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

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux