On Wed, 29 Mar 2006, Matt McCutchen wrote: > > Perhaps this is just politics, but which kernel repository is more > official, and why? Linus's or the one I have been using, > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git > ? The beauty of git should be (and maybe that's not entirely true simply because of practical concerns) that there really need not be any notion of "more official". You can fetch multiple different git trees from different sources into the same git tree, and then keep them _all_ around equally as different branches. You can move fixes between the different branches with "git cherry-pick", and you can merge different branches with "git merge" Now, the reason I say "_should_ be" rather than "is" is two-fold: - right now, a lot of the infrastructure is simply set up more towards the "one single source repository" model. When you do a "git clone", it kind of makes the origin special. That's how all the documentation is written, and that's also the only remote branch that git creates _automatically_ for you. This really isn't a technical issue: the git code code doesn't care about any special "original" repository. But the fact that you have to create the ".git/remotes/linus" file by hand, and that all the examples in the docs end up talking about a single "origin" branch means that people _think_ of git as a "single origin" thing. - the more fundamental one is that when you start mixing branches, you have to be very careful if you expect the upstream projects to pull the changes _back_. In particular, that's where you have to think twice (or three times) about doing a "git merge" (or a "git pull", which implicitly merges for you if it's not a pure fast-forward). In particular, the fact that _you_ want to merge two trees that came from different sources does _not_ imply that either of the two sources might want to merge with each other. So if you merge the two together, you may find it impossible to have either of them then pull from you: they way want your changes, but they might not like the merge you did, because they have different policies about that work than you did. So while the first point is purely a "mental model" issue and about lack of helper scripts, the second point is fundamental. For example, in your case it was almost certainly the right thing to do to cherry-pick your changes from the 2.6.15.6 branch onto the development branch, because I simply don't want to merge the 2.6.15.6 stuff into the standard tree: part of the _rules_ for the stable branch is that the things it fixes should have been fixed in the development tree already, so merging the stable tree should always be unnecessary (and often clash, although _hopefully_ in many cases the fixes in the stable tree are 1:1 identical and will merge beautifully). Anyway: from a technical standpoint, no tree should be "special" or "more official" for git usage. But when merging data back to any of those trees that aren't special, the source/history of the data is important to keep in mind. Branch "a" may not be any more special than branch "b", but when you push changes back to the source of branch "a", the history of those changes (relative to what the source was) is meaningful. Linus - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html