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)
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.
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.
I'm wondering if Linus's personal version of git is broken ;o)
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
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.
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...
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.
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...
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.
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"
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...
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.
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?
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.
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.
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
No, every morning I pull from you and Junio and Petr Baudis using cg-update,
Oh, don't use "cg-update", or just fix it to do "git pull".
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!
From: Andreas Ericsson <hidden> Date: 2016-06-15 22:43:18
walt wrote:
On Thu, 28 Jun 2007, Linus Torvalds wrote:
quoted
On Thu, 28 Jun 2007, walt wrote:
quoted
No, every morning I pull from you and Junio and Petr Baudis using cg-update,
quoted
Oh, don't use "cg-update", or just fix it to do "git pull".
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.
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).
Will a simple git-prune bring me correctly up to date, or am I missing
some steps?
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).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231