Re: flatten-merge history

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: flatten-merge history

From: Andreas Schwab <hidden>
Date: 2016-06-15 23:02:47

Henning Moll [off-list ref] writes:
1. For P, A is the nearest prior commit on 'master'
2. on master: git rebase -i A^
3. change A from pick to edit. save. quit
4. git merge P
5. git rebase --continue

From the perspective of 'master' this worked. But as all of the commits
have been rewritten, the branches b1 and b2 no longer refer to
'master'. Branch b2, for example, still branches off at B and not B'.
You only rebased master, so b1 and b2 were unchanged.  If you want to
change b1 and b2 you have to rebase them as well.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: flatten-merge history

From: Christian Couder <hidden>
Date: 2016-06-15 23:02:47

On Sun, Oct 26, 2014 at 4:19 PM, Andreas Schwab [off-list ref] wrote:
Henning Moll [off-list ref] writes:
quoted
1. For P, A is the nearest prior commit on 'master'
2. on master: git rebase -i A^
3. change A from pick to edit. save. quit
4. git merge P
5. git rebase --continue

From the perspective of 'master' this worked. But as all of the commits
have been rewritten, the branches b1 and b2 no longer refer to
'master'. Branch b2, for example, still branches off at B and not B'.
You only rebased master, so b1 and b2 were unchanged.  If you want to
change b1 and b2 you have to rebase them as well.
Yeah. Henning, when interactively rebasing, in our editor, you should
have something like:

pick A
pick P
pick B
pick Q
pick C
pick D
pick R
pick E

which should work without any conflict.
And then you can rebase the b1 and b2 branches on the resulting branch.

Best,
Christian.

Re: flatten-merge history

From: Henning Moll <hidden>
Date: 2016-06-15 23:02:47

Am 26.10.2014 um 20:02 schrieb Christian Couder:
Yeah. Henning, when interactively rebasing, in our editor, you should 
have something like: pick A pick P pick B pick Q pick C pick D pick R 
pick E which should work without any conflict. And then you can rebase 
the b1 and b2 branches on the resulting branch.
Thank you all very much. It worked!

I didn't know that i could also introduce new commits in the interactive 
rebase list. Just for the record, in case others need to do such a task:

intial situation:

     P - - - Q - - - - - R       <-extern

A - - - B - - - C - D - - - E   <-master
          \           \
           M ...       \         <-b1
                        \
                         W ...   <-b2

On master:
$ git rebase -i --root

(editor opens showing

pick A
pick B
pick C
pick D
pick E

modify this to

pick A
pick P
pick B
pick Q
pick C
pick D
pick R
pick E

save, quit. Now, master is already fixed. Now fix the branches:

$ git rebase --onto B' B b1
$ git rebase --onto D' D b2

Just a final question: Is it possible to keep the GIT_COMMITTER_DATE in 
all those rebases?

Thanks again
Henning
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help