1

If I use gitk to look at a commit object it lists under Branches (in the lower left pane) all the children of this branch to which I can navigate upwards (as long as they are not nameless commits but actually have branch names).

Why? IMHO this is not logical and not useful because it violates the chronology of events (how thinsg got committed into the repository).

Suppose I have a a tree which look like this:

o branch 'Left' (commit 3)
| o branch 'Right' (commit 2)
|/
o commit 1
|
o branch 'base'

Now, if I select commit 1, then under 'Branches:' I will see:
Branches: Left, Right
Follows: base

What is the point of this? The commit 1 object is part of the base branch, it's not part of the Left branch, nor the Right branch, simply because at the time it was created Left and Right did not exist yet. So everything that gets merged or committed to Left and Right LATER will be part of Left or Right, NOT commit 1. So then how can the branches that commit 1 is part of include Left and Right?

Someone please explain what I am missing here, because coming from a ClearCase background it does not make sense to me at all...

Thanks!

Alan
  • 291
  • 3
  • 3

3 Answers3

1

Thanks to this information, you know that the changes introduced in the selected commit are included in all the branches figuring there.

I can think of situations where I would like to know in which branches the commit applies (or rather, if a given branch includes the selected commit). You could always follow the lines in gitk, but that can be cumbersome with long branches.

Sometimes I would like to do the opposite, select a commit and see if another previous commit applies there. There is no practical way to do that as far as I know, so selecting the other previous commit and checking the "Branches" field is a nice substitute.

Gauthier
  • 40,309
  • 11
  • 63
  • 97
  • First off - thanks for answering. Ok I see your point, but in this case how can I see the reverse information, i.e. what is the starting point of a branch? In other words - if I merge two more commits (4 and 5) on top of Left what tells me that commits 3, 4 and 5 are all part of the Left branch? Yes, I could sort of figure it out visually, but what if Branch Left was not created until commit 4? Or if it got created at the same level as commit 1 or base? – Alan Dec 14 '10 at 14:04
  • @Alan: In the case you describe, commits 3, 4, and 5 would still list Left as a branch they're on. It doesn't matter at all where it was created from, just whether or not a given commit is part of its history. – Cascabel Dec 14 '10 at 14:56
  • @Alan: as Jefromi says, does it really matter where the new branch started? Whether a branch existed when a commit was created does not change the fact that the commit is part of its history. In git, branches are practically just pointers to commits. Each commit has a pointer to its parent, which is how the history is recreated. – Gauthier Dec 14 '10 at 15:05
  • @Alan: and to answer to "what tells me that commits 3, 4 and 5 are all part of the Left branch?", you select the commits in gitk, and the field "Branches" shows "Left". This is exactly the point, as I wrote in my answer. – Gauthier Dec 14 '10 at 15:09
  • No, this is wrong or at the very least its a very weird logic. The branch is supposed to contain a collection of code - e.g. a bug fix or a feature. If I look at the tree and I see that a commit belongs to branch Left I say to myself, "this is something that I need to pick if I want to add the feature Left to my code". Most versioning systems treat branches this way. But in the case of git it is totally misleading because, according to gitk 'base' and 'commit 1' appear to be part of the Left feature when in fact Left started at commit 3 and these two commits have nothing to do with it. – Alan Dec 15 '10 at 07:32
  • I suggest reading git internals by Scott Chacon, if you are interested in how git handles its commits. A branch is technically only a reference to a given commit. The commits themselves keep track of their respective parents. I understand that this feels weird if you are used to branches being a collection of commits. The commits in your branch belong to only that branch (the Branches field in gitk), until they are merge in master (or another branch). From that point on, the commit is both a part of the branch and of master. – Gauthier Dec 15 '10 at 09:05
  • @Alan: In my understanding a branch includes all the code of the original, not just the added features. A snapshot of a branch at any given time is the whole thing (and this it makes sense for it to share the history). In your understanding a branch is not self-contained code, but a set of patches to be applied on the base. I think this is the source of confusion. – misiu_mp May 11 '11 at 14:26
0

Git has a more anonymous branch model (not to confuse with anonymous branches, git doesn't have these) in that way, that a commit is not permanently associated with a branch (sometimes branch names go into merge messages, but that's more a convention). A branch in git is a branch-label which get moved forward along with a new commit, but there is no information in a commit about on which branch it was created.

In your example commit1 is not directly associated with any branch, but a previous one stays on base and the two ascending commits are on Left and Right.

Rudi
  • 19,366
  • 3
  • 55
  • 77
0

You are looking at this slightly wrong. The commit1 commit is not part of the base branch. In git, branches are simple references to commit objects. The history of a branch is then described as 'all commits reachable from'. So commit1 is reachable from both Left and Right but it is not reachable from base.

If you were to git checkout base && git checkout -b feature2 then your new feature2 branch would not include commit1. Git doesn't track branch creation - if you want to record that you can add a tag or use git mergebase Left Right which will tell you the first commit reachable from both branches (in this case, commit1).

patthoyts
  • 32,320
  • 3
  • 62
  • 93