On Wed, 16 Oct 2013 05:51:32 -0700 (PDT)
Roy Vardi <roy.va...@gmail.com> wrote:
> So basically you're saying that the only way for me to run git branch
> and see master is if I'm on the head of it?
> I thought that all branches are conceived of a history of commits,
> and checking out an older commit still means that I'm on the same
> branch... Isn't it so?
In Mercurial, yes, in Git, no.
In the internal Git lingo a branch is called "a head" (consult the
gitrevisions manual page), and it's a moving pointer to a concrete
commit. What forms the *chain* (actually, a graph) of history ending
in a commit which is pointed to by a branch pointer is the fact each
commit references one or more (in case of true merges) parent commits,
so, starting with the "tip" commit, Git is able to traverse its whole
ancestry. But there's absolutely no information recorded in a commit
itself which would "mark" it as "belonging" to any branch.
The rationale for this, as I understand this, is that for the use case
Git was concieved for -- the development of Linux -- names of branches
have no sense at all because the project is organised in a form of
several *different* staging repositories belonging to
"leutenants" (folks in charge for particular kernel subsystems), and
changes flow from the repositories of individual developers to the
repositories belonging to leutenants, and from there -- to the Linus'
own (integration) tree. During these commit flows, names of branches
they were originally created "on" lose any sense. For instance,
the leutenants tend to maintain branches pulled from their downstream
developers using namespaces describing those developers -- a branch
fetched from Joe Random Hacker's repository which contains
a fix to the blarb subsystem might end up being named
"jrh/blarb-fix", and Linus would pull this series of commits
as a part of, say, "blarb-fixes" branch from that leutenant's
repository... I think you've got the idea.
> If not - then I have another question:
> Say I have a commit hash which is shared by two branches (I
> cherry-picked it from one branch to the other).
At this point it's no longer shared: cherry picking is like creating a
textual patch off a commit and applying it creating *another* commit --
both would have different hashes.
> Now - If I checkout this hash, "where" would I be? If both branches
> have a different set of commits prior to this commit, then which of
> those past commits will I see?
When you check out a commit you end up being in a so-called "detached
HEAD" state: you're free to record commits, and they will normally
"stack up" on top of the checked out one, and the HEAD ref will be
promoted accordingly, but there will be no reference to this line of
development other than HEAD itself, and so when you check out some
other state this line "will be kind of lost" (in fact not but I
digress). So the usual approach is to turn such a line into a branch
before switching somewhere else, for instance, by running
`git branch <name>`. Or you might tag this commit. In other words,
give it a pointer and switch away freely.
The name of this state means the HEAD is detached from any branch.
Please see  for more info on all of this.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.