Branches for commit (git)

[Dave Musicant]

I'm trying to get my head wrapped around how branching works in Bitbucket for git projects. In git, a branch is ultimately just a pointer to a specific commit at a tip. So I've created a project with two branches, below:

https://bitbucket.org/musicant/testagain/commits/all

When I click on an individual commit, it has a field called "branches" that tells me, presumably, which branch a commit is on. I'm not even sure I understand what that means -- what does it mean for a non-tip commit to be part of a branch? I could conjecture that there is a descendant somewhere along the line that ends in a particular branch, but that doesn't work. If that were the case, the early mainline commits would have both branch names on it, which they don't.

So again, my question: in the screen for a particular commit, such as this one:

https://bitbucket.org/musicant/testagain/commits/4fe9d15bd4ee572a1700f9f593776ef27c2209dc

What does "branches" on the right hand side actually mean? How can multple commits show the same branch (such as master), when "a branch in Git is simply a lightweight movable pointer to one of these commits"? [git-scm.com]

[Paolo Furini · Accepted solution]

Actually.. they are both true! ;)

When you commit you do so IN a particular branch. You must be in a branch OR in a "detached HEAD" state, but you cannot commit to multiple branches at a time..

But.. when speaking of "genealogies", a commit can be part of multiple branches. In fact, when doing a merge, you're joining the history of two branches, and, when the two branches share the same commits, then Git does a "fast-forward" merge by default. Instead, when the commits diverge, Git tries an automatic merge of your files and creates a new commit.

I suppose that in the detail pane BitBucket is displaying the branch you were in when you committed.

[Dave Musicant]

That helped a lot, Paolo.

How does Bitbucket know which branch I was in when I commited? I'm finding multiple web sources that indicate that the branch you were in when you committed isn't actually stored with the commit. git reflog will get me that info, apparently, but only locally; that info isn't pushed:

http://stackoverflow.com/questions/17857723/whats-the-difference-between-git-reflog-and-log

So if in the detail pane, Bitbucket is displaying the branch I was in when I committed, how does it know? Said differently, if I clone that repository, how could I get that same info from the command line?

[Paolo Furini]

You're absolutely right. reflog is held locally and not pushed upstream. Bibucket must be doing its calculations using git log, but I think they should review the way they're doing it..

I'm with you that the "Branches" label in the commit detail is pretty useless now. It should list ALL the branches a particular commit is in, and the git log traversal is the way to find it out.

Maybe not a "bug" in a strict sense, but it's a lack of functionality. Maybe you can file a bug.

Paolo

[Dave Musicant]

Works for me. Thanks again.

[Paolo Furini]

The branch ref points to the tip in that branch, but "logically" a specific commit can be part of none, one, or multiple branches. Commits that are not part of any branch are the result of a "detached HEAD" situation, and they are accessible for some time by their IDs before garbage collection.

So (I refer to your commits by message, as I'm too lazy to copy the SHA1 ids):

- "up" is in master AND side branches (it can be reached navigating backward from master AND side tip)

- "second commit" is in master AND side

- "third commit" is in master AND side

- "main change" is ONLY in master (go to Commits tab and select All branches in the dropdown, then u'll see a blue line that forks from "third commit" reaching ONLY "main change" commit)

- "side change" is ONLY in side

- "Another change to side" is ONLY in side

Hope this clarify how branches are displayed in BitBucket (and in every other git GUI, either desktop or web ones).

[Dave Musicant]

Paolo -- that helps some. Though if commit "up" is in master and side branches, why is it when I visit the page for that particular commit, at:

https://bitbucket.org/musicant/testagain/commits/0360f29868ca3b9426fe8e06e35b15c320ff72f5

... it only shows "master" for branches?

[Paolo Furini]

This must be the way BitBucket decides to display branch affinity. But actually that commit is in master AND side branches.

[Dave Musicant]

Hmmm. If "up" is on master and side branches, because it has both as descendants, and Bitbucket is only showing "master," that kind of sounds like a bug, or that I'm misunderstanding how it should work. Why master in particular? Why not side instead? What circumstance would cause Bitbucket to show two branches in this field?

[Seth]

I'm not sure why the label is plural, but every commit has to be made TO a branch. That information is remembered, and Git uses that information to create the branch graph shown on the left of commits/all

[Dave Musicant]

Seth -- if every commit is made to a branch, and that info is remembered to create the graph on the left, how does that explain commit 6f4a73a, labeled "side change"?

https://bitbucket.org/musicant/testagain/commits/6f4a73acdd35f65b901e4bc58b510e019ad3a58a

That commit shows "side" as its branch, but in the graph on the left, its parent is of the same color as the master branch.

[Paolo Furini]

Actually, "side change" is on side branch only, and its parent is "third commit". In fact "side change" is on its own green line, wether master is represented by a blue line that, as I said before, forks from "third commit" and reaches "main change", that is clearly only in the master branch..

[Seth]

Paolo is correct. It is an incorrect (though understandable) assumption that the branch represented by the straight line is master. In actuality, the branch with the most recent commit will be straight, which is currently "side".

[Dave Musicant]

I'm trying to reconcile what Paolo says in the first comment above, and in this one. Paolo indicates that the branch of a commit is determined by looking to the tips, and a commit belongs to any branches that it descends to. Seth indicates in this comment that every commit is made specifically to a (single) branch. These are different explanations. Which is right, and how does that interact with the "branches" field on the commit screen?

[Dave Musicant]

I'm trying to reconcile what Paolo says in the first comment above, and in this one. Paolo indicates that the branch of a commit is determined by looking to the tips, and a commit belongs to any branches that it descends to. Seth indicates in this comment that every commit is made specifically to a (single) branch. These are different explanations. Which is right, and how does that interact with the "branches" field on the commit screen?