Problem with Linus's git repository?

For two days I've been unable to pull from Linus's kernel git repository. The reason seems to be that HEAD is a symlink to refs/heads/master, which appears to be missing.

I'm wondering if Linus's personal version of git is broken ;o)

On Tue, 26 Jun 2007, walt wrote:

It's not missing, it's packed. I tend to re-pack after I make a release, and this time I did it after -rc6.

I assume you're using http, and probably not a very recent version.

http fetching has always been the ugly step-child of the other protocols. I personally dislike it a lot. But it _should_ work even with packed refs, at least if recent enough.

I just tested, it seems to work for me (I didn't wait for the clone to succeed, but it certainly got started).

		Linus

On Tue, 26 Jun 2007, Linus Torvalds wrote:

Sometime overnight this problem disappeared. I haven't actually tested this idea, but I have a hunch that your commit yesterday of "Fix zero-object version-2 packs" is the reason.

If the problem recurs I'll follow up on it.

Thanks.

On Wed, 27 Jun 2007, walt wrote:

No, I think the reason is simply that I pushed more updates to kernel.org, so now the kernel git repo has an explicit and separate "master" branch again.

What is your git version? The _real_ fix probably is to just upgrade. Are you using that broken(*) Debian git package by any chance?

		Linus

(*) By broken I mean "stable cannot be bothered to upgrade packages to modern versions, and is still on some ancient 1.4-based git version"

Linus Torvalds <torvalds@linux-foundation.org> writes:

Well, although git 1.4 is ancient in git timescale, you can keep your repository friendly with older versions of git and 1.4 certainly is not too old for that. In other words, newer git lets you choose to make your repository unreadable by 1.4, and you chose to do so, perhaps for a good reason.

Should we call git 1.5 "backward incompatible" with 1.4, because it allows you (or anybody) to make that choice? I dunno.

On Wed, 27 Jun 2007, Linus Torvalds wrote:

No, every morning I pull from you and Junio and Petr Baudis using cg-update, so I'm very much current. I notice that cg-update specifically does an http GET on kernel/git/torvalds/linux-2.6.git/HEAD which is actually a symlink to your refs/heads/master. Your 'master' now exists, but didn't exist two days ago as far I could see from my end.

The kernel.org server returned a 'you don't have permission to read kernel/git/torvalds/linux-2.6.git/HEAD on this server', not a 404. I tried two different ftp clients which also could not see your 'master' file until yesterday.

I notice that Petr hasn't made any changes to cogito for a long time, so maybe it needs some updating? Dunno.

--- Scanned by M+ Guardian Messaging Firewall ---

Hi,

On Thu, 28 Jun 2007, walt wrote:

Pasky announced that he will be discontinuing cogito.

Hth, Dscho

On Thu, 28 Jun 2007, walt wrote:

Oh, don't use "cg-update", or just fix it to do "git pull".

That explains it. cogito simply is not maintained any more.

		Linus

On Thu, 28 Jun 2007, Linus Torvalds wrote:

I'm happy to stick with using git. From reading the latest Docs, it seems that git-pull -v will do what I need (I think).

That's what I did just now to update from you and Junio, and the output seemed exactly appropriate -- ended with a fast-forward and no errors for either one.

However, a git-fsck turned up four dangling commits for Junio, and 42 danglers for you, including a mix of blobs, trees, and commits.

Will a simple git-prune bring me correctly up to date, or am I missing some steps?

Thanks!

--- Scanned by M+ Guardian Messaging Firewall ---

walt wrote:

You will see dangling commits, blobs and trees from Junio because he rewinds his 'pu' branch.

I'm not sure why you see any from Linus, as I'm not aware of any rewinding in the official kernel tree (unless you're talking about some other repo, in which case I'm clueless).

You're already up to date. The dangling commits do not hurt your repo in any way. Nor do they hurt the performance of any of the tools you normally use. fsck suffers a bit from them, because it has to care about them, but the normal DAG-traversing tools will never even see them.

git prune would remove them and save you a tiny bit of diskspace. Next time you pull from Junio, you'll most likely get orphaned commits again though, meaning blobs, trees and commits will end up dangling once more. It's perfectly normal and nothing to worry about.

For repo maintenance, I run "git gc" once a month on my local copies. More to let my laptop do something while I'm fiddling with receipts and stuff than for any real need (the idea of idle computers offend me for some reason).