Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 30 June 2008 14:03, Jakub Narebski wrote:
> Jan Wielemaker wrote:
> > Summarising, I think the conclusion is that git pack-refs has somehow
> > been run on this repository, and being a bare one this is not a
> > particulary good idea right now. I have the impression I should `unpack'
> > them by putting the appriate files in heads (done) and tags (now still)
> > and (re)move packed-refs.
>
> If you use new enough git both on server and on clients it should
> not have problems with packed-refs. I would rather check permissions
> of $GIT_DIR and $GIT_DIR/packed-refs.

There is no permission problem, as a I proved by doing a recursive copy
of the whole repo (cp -a, no errors) and the problem prevails on the
copy. A serious scan for permission errors was my first step. Almost
looks like something in the environment, but I can't find anything weird
there either.

> If "git show-ref" and "git for-each-ref" works, then
> "git ls-remote <repo>" should work, and git-fetch/git-clone
> shoulw work too...

Thanks for the pointers. I'll leave it for now (busy ...). I now
understand how it is supposed to work. If I can find time at some point
I'll run strace in different setups to see whether I can spot the
difference.

Anyway, thanks to your help I am fairly confident my repo is in good
shape again.

	Cheers --- Jan

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux