-2

I was trying to really understand some rebase stuff, and was really stuck on this snippet:

git rebase --onto topicA~5 topicA~3 topicA

How would you explain it? How do you understand it?

Devin Rhode
  • 23,026
  • 8
  • 58
  • 72
  • 1
    Also: https://stackoverflow.com/questions/68522631/git-move-old-commit-to-the-past-of-another-branch – matt Feb 15 '22 at 23:29
  • I think a related approach would be "cherry-pick a range of commits" https://www.google.com/search?q=cherry-pick+range+of+commits – Devin Rhode Feb 18 '22 at 03:27
  • 2
    Rebase is exactly "cherry-picking a range of commits" from the branch point up to the branch head. – phd Feb 18 '22 at 11:57
  • These other answers (from @matt) and @torek are huge, but much more comprehensive. I suppose I could throw my hat in the ring, but I think they have much better answers, despite the length. – Devin Rhode Feb 18 '22 at 15:47
  • 1
    A rule of thumb: one should try to distinguish between Stack Overflow (an encyclopedia of programming facts) and one's own personal blog / notes. – matt Feb 18 '22 at 16:45
  • I'm using this option "Answer your own question – [share your knowledge, Q&A-style](https://stackoverflow.blog/2011/07/01/its-ok-to-ask-and-answer-your-own-questions/)". After reading this link, I think it's fair to say stack overflow isn't exactly meant to be a polished, well reviewed encyclopedia. However, that's a desirable goal. On one hand, I believe you and torek's answers ARE better. OTOH, they are very long and intimidating. – Devin Rhode Feb 19 '22 at 16:29
  • w3schools helped me a long 10 years ago when I first started coding. But, I later discovered https://www.w3fools.com/ There's some balance of accessibility and detail that's simply hard to achieve (Still, I don't disagree with closing this and pointing to your page) – Devin Rhode Feb 19 '22 at 16:31

1 Answers1

-2

Here's a plain english attempt to re-explain it, for my own future reference.

Imagine this is the call signature:

git rebase --onto <base-commit-ish> <first-segment-HEAD> <second-segment-HEAD>

This will make <second-segment> not dependent on <first-segment>.

That is, you'll get a branch structure like this:

                 H'--I'--J'  second-segment
                /
                | E---F---G  first-segment
                |/
    A---B---C---D  <base-commit-ish "D">

This is useful if you have stacked PRs, but want to "break out" one of the PRs as separate, so they can be independently merged.

If you have a large PR stack, a change is truly independently mergeable (no potential merge conflicts, etc), cherry-pick is a better option.

Devin Rhode
  • 23,026
  • 8
  • 58
  • 72