On Tue, 02 Jan 2007 23:18:13 +0100, Jakub Narebski wrote: > Is it still problem (the dissapearing remote branches) with the new > wildcard remote.<name>.fetch generated by new git-clone? Ah, you're right. Sorry I missed that, (looks like it was in next but not in master). I had said I was going to start running from next to test this stuff. So now I tried switching to next and hit a couple minor surprises, (not big issues---mostly just me really trying out separate-remotes for the first time, and pretending to some extent that I don't know anything about it): $ git checkout next error: pathspec 'next' did not match any file(s) known to git. Did you forget to 'git add'? Here I'm using a branch name that cannot be resolved but I'm getting an error message based on a path name that cannot be resolved. It's tricky to know how to construct the correct error message here since "git checkout" can accept either a branch name or a path name. But I would argue that the branch name is the primary thing for "git checkout" to act on so the error message should talk about that if the argument cannot be resolved as either a branch or a path. (Regardless, "git add" would not be a helpful suggestion if someone were actually trying to do "git checkout file"). So I know that "git checkout next" used to work, and I know that we're now in a "separate remotes" world. But I don't know how everything about how they work yet. Clearly just using "next" doesn't resolve to anything anymore. So let's see what we have to work with: $ git branch * master Hmm... nothing to see here (though the fact that the remote-tracking branches don't show up here is generally quite nice---I love the reduced noise). But maybe we want at least an indication of what's not being shown? Maybe something like: $ git branch * master [and 8 remote branches: use -r to see them as well] That might avoid some confusion for upgraders anyway. Moving on, I can see the "missing" branches with: $ git branch -r origin/HEAD origin/html origin/maint origin/man origin/master origin/next origin/pu origin/todo And now I try to check one out: $ git checkout origin/next git checkout: provided reference cannot be checked out directly You need -b to associate a new branch with the wanted checkout. Example: git checkout -b <new_branch_name> origin/next And now I start getting confused. If git-checkout wants a branch, and git-branch says that "origin/next" is a branch, then why won't this work? OK, I know that something's special about origin/next, (it's a "remote-tracking branch" and I needed a -r option to get git-branch to list it for me), but nothing in the git-checkout documentation would lead me to expect that "git checkout origin/next" wouldn't work. But at least I'm given a very clear error message here, (a great improvement, thanks!), and even a sample command. So I can do: $ git checkout -b next origin/next And I'm happy that works and I can build things. But say in a couple of days I want to build the latest in Junio's "next". What's the easiest recipe for that now? If I'm understanding things correctly, I can update my remote-tracking origin/next with just: $ git pull origin And that's thanks to this entry in .git/config: [remote "origin"] url = git://git.kernel.org/pub/scm/git/git.git fetch = +refs/heads/*:refs/remotes/origin/* I _think_ there's also a way for me to configure my local "next" to automatically fast-forward to track what's happening in "origin/next" on any invocation of "git pull origin", right? That is, configure origin/next as the thing to get merged into my local next when I pull. How do I do that again? Where's that documented? Ah, if I look in .git/config I can see that I should be able to just copy the block for the "master" branch and come up with: [branch "next"] remote = origin merge = refs/heads/next is that right? If so, it's really nice that what used to be hard-coded magic, (first remote branch getting merged into current branch), is now self-documented magic that can easily be applied to other branch combinations. Another great improvement, well done! The remaining question is whether it wouldn't make sense to just create that block when I did "git checkout -b next origin/next". I think this has been proposed before and Junio said "Maybe, if everything can be resolved unambiguously, but even then, not always". I'd be interested in hearing more about when that would be the wrong thing to do. It seems it would be awfully convenient here, (and not doing it means it's easy to end up with a local "next" branch without realizing how stale it is). Now, if I'm only tracking/building what's in next and not actually planning on committing anything, then I wouldn't even need the local branch at all if I could just checkout the remote tracking-branch directly: $ git checkout origin/next In fact, I'd greatly prefer this, since a lot of the advantage of separate remotes is that "git branch" lists only stuff I'm actually working on and not other noise from remote branches that I consider uninteresting. Forcing me to clutter up that list just to examine the state of some remote branch is not helpful. Of course, this feature depends on the pending "detached HEAD" work that started this thread, (wow, look at that, I wandered back on topic!). And a further question from there is whether it makes sense to have "git checkout" look around in .git/refs/remotes/* so that I could checkout origin/next by just using the name "next": $ git checkout next which could complain if that couldn't be resolved without ambiguity. Would that be a bad idea? -Carl
Attachment:
pgpD0685wIdQp.pgp
Description: PGP signature