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...
Sam
