domenica 11 giugno 2017

Magit spin-offs: another way to name a tracking branch.

A few days ago my attention was caught by an entry in the Magit Branch Pop-up buffer: Create a new spin-off.

What the hell is a spin off?
According to the Magit Branching documentation, a spin-off is nothing more than a tracking branch.
A tracking branch, created on the git side with the -t switch, is a branch that knows (i.e., it has
knowlegde) about the branch it was originated from. Well, every branch in git has, of course, knowlegde
about its ancestor branch (how would you merge otherwise?), but in this case
the knoweldge is made explicit by the tracking feature.

In particular, when a tracking branch is checked out git advices about commits that made the
current (tracking) branch diverging from its ancestor, something like the following:

% git checkout b
Switched to branch 'b'
Your branch and 'master' have diverged,
and have 1 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

In the above example you can see that the b branch is behind master two commits, as well as after master by one commit.
In other words, your b branch has done a single commit while master advanced by two other commits. As git
suggests, you can pull and git will automagically fetch updates from the master branch into b.
And in fact:

% git pull
From .
 * branch            master     -> FETCH_HEAD
Merge made by the 'recursive' strategy.

The tracking is useful to know transparently when and how (much) your branch is diverging from the source, and this of course
is true both for local commits and remote ones:

% git status
On branch b
Your branch is ahead of 'master' by 2 commits.
  (use "git push" to publish your local commits)
nothing to commit, working tree clean

What happens into Magit? Well, once you checkout a tracking branch the popup buffer shows that is unmerged from the source branch, and
it does suffice to F pull to prompt the merging popup.

So, to recap, a Magit spin-off lies a tracking branch, which in turn is a branch explicitly aware of what makes it different
from the source branch. This is useful, for instance, for features and short living development branches that are going to be merged
surely by design and must be kept up to date from the normale release history. I don't see the point in using tracking into
versions branches.

Nessun commento: