gitk show "future" branches?

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 Cl开发者_StackOverflowearCase background it does not make sense to me at all...

Thanks!

---

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.

---

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.

---

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).