1

I see many questions like that, but unfortunately none of them is giving a straight answer - can git track the base branch from which the current branch was created?

Consider the following branch structure:

master ---c0--c1---
          \
release1   ---c2--c3
              \
feature1       ---?

Release1 branch was branched off master and had 2 commits since merging (c2 and c3). Master branch had 1 commit (c1) which had not been merged anywhere. Feature1 branch was branched off release1 after c2 commit and does not have c1 or c3 commits yet.

I want feature1 to be "tethered" to release1, i.e. it should get updates from release1, but not from master, so "git ..." command should merge c3 commit but not c1.

This is easily done when user EXPLICITLY specifies release1 as the source branch when doing a merge. My question is - is git able to MEMORIZE that current branch was based off release1 and pull changes from release1 BY DEFAULT?

Alexander
  • 753
  • 2
  • 10
  • 25
  • 1
    The short answer is no: you can only have one *upstream*setting for a branch, and that one upstream is the closest thing has to the concept of a "base branch name". Since you want to have both an upstream *and* a "base branch" (as you call it), you could invent your own configuration values and Git commands and use those to achieve the desired results, but there is nothing built in to Git to do this. – torek May 18 '18 at 20:19

1 Answers1

1

As presented here this can be done by setting [origin/]release1 as an upstream branch of feature1 (when feature1 is checked out).

git branch -u origin/release1

(This was also presented is this answer with the longer equivalent of -u, --set-upstream-to).

Now you can simply

git pull --rebase

when on feature1 to automatically rebase (or skip --rebase to create a merge commit) to the HEAD of release1 branch, which includes c2 and c3.

orhtej2
  • 2,133
  • 3
  • 16
  • 26
  • Thanks, orhtej2, this is sure a legitimate way, but in my case I want a valid remote feature1 branch. – Alexander May 18 '18 at 17:47
  • @Alexander What do you mean? What do you want to achieve that's not covered by my answer? – orhtej2 May 18 '18 at 17:48
  • Your solution assumes just one remote branch, and (from what I see) the divergence between release1 and feature1 would be achieved by keeping feature1 commits local (we don't want to push everything to release1 right away). What do we do if someone else wants to take a look at local commits? – Alexander May 18 '18 at 17:54
  • @Alexander you can always push updated branch to publish local commits. If you pull and rebase you can always force overwrite while publishing (git push -f). – orhtej2 May 18 '18 at 18:17
  • Sure I can, but in my question's context I want 2 separate remote branches and want to know if I can "forget" both of their names. – Alexander May 18 '18 at 18:22