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

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

 



Jan Wielemaker wrote:
> On Monday 30 June 2008 12:10, Jakub Narebski wrote:
>> Jan Wielemaker <J.Wielemaker@xxxxxx> writes:
>>>
>>> I'm a bit puzzled. I have a bare repository, somehow without any files
>>> in refs/heads.
>>
>> Do you have .git/packed-refs file?
> 
> Its a bare repo, so I'll forget the .git.  Yes, I have that file and
> it contains nice references,  I checked a few by hand, and they have
> the same SHA1 as the files I copied.

That is where the refs are instead of being in individual files under
refs/ - those are so called "packed refs".

  When a ref is  missing from  the traditional $GIT_DIR/refs hierarchy,
  it is looked up in $GIT_DIR/packed-refs and used if found.

I'm not sure why branches are also packed, because git used to pack
only tags and refs which were packed already.

>> How do you have gc.packrefs set ("git config --get gc.packrefs")?
> 
> This gives no output, so I guess the answer is 'no'.

In git-config(1) you can find the following:

  gc.packrefs::
        `git gc` does not run `git pack-refs` in a bare repository by
        default so that older dumb-transport clients can still fetch
        from the repository.  Setting this to `true` lets `git
        gc` to run `git pack-refs`.  Setting this to `false` tells
        `git gc` never to run `git pack-refs`. The default setting is
        `notbare`. Enable it only when you know you do not have to
        support such clients.  The default setting will change to `true`
        at some stage, and setting this to `false` will continue to
        prevent `git pack-refs` from being run from `git gc`.

Unless something changed (and git Documentation was not updated) git
should not pack refs by default.

>> What are the git version on the
>> clients that have trouble accessing repository, and what protocol
>> (transport method) do they use: "file", http(s)/ftp, git, ssh?
> 
> I could reproduce the problem using the same git that maintains the bare
> repository, which started as git-1.5.3.4 and is now 1.5.6.rc3. It
> reproduces both using local file access and ssh. Other people have a
> variety of versions. I know of concrete problems using the stable 1.5.5
> over ssh.
>
> The problem that I can't even clone is indeed after running a git-gc.

Hmmm... strange. I know that there can be problems with older clients
(those which do not understand packed-refs format) accessing
repositories with packed refs (without loose refs) via "dumb"
protocols.  Problems with accessing repositories locally and via ssh
might point to some troubles with permissions and ownership of
$GIT_DIR and $GIT_DIR/packed-refs.
 
git-gc can pack refs, that is what running it causes problems.

> So, now I have all branch head refs double (in packed-refs and in
> refs/heads). That explains ar least where they come from, but it fails
> to explain why doing exactly the same using the same git on the same
> repo as two users yields a different result. Of course, besides the
> desire to understand how his works, I'm mostly interested in how to fix
> this :-)

Unfortunately as it is not caused by the issue I thought about I cannot
help you further...

-- 
Jakub Narebski
Poland
--
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