0

I am not, and will never be, a git expert, so kindly be gentle.

I have a PR branch which has—Github tells me—let's say 12 commits on it.

While I've been working on this PR, I've merged master (the branch it diverged from originally) into it a couple of times. I am planning on squashing all commits down to one before this PR is accepted and merged.

I know that I am going to use git rebase -i to do this. The general area of this question is how to come up with the argument to supply to this command.

Given the merges from master to my PR branch etc. etc., git merge-base doesn't give me, I don't think, the right SHA to supply as an argument to git rebase -i. It will, in fact, give me the most recent commit that "came over" from master, instead of the earliest point at which my branch "started".

I have, of course, read this excellent answer. Its "shell magic" answer works, but I don't fully understand it, and I don't like relying on magic I don't understand.

My question, therefore, is: From my PR branch, can I, instead, use this comparatively simple command: git rebase -i HEAD~12, where 12 is whatever Github tells me is the number of commits on my branch?

(I am assuming in all of this, of course, that I have pushed my local branch to my origin, i.e. my local on-my-laptop branch is identical to my Github-hosted origin branch. Implicit in this assumption is that if Github says 12 commits, then my on-my-laptop branch should also have exactly 12 commits.)

Is this number of commits OK to supply after the tilde (~)? Is this a reliable, relatively brain-dead-easy thing to do? Or will I trip myself up on yet another inscrutable git option or convention?

Laird Nelson
  • 15,321
  • 19
  • 73
  • 127
  • 1
    Typically, what you really want is `git fetch && git rebase -i origin/master`. There's no counting or anything involved here. – torek Apr 19 '19 at 00:32
  • Will that work properly even in the presence of intermediate merges from `master` to my PR branch? – Laird Nelson Apr 19 '19 at 00:37
  • 1
    As long as they are merges *from* master *to* your PR branch, yes. Any merges going the other way are more problematic here (but might also be problematic in other ways). – torek Apr 19 '19 at 00:47

1 Answers1

1

I've found this wonderful example, which answers my question exactly. Specifically, it addresses the need for counting commits, and for designating the commit hash that should be supplied to git rebase -i. It says, in part:

A downside of the git rebase --interactive HEAD~[N] command is that you have to guess the exact number of commits, by counting them one by one. Luckily, there is another way:

git rebase --interactive [commit-hash]

Where [commit-hash] is the hash of the commit just before the first one you want to rewrite from. So in my example the command would be:

git rebase --interactive 6394dc

Where 6394dc is Feature Y. You can read the whole thing as:

Merge all my commits on top of commit [commit-hash].

Way easier, isn't it?

My main issue was trying to find [commit-hash]. Now I know that it is not "one of mine", but the one that predates mine.

Laird Nelson
  • 15,321
  • 19
  • 73
  • 127