[bug] git-clone over ssh fails when repository has local commits

Hello,

First of all I kindly ask you to put my e-mail in CC as I'm not subscribed to the list. Secondly, I did try to find similar issues on the archives, but failed to do so. I apologize if this is not a bug.

I keep some local git repositories on my laptop, which are also used by other machines on my home network. In order to avoid unnecessary burden on the master servers, I've tried keeping a "local master" on the laptop and clone the repo's over ssh on the other machines.

I have some local commits on some of the "local master" repo's, and that's where the problems start: while cloning over ssh works fine for the unchanged repo's, those which have local commits are impossible to clone. The error on the "slave" machines is this:

 $ git-clone ssh://<host>/<path>
Initialized empty Git repository in <path>/.git/
Password:
remote: Counting objects: 132468, done.
remote: Compressing objects: 100% (25543/25543), done.
remote: Total 132468 (delta 107355), reused 130574 (delta 105466)
Receiving objects: 100% (132468/132468), 42.12 MiB | 4161 KiB/s, done.
Resolving deltas: 100% (107355/107355), done.
error: Trying to write ref REMOTE_HEAD with nonexistant object
f7a51afd56964cb0f10178353315d2680832ea54
fatal: Cannot update the ref 'REMOTE_HEAD'.
Warning: Remote HEAD refers to nonexistent ref, unable to checkout.

where I've "obfuscated" the hostname and the repository path. I'm using the latest version, 1.5.4.5.

Thanks,
  Renato Caldas

On Sun, Apr 06, 2008 at 02:45:22PM +0100, seventh guardian wrote:

It sounds like your remote repository has a bogus HEAD that points to a non-existent object. Can you ssh to <host> and confirm that you can do a "git show HEAD" in the remote repo?

-Peff

On Sun, Apr 6, 2008 at 5:11 PM, Jeff King <peff@peff.net> wrote:

I can, but it is a local commit. It seems like local commits aren't being "cloned over" to the slaves.. As I said, this only happens for "local masters" where I have local commits. If my master is untouched, then I can successfuly clone the repo.

Thanks,
  Renato

On Sun, Apr 06, 2008 at 05:22:39PM +0100, seventh guardian wrote:

You are going to have to clarify what you mean by "local commit" and "local master". Those aren't terms that are commonly used, so I don't understand what you are talking about. Can you describe which git commands you used to create this situation?

-Peff

On Sun, Apr 6, 2008 at 5:56 PM, Jeff King <peff@peff.net> wrote:

I figured ;) Let me see if I can explain it better:

remote master: the project git server, located remotely over the internet local master: my laptop repository, made by cloning the project master repo slave(s): my local machines, which clone the local master, instead of the remote master (to save bandwidth)

So on the local master (my laptop) I did: $ git-clone http://remote.master.address/foo/bar.git

Because I had to do some local changes to the code (what I've called a "local commit"), I did this on the local master: $ git-commit -a

Now I want a copy of the repository on another machine, "slave". So I do this: $ git-clone ssh://local.master.address/path/to/repo

Which gives the annoying error.. If I skipped the "local commit" stuff, then the cloning would work perfectly.

I hope this is clear now.. Thanks!
  Renato

On Sun, Apr 06, 2008 at 06:11:12PM +0100, seventh guardian wrote:

OK, I understand now. I think that is a reasonable terminology for your situation, but keep in mind that git doesn't really understand the concept of a "master". From the perspective of your slaves, there is only your "local master" as the remote "origin", and they can't tell any difference between that and the original "remote master".

Hmm. This _should_ just work, but something funny is going on. For some reason the "local master" is telling us that his HEAD points to f7a51afd, but we don't actually get that object. But I'm not quite sure how we get into that situation; my guess is that there is something confusing going on at the remote master, since the http fetching code is not as strict and might fail to notice a missing object there. Is it possible for us to see the remote master so we can take a look?

-Peff

On Sun, Apr 6, 2008 at 6:51 PM, Jeff King <peff@peff.net> wrote:

This object is the correct HEAD, but it is a local commit (I rebase all local changes so that they stay "on top" of the original code).

Sure, I just thought it would confuse more than it would help. I was obviously wrong, as I'm actually using git:// instead of http://.... sorry... ;)

 I'm experiencing this with both these repo's, as I have committed
some local changes to them:

git://anongit.freedesktop.org/git/nouveau/mesa git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/

On the other hand, I don't have this issue with this repo, which doesn't have any local commit:

git://anongit.freedesktop.org/git/mesa/drm/

Now that I look at the addresses, the "nouveau" part is common to the problematic repo's. I'll make a local change on the last repo and see if it also exhibits the problem. I'll report back ASAP.

Cheers,
  Renato

On Sun, Apr 6, 2008 at 7:06 PM, seventh guardian <seventhguardian@gmail.com> wrote:

The last repo also exhibits the problem after committing a local change. A hard reset to "origin" fixes the problem, but also throws away the local changes..

Cheers,
  Renato

<opublikowany i wysłany>

seventh guardian wrote:

It looks for me as permission problems, as thought loose objects get created unreadable by git daemon, or something...

On Sun, Apr 06, 2008 at 07:06:40PM +0100, seventh guardian wrote:

That shouldn't matter to git; it doesn't care at all about where commits were created.

Heh. OK, scratch what I said before then. :)

Can you give an exact set of steps to reproduce? There doesn't seem to be anything wrong with those repos, and I was able to do:

  m1$ git clone git://anongit.freedesktop.org/git/nouveau/xf86-video-nouveau/
  m1$ cd xf86-video-nouveau && echo foo >>COPYING && git commit -a -m foo
  m2$ git clone ssh://m1/path/to/xf86-video-nouveau

So now my guess is when you make local changes, something funny is going on. Can you describe that process in more detail?

-Peff

On Sun, Apr 6, 2008 at 7:17 PM, Jeff King <peff@peff.net> wrote:

My process is the same as yours, except for the "time-torture" the repositories have suffered. Surprisingly, everything worked on a fresh clone. So I suspect my "local master" repo's are somewhat messed up.. Will try to investigate further.

Thanks!
  Renato