2

How to use --onto along with --rebase-merges - in the given situation.

Current:

C0---C1---C2---C3---C4---C5---C6 (master)
           \              |__________
            \                        \
             F1---F2---F3---F4---F5---M1---F6---F7 (feature)

Goal: I want to get "onto" to C3 while preserving all merges:

C0---C1---C2---C3---C4---C5---C6 (master)
                \         |_______________
                 \                        \
                  F1'--F2'--F3'--F4'--F5'--M1'--F6'--F7' (feature)

The desired result is as if replaying history in feature, except everything starts from C3. The resulting files should be the same in the feature branch before and after the rebase.

When I tried: git rebase -r --onto C3 master:

I get something like this, resulting in dropping C4 and C5 from feature.

C0---C1---C2---C3---C4---C5---C6 (master)
           \    \____________________
            \                        \
             F1---F2---F3---F4---F5---M1'--F6'--F7' (feature)

What am I missing? I have seen a few posts related to --onto already, and I can't say I can work out what is going on here from there.

Shriram V
  • 1,500
  • 2
  • 11
  • 20
  • hi, perhaps this might be of interest https://stackoverflow.com/questions/15915430/what-exactly-does-gits-rebase-preserve-merges-do-and-why#:~:text=As%20with%20a%20normal%20git,replaying%20works%20for%20merge%20commits. – jspcal Oct 26 '21 at 01:15
  • `rebase --rebase-merges --onto C3 C2 feature` is more what you want to say, but you might have to proceed in two stages because of the merge. – matt Oct 26 '21 at 01:58
  • I assume your example is just made up to illustrate your point, but it's a strange example. What would the point be of that change? – TTT Oct 26 '21 at 04:10
  • @TTT: Well, what I am doing is a bit more complicated. My branch history becomes messy after `C3` with more `feature` sub `feature-s1`, `feature-s2`. Each of these keep merging in stuff from the master at regular intervals. `feature-s`* also merge between themselves. In the end all sub branches merge into `feature`. I do want to a simply rebase `feature` before they go onto `master`. But the changes show up too complicated conflicts. So to reduce the severity of the conflicts, I was trying to replay history in an incremental fashion - by strategically replacing key merges by rebases. – Shriram V Oct 26 '21 at 10:30
  • I don't know exactly what's happening in this case (i.e. why the desired result isn't the default), but if you combine `--rebase-merges` with `--interactive`, the TODO file that gets generated lists all the merges it's going to recreate, with detailed comments about how they're controlled, so you might be able to manually create the scenario you want by editing those. – IMSoP Oct 26 '21 at 10:47

0 Answers0