Nope.
I simply don't _have_ those branches.
Why? Because the kernel is _distributed_. There is no central place
(certainly not my repository) that tracks all the possible branches that
might get merged.
In other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more
sense to have a "pull" that fetches and merges, over something that
fetches separately and then merges. Because in a truly distributed
environment, you simply DO NOT HAVE static branches that you can associate
with particular sources.
See?
And the thing is, I think the git design should be geared towards true
distribution. It should NOT be geared toward a fairly static set of
branches that all have a fairly static set of other repositories
associated with them. Can you see the difference?
I'm personally convinced that one of the reasons people tend to use git in
a centralized manner is just a mental disease that has its roots in how
they used _other_ SCM's. I don't want git design to be polluted by such a
centralized notion.
So to repeat: you can always make "pull" boil down to "pull from myself"
(aka just "merge"), but you can _not_ make "fetch + merge" boil down to
"pull" without meking up extra state to track separately. In other words,
"pull" really is the strictly more powerful operation.
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
