Why is git clone not checking out files?

I don't understand why clone (version 1.4.4.1) is not checking out my files:

% ls /repos/git/project
branches  description  HEAD   info     refs
config    FETCH_HEAD   hooks  objects  remotes
% git clone /repos/git/project
remote: Generating pack...
remote: Done counting 1149 objects.
remote: Deltifying 1149 objects.
remote: 149/1149) done49) done
Indexing 1149 objects.
remote: Total 1149, written 1149 (delta 619), reused 1149 (delta 619)
 100% (1149/1149) done
Resolving 619 deltas.
 100% (619/619) done
% ls project
% ls -a project
.  ..  .git

Bill

Bill Lear wrote:

Unless you use git clone --bare, it should checkout HEAD branch...

On Tuesday, January 30, 2007 at 19:15:33 (+0100) Jakub Narebski writes:

Ok, well, I certainly did not issue git clone --bare, it was just a plain ol' clone:

% git clone /repos/git/project

and no checkout ensued. Can I fix this somehow? I've tried the clone several times with no success. Is there anything I can check in the source repo (the above /repos/git/project) to see why it would not be working?

Bill

Bill Lear <rael@zopyra.com> wrote:

I've seen this happen if HEAD in the source repository does not point at a branch, or points at a commit which doesn't exist. Though I usually also see an error about how HEAD isn't a valid object name...

On Tuesday, January 30, 2007 at 13:22:37 (-0500) Shawn O. Pearce writes:

Hmm.

% cd /repos/git/project % ls branches description HEAD info refs config FETCH_HEAD hooks objects remotes % cat HEAD ref: refs/heads/master % cat FETCH_HEAD 2ed7b6f672963bab4bad713a71967f683fe01163 branch 'topic' of git://source/public/project 2ed7b6f672963bab4bad713a71967f683fe01163 not-for-merge tag 'fbdev_ref_1' of git://source/public/project

This repository was created like this:

% mkdir /repos/git/project % cd /repos/git/project % git --bare init-db --shared % GIT_DIR=. git fetch git://xiphi/public/project topic:topic

Bill

On Tue, 30 Jan 2007, Bill Lear wrote:

Ok, HEAD points to "master".

...but you don't _have_ any such branch. You only have a "topic" branch.

		Linus

Linus Torvalds wrote:

...so "git clone" tries to checkout HEAD -> refs/heads/master branch, which does not exist. It is strange that git does not report error or at least warning, though...

On Tue, 30 Jan 2007, Jakub Narebski wrote:

Well, HEAD pointing to a non-existent branch is actually a perfectly valid thing. It literally means "I haven't done the first commit yet".

So Bill's repository is a perfectly fine repository. It has a topic branch (called 'topic'), and it has an empty 'master' branch that just hasn't seen any commits yet. You can work on it as a full and normal git repository, because it really *is* a full and normal git repository.

Of course, I do agree that it'sa fairly confusing way to set up a repo, and you generally shouldn't do it, but Bill did it that way explicitly. Maybe he didn't do it "on purpose", but git at no point in time had any way to know that Bill wanted somethign else. Nothing he did was "wrong", and it's quite possible that it's what he could have meant to do.

Anyway, it's certainly easy to fix. Bill, you can either:

 - just rename the "topic" branch to "master"

 - change the HEAD to point to "topic" rather than "master".

(and if you do that setup in the future, the way to populate the initial bare repository would have been to just do

	git fetch original topic:master

and you'd never have seen this, because the branch you fetched would have been named the default 'master' in the first place).

		Linus

On Tuesday, January 30, 2007 at 11:04:57 (-0800) Linus Torvalds writes:

My setup was prompted by advice I got here. Perhaps I misunderstood. I thought the way to set up a shared public repo for my collaborators was to git --bare init-db --shared, then do a git fetch from the upstream repo. I want to be able to push into my public repo from one or more of my private repos, hence the need (I was told) for he bare option.

I don't think I want this. I want to know I'm on the topic branch of that repo, anything else really makes me nervous.

Same for this...[Thanks for the advice, nevertheless.]

I wonder if the original repo I pulled from is just messed up. Ahh -- I see Shawn just replied saying I needed to fetch in a different way. I shall peruse that and report clarity of vision when achieved...

Bill

Hi,

On Tue, 30 Jan 2007, Bill Lear wrote:

The name in the bare repository does not matter as much as your _local_ name.

If you have only _one_ branch in the upstream repo, why don't you let "HEAD" (in that repo) point to that branch, but to a non-existent "master"? That does not make sense.

Ciao, Dscho

On Tuesday, January 30, 2007 at 20:15:37 (+0100) Johannes Schindelin writes:

Well, being a git newbie, it kinda matters to me. I need linearity right now. Anything that swerves is likely to result in me and my project stuck in the weeds.

So, I tried a straight fetch:

% GIT_DIR=. git fetch git://source/public/project

This has one branch:

% GIT_DIR=. git branch
  topic

Then a clone of that:

% cd over_there
% git clone /repos/git/project
[...]
% cd project
% git branch
  topic

All is well exactly what I want and expect ... except:

% ls -a . .. .git

No checkout was done.  I'm finding this extremely confusing.

I just want to work on the branch, and I want it identified as such, and I want it checked out, and I want some candy.

Sorry to whine, just wish I understood this better.

Bill

On Tuesday, January 30, 2007 at 13:36:50 (-0600) Bill Lear writes:

Ummm, I may have made a mistake here ... doing again to ensure I did not mis-type above ...

Bill

On Tuesday, January 30, 2007 at 13:43:22 (-0600) Bill Lear writes:

Ok, I hate twice quoting my self, especially to admit to crack smoking. I was indeed apparently smoking crack --- no such branch shows up...

Bill

Ok, in my own inimitable way, I think I have figured this out. Please let me know if this is dumb (output of commands below clipped):

% git --bare init-db --shared % GIT_DIR=. git fetch git://source/public/project topic:topic % cd there % git clone /repos/git/project % cd project % git checkout topic warning: You do not appear to currently be on a branch. warning: Forcing checkout of topic^0.

If this is ok, this appears to give me the result I want ... I think.

Thanks to all for hand-holding the blind and if someone already mentioned this option, apologies for missing it.

Bill

On Tuesday, January 30, 2007 at 13:36:50 (-0600) Bill Lear writes:

Linus Torvalds wrote:

Or, in repository you clone from, do "git pull . topic" when on master, and you will have 'master' branch for your own work, which would be fast-forward of 'topic'.

On 1/30/07, Jakub Narebski <jnareb@gmail.com> wrote:

It would be nice if git-clone at the very end (at checkout) wrote which
branch we are at, e.g.
  "On branch refs/heads/master"
  "Not currently on any branch"
  "Current branch refs/heads/master does not exist"

On Tuesday, January 30, 2007 at 10:41:03 (-0800) Linus Torvalds writes:

Hmm, so I did this:

% cd /repos/git/project
% GIT_DIR=. git branch
  topic

And then, tried it all again:

% cd ..
% rm -rf project
% mkdir project
% cd project
% git --bare clone --shared
% GIT_DIR=. git fetch git://source/public/project
warning: no common commits
remote: Generating pack...
remote: Done counting 1148 objects.
remote: Deltifying 1148 objects.
remote:  100% (1148/1148) done
Unpacking 1148 objects
remote: Total 1148, written 1148 (delta 632), reused 1020 (delta 534)
 100% (1148/1148) done
% GIT_DIR=. git branch
[eh?  No branches??]
% cat HEAD
ref: refs/heads/master

So, where are my branches? And don't tell me I don't need no steenking branches...

Bill

Bill Lear <rael@zopyra.com> wrote:

You did not ask for a tracking branch to be created. So the result of your fetch is in FETCH_HEAD only. Try instead:

GIT_DIR=. git fetch git://source/public/project topic:refs/heads/master

Shawn O. Pearce wrote:

Or you can use "git clone --bare --shared" (not "git --bare clone"; there is a diference).

On Tuesday, January 30, 2007 at 14:09:07 (-0500) Shawn O. Pearce writes:

Ok, then when I clone this my master branch in my cloned repo will actually be pointing to the topic branch of the remote repo?

[recreate dir, re-init, fetch as above, clone; now, cd into cloned repo]
% cd project
% git branch
* master
  origin

This makes me really nervous, like a nervousness-inducing cloaking device would. I'm not enough of a git master to just "use the force". When I go into my cloned repo, I want to see "topic" for my branch name, not master...

BTW, I note also that the clone seems to have taken GOBS more time this time around. Am I seeing things or would this be a result of the fetch gymnastics above?

Bill

On Tue, 30 Jan 2007, Bill Lear wrote:

Heh. That's not doing what you seem to expect.

If you don't give it a branch to fetch into, "git fetch" will not populate *any* branch. It does fetch the data:

but it never wrote it into a branch, since you didn't tell it where it should go.

It didn't go away entirely, though: it's referenced by FETCH_HEAD, and this is actually the *common* thing for fetch usage when you use it to just them merge the fetched result into your current head. That is, for example, what I do all the time (except the "fetch+merge" thing is usually just called "git pull" ;)

Right.

.. and again, this is fine, but it just means that since no "master" branch exists, you have an empty HEAD with no commits.

You absolutely need some steenking branches, but you need to tell git which branch you want to use.

So either use

	git --bare fetch git://source/public/project topic:master

(to tell git to fetch the remote 'topic' into the local 'master')

OR, if you just prefer using the 'topic' name - which is certainly not wrong at all, do

	git --bare fetch git://source/public/project topic:topic
	git --bare symbolic-ref HEAD refs/heads/topic

where that second line is important: it's the one that tells that you want HEAD to be pointing to the 'topic' branch.

[ You could have done that second line before the fetch, and really 
  considered it part of the "create repository" sequence, rather than the 
  "fetch" sequence ]

Or something like that.

		Linus

On Tue, 30 Jan 2007, Linus Torvalds wrote:

Side note: it's usually a good idea to have a 'master' branch, not so much because git itself really cares (it's just a default, after all, in a technical sense), but more because NOT having a master branch may then end up confusing other people who try to access the repository, and it doesn't have the normal default branch.

And another note on this. I did do that with a special command, and yes, th is is what you should do in a script. HOWEVER, as with .git/config, I really think it's probably just easier to open your editor on the HEAD file directly, and just do that renaming by hand.

I _like_ people being able to just open files and mucking with them. It's considered extremely bad form in CVS (yeah, people _do_ actually open the CVS internal *,v files and muck with them, and it's a horrible horrible thing to do, but sometimes people have reason to do it), but in git, all the files you really *really* must not try to edit are compressed binary files and are protected by really strong checksums etc, so I don't think it's wrong to encourage people to edit files under .git/ by hand.

The things that can be edited are perfectly fine to edit. You can screw things up, of course, but on the other hand, I think people can really get a much better feeling for what git does if they end up understanding the files that git depends on.

So by all means, get down and dirty, and just fire up your editor on .git/HEAD when you want to create a repository that has some other default HEAD than 'master'.

		Linus