git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Jan Wielemaker <J.Wielemaker@uva.nl>
Cc: git@vger.kernel.org
Subject: Re: Corruption: empty refs/heads in otherwise filled repo: cannot clone?
Date: Mon, 30 Jun 2008 13:26:10 +0200	[thread overview]
Message-ID: <200806301326.12140.jnareb@gmail.com> (raw)
In-Reply-To: <200806301230.38980.J.Wielemaker@uva.nl>

Jan Wielemaker wrote:
> On Monday 30 June 2008 12:10, Jakub Narebski wrote:
>> Jan Wielemaker <J.Wielemaker@uva.nl> 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

  reply	other threads:[~2008-06-30 11:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-30  9:49 Corruption: empty refs/heads in otherwise filled repo: cannot clone? Jan Wielemaker
2008-06-30 10:10 ` Jakub Narebski
2008-06-30 10:30   ` Jan Wielemaker
2008-06-30 11:26     ` Jakub Narebski [this message]
2008-06-30 11:44       ` Jan Wielemaker
2008-06-30 12:03         ` Jakub Narebski
2008-06-30 12:20           ` Jan Wielemaker
2008-06-30 19:33             ` Daniel Barkalow
2008-06-30 19:46               ` Jan Wielemaker
2008-06-30 11:50       ` Björn Steinbrink

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200806301326.12140.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=J.Wielemaker@uva.nl \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).