0

In general when is one branch the upstream of another one?

git-rebase - Forward-port local commits to the updated upstream head

git rebase [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>] [<upstream>] [<branch>]

In the following the master is the upstream branch. But why is master upstream, what is the precise definition?

      A---B---C topic
     /
D---E---F---G master
Claudio
  • 10,614
  • 4
  • 31
  • 71
Roland
  • 7,525
  • 13
  • 61
  • 124
  • "If is not specified, the upstream configured in branch..remote and branch..merge options will be used." – Fred Foo Nov 08 '13 at 10:28
  • Did you look at one of the examples in that documentation that uses the upstream argument, and see what it did? – Useless Nov 08 '13 at 10:29
  • Look at the edited question. – Roland Nov 08 '13 at 10:45
  • It really is exactly what the docs say. In the added example, `master` is only "upstream" from `topic` if you've configured `branch.topic.remote = .` and `branch.topic.merge = master`. Otherwise `git rebase` *needs* you to name a commit to be used (as if it were* "upstream", instead of figuring it out automatically. (And in general, when you use rebase like this, you *do* specify the "fake upstream", instead of configuring it.) – torek Nov 08 '13 at 11:36
  • 1
    @torek The problem is that the docs dont define upstream. The term seems to be used rather loosely. See also this question: http://stackoverflow.com/questions/2739376/definition-of-downstream-and-upstream – Roland Nov 08 '13 at 12:21
  • 1
    Rebase doesn't define it here, because it's up to you to choose it. I think "upstream" is the wrong word to use for this argument—it might be better to call it "start-after", as in: "rebase starts with those commits that come 'after' the given `start-after` point, and continues to the tip commit on the given `branch`, moving them to the `onto` point." (But that's still not quite accurate, as it starts after the merge base. Which is probably why the docs say "upstream" here, it's confusing no matter how you phrase it.) – torek Nov 08 '13 at 12:24
  • @torek where is a good place to look for git terminology besides the [Git book](http://git-scm.com/book)? E.g. what is a [source object](http://git-scm.com/docs/git-push.html), etc... – Roland Nov 08 '13 at 12:41
  • 1
    The problem with looking for git terminology is there is no single agreed-upon set of terms. Look at the arguments that rage over "index" vs "staging area", for instance. :-) So, everything defines its own terms: `rebase` uses "upstream" in a slightly weird way, `push` and `fetch` have subtly different ways of using "refspec", etc. They're all *reasonable* but you have to be really careful about who's speaking. – torek Nov 08 '13 at 12:44

1 Answers1

1

The user selects what is the upstream for the branch to be rebased on. Any commit in the repo can be considered upstream for rebase operation even the one that is already part of the branch, for example:

git rebase -i HEAD~5 

Will allow to rewrite last 5 commits of the current branch (change order, squash or remove some)

But one of the generic usages would be if you have a branch that tracks releases and your development branch and while you were developing, somebody created a release with new feature that your development branch doesn't have yet. In this case your dev branch should be rebased on the released state, i.e. upstream.

Eugene Sajine
  • 8,104
  • 3
  • 23
  • 28