linux-2.6.git mirror

Hi Linus,

I'm trying to setup a mirror of your Linux tree with git 1.5.3.1 and v2.6.23-5054-g821f3ef and I get the following error during this scenario:

$ mkdir linux $ cd linux $ git --bare init --shared=all Initialized empty shared Git repository in /home/emmedve1/linux/ $ git remote add --mirror -f origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git $ git fsck --full --strict <- all fine $ git remote update Updating origin error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit error: Object 5dc01c595e6c6ec9ccda4f6f69c131c0dd945f8c is a tree, not a commit $ git fsck --full --strict <- all fine

The situation is similar with the git tree:

error: Object a0e7d36193b96f552073558acf5fcc1f10528917 is a blob, not a commit

Other repositories (sparse for example) don't necessarily expose this, but I didn't test too many. This situation doesn't seem to surface for non-bare clones. I searched a bit the web for this, but nothing obvious showed up.

Is this something I should be worried about?

Thanks for your patience, Emil.

Instead of v2.6.23-5054-g821f3ef please read v1.5.3.4-206-g58ba4f6.

On Tue, 16 Oct 2007, Medve Emilian-EMMEDVE1 wrote:

Interesting. Something seems to be assuming that all tags are commits. Which is not true. You can have (and the kernel repo does this) a tag pointing to a pure tree state (with no history), or as in the case of git itself, there's a tag pointing to a blob that contains Junio's public key.

Yeah, same thing.

No, but if it still happens with a newer git, holler.

			Linus

Hi Linus,

I tested this with Junio's latest master and a couple of stable releases from the maint branch with the same result. In my ignorance I suspected the build infrastructure so I tried different gcc versions (4.x and 3.x) and optimization levels (including -O0) different libraries, etc. that I had on a few machines around here. The result was the same.

What worried me is that I think I traced the source of the error message in commit.c and in both two possible places from where the message could come the processing flow seems to be cut shorter because of this.

Thanks for your reply, Emil.

On Thu, 18 Oct 2007, Medve Emilian-EMMEDVE1 wrote:

Ok, what is going on is:

 - append_fetch_head() looks up the SHA1 for all heads (including tags):

        if (get_sha1(head, sha1))
                return error("Not a valid object name: %s", head);

 - it then wants to check if it's a candidate for merging (because 
   fetching also does the whole "list which heads to merge" in case it is 
   going to be part of a "pull"):

        commit = lookup_commit_reference(sha1);
        if (!commit)
                not_for_merge = 1;

 - and that "lookup_commit_reference()" is just very vocal about the case 
   where it fails. It really shouldn't be, and it shouldn't affect the 
   actual end result, but that basically explains why you get that scary 
   warning.

In short, the warning is just bogus, and should be harmless, but I agree that it's ugly. I think the appended patch should fix it.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---

And yes, I think this should go into Shawns tree of fixes, assuming that Emil confirms that it fixes it for him.

			Linus

 builtin-fetch--tool.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

Hi Linus,

Indeed, I don't get the error message anymore. Thanks for your help.

A remaining question is why I wasn't seeing that error message on normal clones, i.e. non-mirrors (with +refs/heads/*:refs/remotes/origin/* fetch refspec as oposed to +refs/*:refs/* fetch refspec)?

Thanks again, Emil.