6

Given the following branches

     A---B---C topic (HEAD)
    /
D---E---F---G master

and running the command

git rebase master

Does that mean, that we are

  • rebasing topic/HEAD on master, or...
  • rebasing master with topic/HEAD?

I can't infer how I would express this action in a sentence from the git-rebase man pages.

PS: I know what rebase is and what it does, I just want to know "how to speak" the command, since the first argument is actually called upstream.

  • 2
    It's the former ("rebasing topic on master"). When you give `git rebase` a single argument, that one argument—`master`, in this case—serves two purposes: it tells which commits *not* to copy, and it tells *where the copies go*. Your current branch supplies the commits to be copied. – torek Apr 22 '19 at 20:48

3 Answers3

5

The resultant branch layout would be as follows:

      A---B---C ("dangling", waiting for garbage collection)
     /
D---E---F---G---A'---B'---C' < topic (HEAD)
            ^
          master

You would be rebasing your topic (current) branch with master, thus changing the ancestry of A (now A' since it's not quite the same commit) from E to G.

Romain Valeri
  • 19,645
  • 3
  • 36
  • 61
Makoto
  • 104,088
  • 27
  • 192
  • 230
  • I didn't want to edit it myself, but for clarity I would have added on your graph the commits A, B and C (still existing with A pointing to E), with the comment "dangling", to make the copy aspect of the operation even clearer. I have upvoted anyway, this is a useful answer. – Romain Valeri Apr 23 '19 at 00:21
  • @RomainValeri: That would be true had there been a remote branch, but there's no indication that there is. – Makoto Apr 23 '19 at 00:24
  • 1
    ...a remote branch? A rebase is entirely local, what do you mean? OK, I have edited just to show you what I meant, feel free to rollback of course. – Romain Valeri Apr 23 '19 at 00:28
  • I think this is fine. No real complaints here. – Makoto Apr 23 '19 at 00:38
4

The first, rebasing topic/HEAD on master.

You're taking all the commits up to and including the latest of master. The current state/the latest commit of master is now again the 'base' on which you based your work.

You rebased that work on (the work already done in) master.

And (copies of) your commits will be added at the end, after the last commit in master. Credits to Makoto for supplying the graphic that explains the above.

For more reference materials, I personally think this tutorial by Atlassian explains it really nicely, including similar graphics. The basic rebasing is a 2 minute read, after which it continues with interactive rebasing, which is a really, really nice feature to have in your toolkit!

GolezTrol
  • 114,394
  • 18
  • 182
  • 210
  • Thanks for the confirmation. Seemed to make more sense to me anyway. –  Apr 22 '19 at 20:49
  • I know how to rebase and what it does, I just wasn't sure how to put the command in a correct sentence (since the first argument is technically called `upstream`). –  Apr 22 '19 at 20:56
  • No doubt, Erik. I just emphasized it in that wording so hopefully you won't have to doubt again which was rebased on which. :) – GolezTrol Apr 22 '19 at 21:01
1

I just want to know "how to speak" the command, since the first argument is actually called upstream.

I always mentally read that git rebase master command as:

rebase the current branch on top of master (the upstream branch)

That is: replay all commit from master (excluded) up to the current branch HEAD on top of master.

Check out also "git rebase, keeping track of 'local' and 'remote'"

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250