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
Improve this question
8
  • "If <upstream> is not specified, the upstream configured in branch.<name>.remote and branch.<name>.merge options will be used." Commented Nov 8, 2013 at 10:28
  • Did you look at one of the examples in that documentation that uses the upstream argument, and see what it did? Commented Nov 8, 2013 at 10:29
  • 1
    @torek The problem is that the docs dont define upstream. The term seems to be used rather loosely. See also this question: stackoverflow.com/questions/2739376/… Commented Nov 8, 2013 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.) Commented Nov 8, 2013 at 12:24
  • 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. Commented Nov 8, 2013 at 12:44

1 Answer 1

Reset to default
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.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.