[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [jgit-dev] Nonexistent ref warning during clone of empty repository served by JGit
|
On Sun, Mar 2, 2014 at 2:06 PM, Brian Schroeder <bts@xxxxxxxxx> wrote:
> When I create an empty FileRepository or InMemoryRepository and serve it
> using Daemon to a C Git (1.8.4.2 or 1.9.0) client, I get a warning during
> checkout:
>
> % git clone git://localhost/repo.git
> Cloning into 'repo'...
> Checking connectivity... done.
> warning: remote HEAD refers to nonexistent ref, unable to checkout.
>
> This checkout failure also results in the omission of the standard
> branch.master.* settings that usually end up in .git/config after the clone:
>
> [branch "master"]
> remote = origin
> merge = refs/heads/master
> rebase = true
>
> This does not occur for repositories served by C Git:
>
> % git clone git://localhost/another-repo.git
> Cloning into 'another-repo'...
> warning: You appear to have cloned an empty repository.
> Checking connectivity... done
>
> I narrowed this down to JGit responding to `git ls-remote` with the
> following line:
>
> 0000000000000000000000000000000000000000 capabilities^{}
>
> whereas C Git daemons serve an empty response. The C Git client seems to be
> interpreting the zero SHA to be the object ID for HEAD, and it fails when it
> can't find this object.
>
> It seems that this functionality was added to JGit in the following commit,
> which fixes fetch-by-SHA1 for repos that don't have any refs to advertise:
>
> http://git.eclipse.org/c/jgit/jgit.git/commit/?id=ae1f46989c0515dce640ab339453b09810c0c5a5
>
> Does anyone have any thoughts on this? It seems the proper functioning in
> these two scenarios (cloning an empty repo, and fetch-by-SHA1 for repos
> without refs to advertise) are mututally exclusive. Should I open a bug
> report for this?
Ick. This is a bug we should fix in JGit.
