On Wed, Apr 20, 2011 at 02:26:54AM -0400, Jeff King wrote: > On Tue, Apr 19, 2011 at 03:20:53PM -0700, Josh Triplett wrote: > > > Using fetch-pack, I can clone a single tag from a repository: > > > > /tmp/testrepo$ git init > > Initialized empty Git repository in /tmp/testrepo/.git/ > > /tmp/testrepo$ git fetch-pack /home/josh/src/linux-2.6/.git refs/tags/v2.6.12 > > I don't think there is any reason to use fetch-pack here instead of > fetch. The latter will handle other non-git protocols like dumb http and > git-over-http. > > > However, I can't seem to find any way to convince git clone to do the > > same thing for me. git clone will clone a branch, but not a tag. > > > > /tmp/testrepo$ git clone /home/josh/src/linux-2.6/.git -b refs/tags/v2.6.12 > > Cloning into linux-2.6... > > done. > > warning: Remote branch refs/tags/v2.6.12 not found in upstream origin, using HEAD instead > > Right. There is no way to do what you want with clone. The "-b" option > is not "just clone this one thing", it is "clone everything, but the > branch I am interested in is ...". The fetch refspec remains > "+refs/heads/*:refs/remotes/origin/*". Oh, good to know; I hadn't yet figured out that -b didn't change the refspec. > To clone a subset of a repository, you have to do the init+fetch trick, > as you did above. If you want the configuration set up by clone, you > can do that, too, with "git config". So the equivalent commands to the > clone you want are: > > git init linux-2.6 > cd linux-2.6 > git config remote.origin.url /home/josh/src/linux-2.6 > git config remote.origin.fetch refs/tags/v2.6.12 > git fetch origin > > We could make clone more flexible with respect to such things, but I > don't know how useful that would be. A very small minority of power > users want to use weird fetch refspecs, and it is simple enough to > configure them manually, as above. I'd certainly appreciate having a "git clone --refspec=..." or similar, but thanks for suggesting fetch rather than fetch-pack! I actually don't always want the remote set up for this particular purpose, so using fetch works out well. > > On a different note, git fetch-pack seems to silently fail if asked to > > fetch a remote tag which points at a tree object rather than a commit > > object: > > > > /tmp/testrepo$ git init > > Initialized empty Git repository in /tmp/testrepo/.git/ > > /tmp/testrepo$ git fetch-pack /home/josh/src/linux-2.6/.git refs/tags/v2.6.12-tree > > (1) /tmp/testrepo$ echo $? > > 1 > > Did you mean v2.6.11-tree? There is no v2.6.12-tree in standard > linux-2.6 repositories. So fetch-pack is failing because there are no > matching refs to fetch. This works for me: > > $ git init > $ git fetch-pack /home/peff/compile/linux-2.6 refs/tags/v2.6.11-tree > remote: Counting objects... > ... > > If you want better error messages, use the fetch porcelain: > > $ git init > $ git fetch /home/peff/compile/linux-2.6 refs/tags/v2.6.12-tree > fatal: Couldn't find remote ref refs/tags/v2.6.12-tree > fatal: The remote end hung up unexpectedly Well, *that's* embarassing. I thought I'd tested that with a couple of other repositories and tree-tag objects, but apparently not. Sadly, though, I still can't check out the result: /tmp/linux-2.6$ git checkout FETCH_HEAD fatal: Cannot switch branch to a non-commit. (128) /tmp/linux-2.6$ git checkout -b master FETCH_HEAD fatal: Cannot switch branch to a non-commit. I guess I'd hoped for something similar to "detached HEAD" mode. Based on this, I need still to switch to using faked commits rather than trees. - Josh Triplett -- 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