Nicolas Pitre <nico@xxxxxxx> writes: > [ Hmmm... there used to be many more (remote) branches before. Where > are they? Looking into .git/refs I see a remote/ directory and all > remote branches are there. But I'm cheating now because a newbie > might not even think of looking there. > > Ah? there is -a and -r options to git-branch. Fair enough. ] A newbie might not even expect to see "many more branches" because there is no "before" for him. > $ git checkout origin/next > git checkout: to checkout the requested commit you need to specify > a name for a new branch which is created and switched to > > [ Hmmmmmmmm.... /me stares at the message wondering. > I just want to _see_ and maybe _install_ the code from "next". ] Rewording to suggest "checkout -b newbranchname origin/next", perhaps? > $ git checkout -b local_next origin/next "git checkout -b next origin/next" should work just fine, I think. There was a talk about allowing "checkout -b <new> <track>" to add branch.<new>.merge and branch.<new>.remote if <track> can be proven to corresond uniquely to one remote and one branch from that remote; I think that would match the expectation most of the time but that "most" would not be 100% nor even 80%, so I think that should be an optional feature. In any case, there was a talk but there is no code yet. > And there was a discussion about allowing checkouts to be made from a > remote branch but not allowing any commit on it. What happened of this > idea? It remains to be an idle talk without any code. Contributions appreciated. > $ git pull origin/next > fatal: The remote end hung up unexpectedly > Cannot get the repository state from git://git.kernel.org/pub/scm/git/git.git/next > > [ WTF? Where that ...pub/scm/git/git.git/next comes from? Hmmm... ] This comes from ancient request by Linus to allow: $ cat .git/remotes/jgarzik URL: master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/ $ git pull jgarzik/misc-2.6 See http://article.gmane.org/gmane.comp.version-control.git/6181 for the full text. Personally I thought this was confusing when I implemented it the first time, and I still find it confusing. I suspect nobody uses it. I am all for removing this "URL prefix shorthand" feature in v1.5.0. > $ git pull . remotes/origin/next > Already up-to-date. > > [ Woooh! But since I always hated this syntax let's try merge instead. ] > > $ git merge origin/next > Already up-to-date. Yes, that is one of the reasons that you would prefer 'merge' when you are working locally. > $ git pull origin > Warning: No merge candidate found because value of config option > "branch.local_next.merge" does not match any remote branch fetched. > No changes. > > So this means that branch.local_next.merge should be set to origin/next? No, the message says "any REMOTE branch" -- refs/heads/next is what it is called at the remote, and that is how the value is expected to be spelled; I think somebody added an example to config.txt recently to stress this. The above error messasge obviously was not clear enough. Rewording appreciated. - To unsubscribe from this list: 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