Michael G Schwern wrote: >> cg-branch-add p4-perl git://git.catalyst.net.nz/perl.git#p4-perl >> cg-fetch p4-perl >> cg-switch p4-perl >> > cg-switch: refusing to switch to a remote branch - see README for lengthy > explanation; use cg-seek to just quickly inspect it > Oops, yeah, my mistake. cg-seek is what you need there; cogito won't let you switch to that because it considers it a "remote" branch (ie, a tracking branch - "mirror path" in svk terms). 'cg-status' shows these with a R. This is the cogito way to make a local branch based on a remote branch: cg-switch -r p4-perl somelocalname git-log also accepts a revision to start from: git-log p4-perl t/TEST To confound matters, the remote tracking has seen several revisions. First, git-core just had a "remotes" file that specified which refs (ie, branches) on the upstream side get converted to refs locally, and all the branches were in the same namespace. Files in .git/remotes/* Then, cogito allowed branches to be "remote branches", that it would refuse to commit to, and display specially, with the cg-branch-* commands to map to remote places. Files in .git/branches/* Recently (git 1.5+) git-core re-invented them in a more flexible and different way (see "git-remote", "git-config --global color.branch auto" and "git-branch -a -v"). Sections in .git/config However, the only real side effect of this mess is ending up with junk refs. In general just ignore them, you'll see when it's safe to delete them later when you get more familiar with the concept of the commit DAG. I just gave the cg- commands initially because I didn't want to write this git-core equivalent in public: mkdir perl cd perl git-init git-remote add catalyst git://git.catalyst.net.nz/perl.git git-config remote.catalyst.fetch \ '+refs/heads/restorical:refs/remotes/restorical' git-fetch catalyst git-checkout -b master restorical In terms of a tutorial... well, yeah, not sure. I'm writing one that's more of a "working with projects still using SVN repositories with git-svn" tutorial which doesn't really cover this case very well. There's a guy doing lots of work on the git user manual, which by now is getting quite complete. The nice thing about that is that it ships with git and shouldn't get stale like on-line tutorials do. I should probably confess that my git training has included two long talks from Martin Langhoff, and a 1½ hour internals demo from Linus at LCA last year. And of course, rigorous experimentation... SamThread Previous | Thread Next