* Error converting from 1.4.4.1 to 1.5.0?
@ 2007-02-14 16:12 Bill Lear
2007-02-14 17:07 ` Bill Lear
2007-02-14 17:15 ` Junio C Hamano
0 siblings, 2 replies; 39+ messages in thread
From: Bill Lear @ 2007-02-14 16:12 UTC (permalink / raw)
To: git
I have a 1.4.4.1 repository, non-bare, cloned from my public
repository. I just installed and am using the new 1.5.0 git.
On my master branch, I cleaned out some cvs ids in our text files and
did a git diff --- all was well.
I then did a commit, and something went wrong:
% git commit -a -m "Nuke CVS Id strings"
error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
error: unable to read tree object HEAD
# On branch master
error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
error: unable to read tree object HEAD
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# src/ledef/
nothing added to commit but untracked files present (use "git add" to track)
The "Untracked files:" part is fine, but what's up with the other
errors?
I now do a git status and it shows all of my files that I changed
as still modified, and git diff seems to show the same output.
Bill
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 16:12 Error converting from 1.4.4.1 to 1.5.0? Bill Lear
@ 2007-02-14 17:07 ` Bill Lear
2007-02-14 17:15 ` Junio C Hamano
1 sibling, 0 replies; 39+ messages in thread
From: Bill Lear @ 2007-02-14 17:07 UTC (permalink / raw)
To: git
On Wednesday, February 14, 2007 at 10:12:44 (-0600) Bill Lear writes:
>I have a 1.4.4.1 repository, non-bare, cloned from my public
>repository. I just installed and am using the new 1.5.0 git.
>
>On my master branch, I cleaned out some cvs ids in our text files and
>did a git diff --- all was well.
>
>I then did a commit, and something went wrong:
>
>% git commit -a -m "Nuke CVS Id strings"
>error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
>error: unable to read tree object HEAD
># On branch master
>error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
>error: unable to read tree object HEAD
>...
I also notice this:
% git diff src/fus/testsuite/fus.design/prep4_5.s
fatal: failed to find delta-pack base object 1e742ba82e01f5bb39ed62e6863712fd3c9b0616
diff --git a/src/fus/testsuite/fus.design/prep4_5.s b/src/fus/tes[...]
index 106a233..4e6dbd5 100644
But running diff again seems to make the warning go away, but no
changes are listed...bad.
Bill
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 16:12 Error converting from 1.4.4.1 to 1.5.0? Bill Lear
2007-02-14 17:07 ` Bill Lear
@ 2007-02-14 17:15 ` Junio C Hamano
2007-02-14 17:20 ` Bill Lear
1 sibling, 1 reply; 39+ messages in thread
From: Junio C Hamano @ 2007-02-14 17:15 UTC (permalink / raw)
To: Bill Lear; +Cc: git
Bill Lear <rael@zopyra.com> writes:
> I then did a commit, and something went wrong:
>
> % git commit -a -m "Nuke CVS Id strings"
> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
> error: unable to read tree object HEAD
> # On branch master
> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
> error: unable to read tree object HEAD
Does 1.4.4 find that object? What's in HEAD (cat .git/HEAD)?
What does "git fsck-objects --full" report?
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 17:15 ` Junio C Hamano
@ 2007-02-14 17:20 ` Bill Lear
2007-02-14 17:45 ` Junio C Hamano
2007-02-14 18:19 ` Linus Torvalds
0 siblings, 2 replies; 39+ messages in thread
From: Bill Lear @ 2007-02-14 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wednesday, February 14, 2007 at 09:15:08 (-0800) Junio C Hamano writes:
>Bill Lear <rael@zopyra.com> writes:
>
>> I then did a commit, and something went wrong:
>>
>> % git commit -a -m "Nuke CVS Id strings"
>> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
>> error: unable to read tree object HEAD
>> # On branch master
>> error: Could not read ab66b31e390889e6bcbb2002111e2803c51f42b5
>> error: unable to read tree object HEAD
>
>Does 1.4.4 find that object? What's in HEAD (cat .git/HEAD)?
>What does "git fsck-objects --full" report?
% cat .git/HEAD
ref: refs/heads/master
% git --version
git version 1.5.0-dirty
% git fsck-objects --full
error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
% /usr/bin/git --version
git version 1.4.4.1
% /usr/bin/git fsck-objects --full
error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
So, all I did was try to do a commit with the new git ... haven't
recloned, or pulled from upstream...
Bill
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 17:20 ` Bill Lear
@ 2007-02-14 17:45 ` Junio C Hamano
2007-02-14 20:49 ` Bill Lear
2007-02-14 18:19 ` Linus Torvalds
1 sibling, 1 reply; 39+ messages in thread
From: Junio C Hamano @ 2007-02-14 17:45 UTC (permalink / raw)
To: Bill Lear; +Cc: git
Bill Lear <rael@zopyra.com> writes:
> % git fsck-objects --full
> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
>
>
> % /usr/bin/git --version
> git version 1.4.4.1
>
> % /usr/bin/git fsck-objects --full
> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
>
> So, all I did was try to do a commit with the new git ... haven't
> recloned, or pulled from upstream...
If you haven't packed the repository lately, the above indicates
this is not an issue between 1.4.4.1 and 1.5.0, but you had a
corrupt packfile before even started.
How big is this pack, what platform are you working on and whose
SHA-1 implementation do you use?
We used to have a bug that fed really large buffer to
SHA1_Update() function of the underlying SHA-1 library,
which was discovered exactly because somebody reported that
"mismatch with itself" message.
Also, do you have a huge blob in the repository? I do not know
if it is related but the write_sha1_file_prepare() function on
the codepath to write loose objects out would trigger the same
bug...
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 17:20 ` Bill Lear
2007-02-14 17:45 ` Junio C Hamano
@ 2007-02-14 18:19 ` Linus Torvalds
2007-02-14 18:42 ` Linus Torvalds
2007-02-14 21:13 ` Bill Lear
1 sibling, 2 replies; 39+ messages in thread
From: Linus Torvalds @ 2007-02-14 18:19 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, git
On Wed, 14 Feb 2007, Bill Lear wrote:
>
> % git fsck-objects --full
> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
This in itself could have been due to a historical buglet that shouldn't
matter (SHA1 on pack-files got miscomputed). However, that's probably NOT
the problem, since:
> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
implies that the pack really is corrupt.
Even a single-bit error will corrupt a pack in bad ways, which is one
reason why we're so careful with it and add its own SHA1 to the end.
The best way to proceed:
- MAKE A BACKUP ("tar" up everything). If for no other reason than
(a) then you don't have to worry about making things worse even by
mistake
(b) it might be interesting for others (if you can make those
pack-files available) to try to figure out what exactly the
corruption was. We've done it before, when it turned out to be a
single-bit error.
- if you have other git archives or just back-ups of everything, just use
them, and throw the corrupt one away entirely (but see above on why
it's nice to have an archive of the corruption for posterity anyway)
- if you don't, you can try "git unpack-objects -r". See the man-page on
why you need to first _move_ the pack-file away:
mv <bad-pack-file> .git/bad-pack.pack
mv <bad-pack-index> .git/bad-index.index
git unpack-objects -r < .git/bad-pack.pack
this will unpack as many objects into loose format as it can. Hopefully
you haven't lost much.
- after that, the ones that you *did* lose, you can hopefully find in
older git repos: even if you didn't have the *full* new repo anywhere
else, other git repositories may have the particular objects that got
corrupted. "git fsck" will tell you what is missing, and you can just
point your .git/info/alternates file at other repositories to "steal"
objects from automatically.
- if you aren't missing any objects after that, you can now repack the
repository, and then remove the alternates file:
git repack -a -d
rm .git/info/alternates
because the repack will steal all the objects you need, and thus you
don't need alternates any more.
Finally: it would be very interesting to hear if you do something strange
or unusual that could have made your chances of getting corruption higher.
Have you ever seen random SIGSEV's or strange oopses, which could be a
sign of memory corruption on your machine? Do you do a lot of things over
NFS? (which really can corrupt things, especially in circumstances with
dodgy ethernet chips: the UDP checksums are very weak, and some ethernet
cards do not do a good job of checking the ethernet CRC's!).
> So, all I did was try to do a commit with the new git ... haven't
> recloned, or pulled from upstream...
Yes, don't do anything more (certainly do *not* repack or anything) until
you have tarred up and saved the current state, and then only _after_ you
have a good safe archive to restart from, try to fix it up.
And if you can make the git history available to outsiders, I'd love to
see the corrupt tar-file (it doesn't have to be *public*, if you just can
trust me and perhaps a few other people with the data).
So far, as far as I can recall, we've certainly had people screw up their
own trees by mistake, but apart from that kind of "user error" things, the
only real corruption I recall was the single-bit error in a pack-file. We
were able to recover that, but in general, for safety, the best way to
protect your data is to replicate it across multiple independent machines
(something that git is _good_ at, happily).
Linus
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 18:19 ` Linus Torvalds
@ 2007-02-14 18:42 ` Linus Torvalds
2007-02-14 21:13 ` Bill Lear
1 sibling, 0 replies; 39+ messages in thread
From: Linus Torvalds @ 2007-02-14 18:42 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, git
On Wed, 14 Feb 2007, Linus Torvalds wrote:
>
> And if you can make the git history available to outsiders, I'd love to
> see the corrupt tar-file (it doesn't have to be *public*, if you just can
> trust me and perhaps a few other people with the data).
Side note: one reason why this is nice - even if you don't care about the
corruption and can fix it other ways - is that the last time we had the
one-bit corruption is also the reason why we now have the "-r" option to
git-unpack-objects.
In other words, real-life corruption is not just a really nasty event,
it's also a good way for *us* to verify that our recovery tools do as good
a job as they possibly can. Maybe there are other things like that "-r"
option where we could possibly do even better.
The git data structures are designed to be extremely robust, but there's
nothing they can do about "corruption after the fact". The same way that a
logging filesystem doesn't help if the disk itself starts getting read
errors, the git data structures aren't going to guarantee that you can't
lose data if you have actual disk or memory corruption going on.
The things git can do is:
- detection. The SHA1's should basically guarantee that you will never
ever have an _undetectable_ corruption anywhere (which is really really
easy with just about any other SCM)
- make replication easy (so that once you've detected corruption, you
have mirrors you can trust).
- and finally: in the absense of replication, we can do our damndest to
try to figure out what the data was. But in many ways, the fact that we
are really really good at compressing data (people do love their small
repositories) also means that we have basically no redundancy anywhere,
because redundancy is what compression gets rid of (both delta- and
zlib compression do it - it's very fundamentally what any compression
is based on)
but it's always interesting to have real-life corruption cases to verify.
Linus
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 17:45 ` Junio C Hamano
@ 2007-02-14 20:49 ` Bill Lear
2007-02-14 20:58 ` Bill Lear
` (3 more replies)
0 siblings, 4 replies; 39+ messages in thread
From: Bill Lear @ 2007-02-14 20:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wednesday, February 14, 2007 at 09:45:14 (-0800) Junio C Hamano writes:
>Bill Lear <rael@zopyra.com> writes:
>
>> % git fsck-objects --full
>> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
>> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
>>
>>
>> % /usr/bin/git --version
>> git version 1.4.4.1
>>
>> % /usr/bin/git fsck-objects --full
>> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
>> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
>>
>> So, all I did was try to do a commit with the new git ... haven't
>> recloned, or pulled from upstream...
>
>If you haven't packed the repository lately, the above indicates
>this is not an issue between 1.4.4.1 and 1.5.0, but you had a
>corrupt packfile before even started.
>
>How big is this pack, what platform are you working on and whose
>SHA-1 implementation do you use?
In order:
% cd .git/objects/pack
% ls -l
-r--r--r-- 1 rael software 77360 Feb 13 10:18 pack-23d1a9af78b4b78d...
-r--r--r-- 1 rael software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d...
[output of ls trimmed to width]
% uname -a
Linux lisa.zopyra.com 2.6.9-34.0.2.ELsmp #1 SMP Fri Jul 7 18:22:55 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux
I don't know which SHA-1 implementation I use --- I just installed git
and off I went. I do see this:
% which sha1sum
/usr/bin/sha1sum
% sha1sum --version
shasum (coreutils) 5.2.1
Written by Ulrich Drepper and Scott Miller.
[...]
But I'm not sure which library is in use --- how do I know?
>Also, do you have a huge blob in the repository? I do not know
>if it is related but the write_sha1_file_prepare() function on
>the codepath to write loose objects out would trigger the same
>bug...
I don't know what "huge" is, but the pack file seems to be the largest
and then one of the objects is listed at 28,604,986 bytes, but nothing
else is very large.
So, before I get to Linus's message, I did try doing this:
1) with 1.4.4.1 git, clone my public repo
2) in this new clone, make modifications to my files as before
3) with 1.5.0 git, do a commit
and I got the same blowup on commit, and this on fsck, with 1.5.0 git:
% git fsck-objects --full
error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
error: 00078437c23cbc04da52233f4f412219f88b8927: object corrupt or missing
fatal: unknown object type 5 in .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
and with 1.4.4.1 git:
% /usr/bin/git fsck-objects --full
error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
fatal: corrupted pack file .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
So (hopefully this is helpful) I look in my public repo for this pack
file:
% ls -l /repos/git/fus/objects/pack
total 88420
-r--r--r-- 1 blear software 10376 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.idx
-r--r--r-- 1 blear software 753437 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.pack
-r--r--r-- 1 blear software 77360 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
-r--r--r-- 1 blear software 89576130 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
and notice, it is different than the same pack on my just-cloned repo
(that is, the second clone, that I used to reproduce the first
failure):
% ls -l objects/pack/
total 87632
-r--r--r-- 1 blear software 77360 Feb 14 12:50 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
-r--r--r-- 1 blear software 89548154 Feb 14 12:52 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
and in my first-cloned repo:
% ls -l objects/pack/
total 85992
-r--r--r-- 1 blear software 77360 Feb 13 10:18 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
-r--r--r-- 1 blear software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
The .pack files have the same SHA, but different sizes (don't know
what that means).
I will continue digging and on to Linus's post...
Bill
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 20:49 ` Bill Lear
@ 2007-02-14 20:58 ` Bill Lear
2007-02-14 21:19 ` Linus Torvalds
2007-02-14 21:12 ` Junio C Hamano
` (2 subsequent siblings)
3 siblings, 1 reply; 39+ messages in thread
From: Bill Lear @ 2007-02-14 20:58 UTC (permalink / raw)
To: Junio C Hamano, git
I forgot to mention that fsck in my original public repo looks fine:
% cd /repos/git/fus
[with 1.4.4.1]
% GIT_DIR=. /usr/bin/git fsck-objects --full
dangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa
[with 1.5.0]
% GIT_DIR=. git fsck-objects --full
dangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa
Bill
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 20:49 ` Bill Lear
2007-02-14 20:58 ` Bill Lear
@ 2007-02-14 21:12 ` Junio C Hamano
2007-02-14 21:18 ` Bill Lear
2007-02-14 21:14 ` Nicolas Pitre
2007-02-14 21:32 ` Junio C Hamano
3 siblings, 1 reply; 39+ messages in thread
From: Junio C Hamano @ 2007-02-14 21:12 UTC (permalink / raw)
To: Bill Lear; +Cc: git
Bill Lear <rael@zopyra.com> writes:
>>How big is this pack, what platform are you working on and whose
>>SHA-1 implementation do you use?
>
> In order:
>
> % cd .git/objects/pack
> % ls -l
> -r--r--r-- 1 rael software 77360 Feb 13 10:18 pack-23d1a9af78b4b78d...
> -r--r--r-- 1 rael software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d...
>
> [output of ls trimmed to width]
>
> % uname -a
> Linux lisa.zopyra.com 2.6.9-34.0.2.ELsmp #1 SMP Fri Jul 7 18:22:55 CDT 2006 x86_64 x86_64 x86_64 GNU/Linux
>
> I don't know which SHA-1 implementation I use --- I just installed git
> and off I went. I do see this:
>
> % which sha1sum
> /usr/bin/sha1sum
> % sha1sum --version
> shasum (coreutils) 5.2.1
> Written by Ulrich Drepper and Scott Miller.
> [...]
>
> But I'm not sure which library is in use --- how do I know?
"ldd ~/git-master/bin/git" tells me that it links with libcrypto.so,
so I am using OpenSSL's SHA-1 implementation. I do not know
what your distro uses (or you hand built git yourself?).
I asked this question, because...
>>Also, do you have a huge blob in the repository? I do not know
>>if it is related but the write_sha1_file_prepare() function on
>>the codepath to write loose objects out would trigger the same
>>bug...
>
> I don't know what "huge" is, but the pack file seems to be the largest
> and then one of the objects is listed at 28,604,986 bytes, but nothing
> else is very large.
... we had a problem that some SHA-1 implementation gave bogus
results when we did this:
SHA_CTX ctx;
unsigned char sha1[20];
SHA1_Init(&ctx);
/* hash len bytes starting from buf */
SHA1_Update(&ctx, buf, len);
SHA1_Final(sha1, &ctx);
and asked to hash a large buffer in one go. One of the SHA1
implementations we ship ourselves (I think it was handcrafted
PPC one) used to have problems. But I do not think 27MB is
large enough to trigger such a library bug (the bug was integer
wraparound of a bit counter, I think).
So it looks more and more like a bit decay as Linus suspected...
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 18:19 ` Linus Torvalds
2007-02-14 18:42 ` Linus Torvalds
@ 2007-02-14 21:13 ` Bill Lear
2007-02-14 21:35 ` Linus Torvalds
1 sibling, 1 reply; 39+ messages in thread
From: Bill Lear @ 2007-02-14 21:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
On Wednesday, February 14, 2007 at 10:19:53 (-0800) Linus Torvalds writes:
>On Wed, 14 Feb 2007, Bill Lear wrote:
>> fatal: failed to find delta-pack base object 90bad0d280a6d7c155bbd9582b35ffcf5e3bdd27
>
>implies that the pack really is corrupt.
>...
> (b) it might be interesting for others (if you can make those
> pack-files available) to try to figure out what exactly the
> corruption was. We've done it before, when it turned out to be a
> single-bit error.
If you could tell me who I should contact about this, I will.
> - if you have other git archives or just back-ups of everything, just use
> them, and throw the corrupt one away entirely (but see above on why
> it's nice to have an archive of the corruption for posterity anyway)
I would prefer to help straighten this out --- I have a company repo
to fall back on, I have git 1.4 and other repos to fall back on, so
I'm safe.
> - if you don't, you can try "git unpack-objects -r". See the man-page on
> why you need to first _move_ the pack-file away:
>
> mv <bad-pack-file> .git/bad-pack.pack
> mv <bad-pack-index> .git/bad-index.index
>
> git unpack-objects -r < .git/bad-pack.pack
Since I can reproduce the error fairly readily, I can do this later.
>Finally: it would be very interesting to hear if you do something strange
>or unusual that could have made your chances of getting corruption higher.
>
>Have you ever seen random SIGSEV's or strange oopses, which could be a
>sign of memory corruption on your machine? Do you do a lot of things over
>NFS? (which really can corrupt things, especially in circumstances with
>dodgy ethernet chips: the UDP checksums are very weak, and some ethernet
>cards do not do a good job of checking the ethernet CRC's!).
No NFS, but I checked /var/log/messages. I see segfaults from git,
that I missed somehow (don't remember seeing anything awry on the
terminal):
Feb 14 10:05:07 lisa kernel: git[21648]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
Feb 14 10:05:43 lisa kernel: git[21710]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
Feb 14 10:06:28 lisa kernel: git[21858]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
Feb 14 10:10:04 lisa kernel: git[22385]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
Feb 14 11:01:56 lisa kernel: git[24446]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc888 error 4
Feb 14 11:02:34 lisa kernel: git[24479]: segfault at 0000000000000000 rip 0000003f5eb70a40 rsp 0000007fbfffc868 error 4
Feb 14 11:02:40 lisa kernel: git[24700]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc868 error 4
Feb 14 11:07:51 lisa kernel: git[24844]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc128 error 4
Feb 14 11:07:52 lisa kernel: git[24855]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc128 error 4
Feb 14 11:08:01 lisa kernel: git[24886]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc128 error 4
Feb 14 11:08:06 lisa kernel: git[24897]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc118 error 4
Feb 14 11:08:09 lisa kernel: git[24908]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc118 error 4
Feb 14 11:08:27 lisa kernel: git[24939]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
10:05 is just before I posted my first note of this to the git list, and
the first instance of a segfault that I see.
>And if you can make the git history available to outsiders, I'd love to
>see the corrupt tar-file (it doesn't have to be *public*, if you just can
>trust me and perhaps a few other people with the data).
Again, please let me know who to contact about helping on this.
Bill
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 20:49 ` Bill Lear
2007-02-14 20:58 ` Bill Lear
2007-02-14 21:12 ` Junio C Hamano
@ 2007-02-14 21:14 ` Nicolas Pitre
2007-02-14 21:32 ` Junio C Hamano
3 siblings, 0 replies; 39+ messages in thread
From: Nicolas Pitre @ 2007-02-14 21:14 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, git
On Wed, 14 Feb 2007, Bill Lear wrote:
> So (hopefully this is helpful) I look in my public repo for this pack
> file:
>
> % ls -l /repos/git/fus/objects/pack
> total 88420
> -r--r--r-- 1 blear software 10376 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.idx
> -r--r--r-- 1 blear software 753437 Feb 14 10:06 pack-1a201381fe465cbf4d771aec681aff6e12648ea0.pack
> -r--r--r-- 1 blear software 77360 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
> -r--r--r-- 1 blear software 89576130 Feb 13 10:57 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
>
> and notice, it is different than the same pack on my just-cloned repo
> (that is, the second clone, that I used to reproduce the first
> failure):
>
> % ls -l objects/pack/
> total 87632
> -r--r--r-- 1 blear software 77360 Feb 14 12:50 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
> -r--r--r-- 1 blear software 89548154 Feb 14 12:52 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
>
> and in my first-cloned repo:
>
> % ls -l objects/pack/
> total 85992
> -r--r--r-- 1 blear software 77360 Feb 13 10:18 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
> -r--r--r-- 1 blear software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
>
> The .pack files have the same SHA, but different sizes (don't know
> what that means).
The name of the pack corresponds to the list of objects it contains.
The way those objects are packed can change the size and the raw content
of the pack file, but they still should contain the equivalent data. So
this size difference is not a sign of problem.
Nicolas
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 21:12 ` Junio C Hamano
@ 2007-02-14 21:18 ` Bill Lear
0 siblings, 0 replies; 39+ messages in thread
From: Bill Lear @ 2007-02-14 21:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On Wednesday, February 14, 2007 at 13:12:22 (-0800) Junio C Hamano writes:
>Bill Lear <rael@zopyra.com> writes:
>...
>"ldd ~/git-master/bin/git" tells me that it links with libcrypto.so,
>so I am using OpenSSL's SHA-1 implementation. I do not know
>what your distro uses (or you hand built git yourself?).
Should have known --- I hand-built it myself, and thought perhaps
it was a configure option (output truncated):
% ldd /opt/git-1.5.0/bin/git
libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000003de1300000)
% ldd /usr/bin/git
libcrypto.so.4 => /lib64/libcrypto.so.4 (0x0000003de1300000)
So, both 1.5 and 1.4.4.1 are using OpenSSL, I reckon.
>So it looks more and more like a bit decay as Linus suspected...
Strange: given that fsck works on my public repo, with both 1.4.4.1
and with 1.5.0, and I reproduced this easily and fsck barfs on
both of my failed repos. I can't imagine this is really a disk
error of any kind.
Bill
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 20:58 ` Bill Lear
@ 2007-02-14 21:19 ` Linus Torvalds
2007-02-14 21:40 ` Bill Lear
0 siblings, 1 reply; 39+ messages in thread
From: Linus Torvalds @ 2007-02-14 21:19 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, git
On Wed, 14 Feb 2007, Bill Lear wrote:
>
> I forgot to mention that fsck in my original public repo looks fine:
>
> % cd /repos/git/fus
>
> [with 1.4.4.1]
> % GIT_DIR=. /usr/bin/git fsck-objects --full
> dangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa
>
> [with 1.5.0]
> % GIT_DIR=. git fsck-objects --full
> dangling commit 828c0a0649d2d6b43ed13853bba33f7764f034fa
Ahh. So it's literally just the clone that fails?
What happens if you do *just*
git clone /repos/git/fus new
cd new
git fsck --full
and nothing else?
Linus
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 20:49 ` Bill Lear
` (2 preceding siblings ...)
2007-02-14 21:14 ` Nicolas Pitre
@ 2007-02-14 21:32 ` Junio C Hamano
3 siblings, 0 replies; 39+ messages in thread
From: Junio C Hamano @ 2007-02-14 21:32 UTC (permalink / raw)
To: Bill Lear; +Cc: git
Bill Lear <rael@zopyra.com> writes:
> ... I did try doing this:
>
> 1) with 1.4.4.1 git, clone my public repo
> 2) in this new clone, make modifications to my files as before
> 3) with 1.5.0 git, do a commit
>
> and I got the same blowup on commit, and this on fsck, with 1.5.0 git:
>
> % git fsck-objects --full
> error: Packfile .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack SHA1 mismatch with itself
> error: 00078437c23cbc04da52233f4f412219f88b8927: object corrupt or missing
> fatal: unknown object type 5 in .git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
If you stop after cloning but before making a modification, is
the repository in good shape?
> % ls -l objects/pack/
> total 85992
> -r--r--r-- 1 blear software 77360 Feb 13 10:18 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.idx
> -r--r--r-- 1 blear software 87874337 Feb 14 10:00 pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
>
> The .pack files have the same SHA, but different sizes (don't know
> what that means).
That is usually not a problem; the name reflects the names of
objects contained in the pack (so both have the same set of
objects), but the actual raw contents (and the offsets recorded
in corresponding .idx file) depends on the packing parameters
(window, depth and deltabaseoffset).
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 21:13 ` Bill Lear
@ 2007-02-14 21:35 ` Linus Torvalds
0 siblings, 0 replies; 39+ messages in thread
From: Linus Torvalds @ 2007-02-14 21:35 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, git
On Wed, 14 Feb 2007, Bill Lear wrote:
>
> No NFS, but I checked /var/log/messages. I see segfaults from git,
> that I missed somehow (don't remember seeing anything awry on the
> terminal):
>
> Feb 14 10:05:07 lisa kernel: git[21648]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
> Feb 14 10:05:43 lisa kernel: git[21710]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
> Feb 14 10:06:28 lisa kernel: git[21858]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
>
> 10:05 is just before I posted my first note of this to the git list, and
> the first instance of a segfault that I see.
Ok, this is almost certainly what's up. For some strange reason your git
binary segfaults on the clone. The scary thing is, it left your cloned
repo in a bad state without even telling you. That's not good. Normally
we should always die() and give a _reason_ for a failure.
If you have that particular git binary, doing a
gdb git
and then at the gdb prompt doing
x/5i 0x0000003f5eb709d0
will at least tell where the SIGSEGV happened, but it doesn't give a
backtrace so unless it's obvious, it can be a bit hard to debug remotely..
Linus
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 21:19 ` Linus Torvalds
@ 2007-02-14 21:40 ` Bill Lear
2007-02-14 21:47 ` Junio C Hamano
` (4 more replies)
0 siblings, 5 replies; 39+ messages in thread
From: Bill Lear @ 2007-02-14 21:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
WAAAAAIAMINIT ... I think I see it:
% perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
Could I have corrupted the pack file? I'll bet $50 I did:
% [yet another clone]
% xgrep -l '[$]Id'
./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
[...]
%!@#$&$%(@@@!!!
I sent this list to a Perl script to nuke CVS Ids! I invoked this
one level up in my directories, not in my source tree, and .git
got picked up.
[Really, Really Red Shame Face Here]
Ok, I win $50, and I owe each of you a bottle of very good wine for
wasting your time. Just send me an email privately to tell me what
you prefer ... seriously, very seriously ....
I am, however, still curious about the git segfaults in my
/var/log/messages.
Bill
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 21:40 ` Bill Lear
@ 2007-02-14 21:47 ` Junio C Hamano
2007-02-14 21:52 ` Junio C Hamano
2007-02-14 22:02 ` Johannes Schindelin
` (3 subsequent siblings)
4 siblings, 1 reply; 39+ messages in thread
From: Junio C Hamano @ 2007-02-14 21:47 UTC (permalink / raw)
To: Bill Lear; +Cc: Linus Torvalds, git
Bill Lear <rael@zopyra.com> writes:
> WAAAAAIAMINIT ... I think I see it:
>
> % perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
>
> Could I have corrupted the pack file? I'll bet $50 I did:
>
> % [yet another clone]
> % xgrep -l '[$]Id'
> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
> [...]
>
> %!@#$&$%(@@@!!!
We all make mistakes. Thanks for being honest.
The segfaults could be from "git commit" codepath, not from when
you cloned. I could try corrupting a packfile in my repository
and see where it dies, perhaps later.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 21:47 ` Junio C Hamano
@ 2007-02-14 21:52 ` Junio C Hamano
2007-02-14 22:04 ` Johannes Schindelin
0 siblings, 1 reply; 39+ messages in thread
From: Junio C Hamano @ 2007-02-14 21:52 UTC (permalink / raw)
To: Bill Lear; +Cc: Linus Torvalds, git
Junio C Hamano <junkio@cox.net> writes:
> Bill Lear <rael@zopyra.com> writes:
>
>> WAAAAAIAMINIT ... I think I see it:
>>
>> % perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
>>
>> Could I have corrupted the pack file? I'll bet $50 I did:
>>
>> % [yet another clone]
>> % xgrep -l '[$]Id'
>> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
>> [...]
>>
>> %!@#$&$%(@@@!!!
>
> We all make mistakes. Thanks for being honest.
By the way, I sometimes think it might be worth doing this:
$ chmod a-r .git/
We always access files by explicit paths and never ask "ls .git/foo*"
to find what are under .git/ directory.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 21:40 ` Bill Lear
2007-02-14 21:47 ` Junio C Hamano
@ 2007-02-14 22:02 ` Johannes Schindelin
2007-02-14 22:27 ` Nicolas Pitre
` (2 subsequent siblings)
4 siblings, 0 replies; 39+ messages in thread
From: Johannes Schindelin @ 2007-02-14 22:02 UTC (permalink / raw)
To: Bill Lear; +Cc: Linus Torvalds, Junio C Hamano, git
Hi,
On Wed, 14 Feb 2007, Bill Lear wrote:
> I sent this list to a Perl script to nuke CVS Ids! I invoked this one
> level up in my directories, not in my source tree, and .git got picked
> up.
Do not be embarassed. Yours truly managed something similar (actually, I
was running a script to kill all \r from files supposed to be text, and I
forgot the "*" in `find * -type f`), but _without_ a backup. That was fun.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 21:52 ` Junio C Hamano
@ 2007-02-14 22:04 ` Johannes Schindelin
2007-02-14 22:13 ` Junio C Hamano
0 siblings, 1 reply; 39+ messages in thread
From: Johannes Schindelin @ 2007-02-14 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bill Lear, Linus Torvalds, git
Hi,
On Wed, 14 Feb 2007, Junio C Hamano wrote:
> By the way, I sometimes think it might be worth doing this:
>
> $ chmod a-r .git/
>
> We always access files by explicit paths and never ask "ls .git/foo*" to
> find what are under .git/ directory.
If so, please make it unconfigurable. I use tab-completion in the git
directory quite often.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 22:04 ` Johannes Schindelin
@ 2007-02-14 22:13 ` Junio C Hamano
2007-02-14 22:32 ` Johannes Schindelin
` (2 more replies)
0 siblings, 3 replies; 39+ messages in thread
From: Junio C Hamano @ 2007-02-14 22:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Bill Lear, Linus Torvalds, git
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 14 Feb 2007, Junio C Hamano wrote:
>
>> By the way, I sometimes think it might be worth doing this:
>>
>> $ chmod a-r .git/
>>
>> We always access files by explicit paths and never ask "ls .git/foo*" to
>> find what are under .git/ directory.
>
> If so, please make it unconfigurable. I use tab-completion in the git
> directory quite often.
Do you mean "configurable"?
I wonder what you are doing inside .git directory in the first
place. I never chdir() into it myself, but that may be because
I practicaly live inside Emacs.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 21:40 ` Bill Lear
2007-02-14 21:47 ` Junio C Hamano
2007-02-14 22:02 ` Johannes Schindelin
@ 2007-02-14 22:27 ` Nicolas Pitre
2007-02-14 22:41 ` Bill Lear
2007-02-14 23:24 ` Error converting from 1.4.4.1 to 1.5.0? Linus Torvalds
2007-02-14 23:03 ` Linus Torvalds
2007-02-15 8:40 ` Uwe Kleine-König
4 siblings, 2 replies; 39+ messages in thread
From: Nicolas Pitre @ 2007-02-14 22:27 UTC (permalink / raw)
To: Bill Lear; +Cc: Linus Torvalds, Junio C Hamano, git
On Wed, 14 Feb 2007, Bill Lear wrote:
> WAAAAAIAMINIT ... I think I see it:
>
> % perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
>
> Could I have corrupted the pack file? I'll bet $50 I did:
>
> % [yet another clone]
> % xgrep -l '[$]Id'
> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
> [...]
>
> %!@#$&$%(@@@!!!
But...... your pack file is read-only, isn't it?
Is perl -i so bad to overwrite even read only files?
Nicolas
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 22:13 ` Junio C Hamano
@ 2007-02-14 22:32 ` Johannes Schindelin
2007-02-15 0:41 ` Jakub Narebski
2007-02-15 0:54 ` Olivier Galibert
2 siblings, 0 replies; 39+ messages in thread
From: Johannes Schindelin @ 2007-02-14 22:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Bill Lear, Linus Torvalds, git
Hi,
On Wed, 14 Feb 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 14 Feb 2007, Junio C Hamano wrote:
> >
> >> By the way, I sometimes think it might be worth doing this:
> >>
> >> $ chmod a-r .git/
> >>
> >> We always access files by explicit paths and never ask "ls .git/foo*" to
> >> find what are under .git/ directory.
> >
> > If so, please make it unconfigurable. I use tab-completion in the git
> > directory quite often.
>
> Do you mean "configurable"?
No. I meant "unconfigurable", since the sane default _would_ be a-r.
But then, I see that I was silly. This chmod is done on git-init time, and
easy to undo _if_ you want it.
So, colour me a supporter of that feature.
> I wonder what you are doing inside .git directory in the first place.
> I never chdir() into it myself, but that may be because I practicaly
> live inside Emacs.
:-) Lucky you. Since long time, I became a vi user, not out of fun, but
out of necessity. I had to work on many machines which had vi installed,
but not emacs. On some, my quota was not large enough to compile the
beast, so I eventually gave in.
Back to the subject: Sometimes I just want to look if a certain file is
present. But I cannot be bothered to really type out ".git/index.lock",
but rather I do ".g<TAB>/i<TAB>.<TAB>"...
Anyway, here is a minimal (completely untested) patch to do what you
proposed:
-- snipsnap --
[PATCH] init: create GIT_DIR non-readable
We access all files in GIT_DIR by name, so we do not really need it to be
readable. However, it is less easy to corrupt the repository
unintentionally when it is not readable.
Those who want to be able to see the contents of GIT_DIR, always can just
do a `chown u+r $GIT_DIR`.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-init-db.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 12e43d0..8496269 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -18,7 +18,7 @@
static void safe_create_dir(const char *dir, int share)
{
- if (mkdir(dir, 0777) < 0) {
+ if (mkdir(dir, share ? 0777 : 0333) < 0) {
if (errno != EEXIST) {
perror(dir);
exit(1);
^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 22:27 ` Nicolas Pitre
@ 2007-02-14 22:41 ` Bill Lear
2007-02-15 1:18 ` OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?) Simon 'corecode' Schubert
2007-02-14 23:24 ` Error converting from 1.4.4.1 to 1.5.0? Linus Torvalds
1 sibling, 1 reply; 39+ messages in thread
From: Bill Lear @ 2007-02-14 22:41 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Linus Torvalds, Junio C Hamano, git
On Wednesday, February 14, 2007 at 17:27:24 (-0500) Nicolas Pitre writes:
>On Wed, 14 Feb 2007, Bill Lear wrote:
>> %!@#$&$%(@@@!!!
>
>But...... your pack file is read-only, isn't it?
Correct.
>Is perl -i so bad to overwrite even read only files?
It is bad. Evil. I will sue Larry Wall for making me, an innocent,
look so foolish.
I'm still muttering to myself that I could be that dumb...
Bill
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 21:40 ` Bill Lear
` (2 preceding siblings ...)
2007-02-14 22:27 ` Nicolas Pitre
@ 2007-02-14 23:03 ` Linus Torvalds
2007-02-15 8:40 ` Uwe Kleine-König
4 siblings, 0 replies; 39+ messages in thread
From: Linus Torvalds @ 2007-02-14 23:03 UTC (permalink / raw)
To: Bill Lear; +Cc: Junio C Hamano, git
On Wed, 14 Feb 2007, Bill Lear wrote:
>
> WAAAAAIAMINIT ... I think I see it:
>
> % perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
>
> Could I have corrupted the pack file? I'll bet $50 I did:
Heh.
I'm relieved git is off the hook, although I think we should still look at
that SIGSEGV. We might well have some situation where we react badly do a
corrupt pack (most likely, by having one of the object parsing routines
return NULL, and then we follow that NULL pointer rather than saying "bad
object").
> % [yet another clone]
> % xgrep -l '[$]Id'
> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
This is just one reason I don't ever use 'find' on my source tree. I long
ago used to do
find . -name '*.c' | xargs grep ...
etc, but especially with git I have almost totally stopped using "xargs
grep" entirely - to the point where I actually end up importing tar-files
into new git archives just because I'm so used to "git grep".
So I would suggest that in order to avoid this in the future, you teach
your fingers to say "git grep" instead of "xgrep"., which I assume is just
some local alias of yours for "find .. | xargs grep"?
"git grep" really works wonderfully well, and you could have just done
perl -pi -e 's/.*\$Id.*//sx' $(git grep -l '[$]Id')
instead.
("git grep" is much nicer than "xargs grep" in many other ways too. You
can ask it to limit itself to a certain pattern of filenames etc by doing
git grep -l '[$]Id' -- 'net/*.[ch]'
as long as you realize that the name pattern for git grep considers '*' to
act like '**' does for some shells - ie it globs against '/'too, so the
above will find any C and header files under the net/ directory, however
deep they are.. And you can ask it to grep in just a certain revision etc
too).
Once you get used to "git grep", I bet you'll forget all about "xgrep",
and won't have to worry about going into the .git/ directory by mistake
any more.
There are other tricks you can do, but they are somewhat inconvenient.
They range from making ".git" a symlink to somewhere else (to stop
"find" from following it), and in your case, since you apparently already
have an "xgrep" alias for this, you could just teach your "find" thing to
do something like what we do in the kernel Makefile:
RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o -name CVS -o -name .pc -o -name .hg -o -name .git \) -prune -o
and then we use
find . $(RCS_FIND_IGNORE) ...
which knows to ignore ".git" directories along with all the other
SCCS/CVS/SVN/BK/etc directories.
Linus
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 22:27 ` Nicolas Pitre
2007-02-14 22:41 ` Bill Lear
@ 2007-02-14 23:24 ` Linus Torvalds
1 sibling, 0 replies; 39+ messages in thread
From: Linus Torvalds @ 2007-02-14 23:24 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Bill Lear, Junio C Hamano, git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1011 bytes --]
On Wed, 14 Feb 2007, Nicolas Pitre wrote:
>
> But...... your pack file is read-only, isn't it?
Almost any "edit in place" operation under UNIX is invariably a question
of "read old file + write new file + mv new old".
As such, to be read-only for a lot of programs, you actually need to not
just make the *file* read-only, you need to make the *directory* read-only
too.
Or you need to use only tools that explicitly check (a lot of editors will
do that, for example, because in an RCS world you're supposed to do magic
things to actually edit a file).
So I'm not at all surprised that "-pi" (where the "i" stands for
"in-place") will overwrite read-only files.
I'm sure there is some random character that makes perl check, and not do
it. Probably a sequence of unusual characters that makes it look like a
swear-word.
Maybe "perl -pi -%££@$" will do it. And if not, just add random characters
until it works. "It's the perl way".
Linus "Yeah, I never really got the 'perl way'" Torvalds
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 22:13 ` Junio C Hamano
2007-02-14 22:32 ` Johannes Schindelin
@ 2007-02-15 0:41 ` Jakub Narebski
2007-02-15 0:54 ` Olivier Galibert
2 siblings, 0 replies; 39+ messages in thread
From: Jakub Narebski @ 2007-02-15 0:41 UTC (permalink / raw)
To: git
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> On Wed, 14 Feb 2007, Junio C Hamano wrote:
>>
>>> By the way, I sometimes think it might be worth doing this:
>>>
>>> $ chmod a-r .git/
>>>
>>> We always access files by explicit paths and never ask "ls .git/foo*" to
>>> find what are under .git/ directory.
>>
>> If so, please make it unconfigurable. I use tab-completion in the git
>> directory quite often.
>
> Do you mean "configurable"?
>
> I wonder what you are doing inside .git directory in the first
> place. I never chdir() into it myself, but that may be because
> I practicaly live inside Emacs.
I look what interesting is in here (like COMMIT_EDITMSG, MERGE_HEAD,
ORIG_HEAD, some StGIT templates,....).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 22:13 ` Junio C Hamano
2007-02-14 22:32 ` Johannes Schindelin
2007-02-15 0:41 ` Jakub Narebski
@ 2007-02-15 0:54 ` Olivier Galibert
2007-02-15 1:36 ` Johannes Schindelin
2 siblings, 1 reply; 39+ messages in thread
From: Olivier Galibert @ 2007-02-15 0:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Bill Lear, Linus Torvalds, git
On Wed, Feb 14, 2007 at 02:13:01PM -0800, Junio C Hamano wrote:
> I wonder what you are doing inside .git directory in the first
> place. I never chdir() into it myself, but that may be because
> I practicaly live inside Emacs.
"Hmmm, how did I call this remote already? ls .g<TAB>rem<TAB><RET>
ahhh, I see".
Emacs happily does the completion too, but obviously also requires +r
for that.
OG.
^ permalink raw reply [flat|nested] 39+ messages in thread
* OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)
2007-02-14 22:41 ` Bill Lear
@ 2007-02-15 1:18 ` Simon 'corecode' Schubert
2007-02-15 2:13 ` Shawn O. Pearce
2007-02-15 9:13 ` Andy Parkins
0 siblings, 2 replies; 39+ messages in thread
From: Simon 'corecode' Schubert @ 2007-02-15 1:18 UTC (permalink / raw)
To: Bill Lear; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 532 bytes --]
Bill Lear wrote:
> I'm still muttering to myself that I could be that dumb...
Still better than trying to backup with
tar czvf data* destfile.tar.gz
automatic tape backup is a real helper then :)
cheers
simon
--
Serve - BSD +++ RENT this banner advert +++ ASCII Ribbon /"\
Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ /
Party Enjoy Relax | http://dragonflybsd.org Against HTML \
Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-15 0:54 ` Olivier Galibert
@ 2007-02-15 1:36 ` Johannes Schindelin
0 siblings, 0 replies; 39+ messages in thread
From: Johannes Schindelin @ 2007-02-15 1:36 UTC (permalink / raw)
To: Olivier Galibert; +Cc: Junio C Hamano, Bill Lear, Linus Torvalds, git
Hi,
On Thu, 15 Feb 2007, Olivier Galibert wrote:
> On Wed, Feb 14, 2007 at 02:13:01PM -0800, Junio C Hamano wrote:
> > I wonder what you are doing inside .git directory in the first
> > place. I never chdir() into it myself, but that may be because
> > I practicaly live inside Emacs.
>
> "Hmmm, how did I call this remote already? ls .g<TAB>rem<TAB><RET>
> ahhh, I see".
Hmm. That does not work for remotes which are stored in the config (which
is the default nowadays)...
So, what you described is obviously wrong.
Besides, "git remote" is way shorter. And it even completes if you
installed the bash completion script!
Ciao,
Dscho
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)
2007-02-15 1:18 ` OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?) Simon 'corecode' Schubert
@ 2007-02-15 2:13 ` Shawn O. Pearce
2007-02-15 2:51 ` Linus Torvalds
2007-02-15 9:13 ` Andy Parkins
1 sibling, 1 reply; 39+ messages in thread
From: Shawn O. Pearce @ 2007-02-15 2:13 UTC (permalink / raw)
To: Simon 'corecode' Schubert; +Cc: Bill Lear, git
Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
> Bill Lear wrote:
> >I'm still muttering to myself that I could be that dumb...
>
> Still better than trying to backup with
>
> tar czvf data* destfile.tar.gz
>
> automatic tape backup is a real helper then :)
or manual backup to "tape", where the tape device supplied was
the only disk... SunOS 4 did not take too kindly to its kernel,
swap space, root fs being overwritten...
Oddly enough, that system never booted again. Ever. We couldn't
even get it to see external (CD-ROM) based media. SCSI controller
also failed during the "tape" backup.
--
Shawn.
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)
2007-02-15 2:13 ` Shawn O. Pearce
@ 2007-02-15 2:51 ` Linus Torvalds
2007-02-15 10:24 ` Johannes Schindelin
2007-02-15 11:58 ` Bill Lear
0 siblings, 2 replies; 39+ messages in thread
From: Linus Torvalds @ 2007-02-15 2:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Simon 'corecode' Schubert, Bill Lear, git
On Wed, 14 Feb 2007, Shawn O. Pearce wrote:
> Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
> > Bill Lear wrote:
> > >I'm still muttering to myself that I could be that dumb...
> >
> > Still better than trying to backup with
> >
> > tar czvf data* destfile.tar.gz
> >
> > automatic tape backup is a real helper then :)
>
> or manual backup to "tape", where the tape device supplied was
> the only disk... SunOS 4 did not take too kindly to its kernel,
> swap space, root fs being overwritten...
Hey, I can beat that (stop me at any time you've heard this story. No? Ok,
then..)
I auto-dialed my harddisk.
I had this auto-dialer, that would send "+++" + "atz" + "atdt..." to dial
the number to the university dial-in farm that was always busy for hours
at a time, and since I've never been much of a user interface person ("No
really? Linus, please tell more! I would never have guessed!"), it was
basically
autodial /dev/ttyS1
or something very similar. It was really stupid too, so if it got some
other answer than "BUSY" or "CONNECTED" back (or timed out), it would just
go on to the next number and try again.
Anyway, the smarter among you will already see how I by mistake filled up
one of my harddisk partitions with Hayes "AT" modem commands, and deleted
my Minix installation. AND THE BASTARD NEVER ANSWERED!
That was one big (perhaps _the_) impetus for just deciding to make Linux
good enough that I wouldn't need to actually reinstall Minix. Happily, it
was already able to bootstrap itself at that point, it just wasn't quite
as good yet. I fixed that in short order, and indeed, I never did end up
feeding the 17 floppy disks into my computer to reinstall Minix.
Moral of the story: "Stupidity is what makes the world go round."
Or something like that.
Linus
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Error converting from 1.4.4.1 to 1.5.0?
2007-02-14 21:40 ` Bill Lear
` (3 preceding siblings ...)
2007-02-14 23:03 ` Linus Torvalds
@ 2007-02-15 8:40 ` Uwe Kleine-König
4 siblings, 0 replies; 39+ messages in thread
From: Uwe Kleine-König @ 2007-02-15 8:40 UTC (permalink / raw)
To: Bill Lear; +Cc: Linus Torvalds, Junio C Hamano, git
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
Bill Lear wrote:
> WAAAAAIAMINIT ... I think I see it:
>
> % perl -pi -e 's/.*\$Id.*//sx' $(xgrep -l '[$]Id')
>
> Could I have corrupted the pack file? I'll bet $50 I did:
>
> % [yet another clone]
> % xgrep -l '[$]Id'
> ./.git/objects/pack/pack-23d1a9af78b4b78d1f3750cf70f83cb91a20ba64.pack
> [...]
>
> %!@#$&$%(@@@!!!
I suffered from something like that, too. Since then I have a script
"ufind". It's a wrapper around find that ignores CVS, Subversion, Git
and hg metadata. Then "my" command would be:
$ ufind -type f -print0 | xargs -0 -r grep -lZ '[$]Id' | xargs -r perl -p -i -e 's/.../'
Where ... is something more restrictive that your .*\$Id.*
For the interessted the script is attached.
--
Uwe Kleine-König
cat /*dev/null; echo 'Hello World!';
cat > /dev/null <<*/
() { } int main() { printf("Hello World!\n");}
/* */
[-- Attachment #2: ufind --]
[-- Type: text/plain, Size: 477 bytes --]
#! /usr/bin/env python
# Copyright (C) Uwe Zeisberger
import itertools, os, sys
ignoreexpr = ['-type', 'd', '(', '-name', 'CVS', '-o', '-name', '.svn', '-o', '-name', '.git', '-o', '-name', '.hg', ')']
paths = list(itertools.takewhile(lambda x: x[0] not in '-(),!', sys.argv[1:]))
args = sys.argv[1 + len(paths):] or ['-true']
os.execvp('find', ['find'] + paths + ['('] + ignoreexpr + [')', '-prune', '-false', '-o', '-not', '('] + ignoreexpr + [')', '('] + args + [')'])
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)
2007-02-15 1:18 ` OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?) Simon 'corecode' Schubert
2007-02-15 2:13 ` Shawn O. Pearce
@ 2007-02-15 9:13 ` Andy Parkins
2007-02-15 14:30 ` Mark Wooding
1 sibling, 1 reply; 39+ messages in thread
From: Andy Parkins @ 2007-02-15 9:13 UTC (permalink / raw)
To: git; +Cc: Simon 'corecode' Schubert, Bill Lear
On Thursday 2007 February 15 01:18, Simon 'corecode' Schubert wrote:
> > I'm still muttering to myself that I could be that dumb...
How about this:
1) "I should like to clean up root's home directory"
2) cd /root; ls -la .
3) "Oh, there are a lot of config file in this directory that I don't need any
more"
4) rm -rf .*
Now start crying softly to yourself, when you realise that ".." is covered
by ".*". Now go to every computer you work on and put
export GLOBIGNORE=".:.."
In your .bashrc.
Boy, was my face red...
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
andyparkins@gmail.com
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)
2007-02-15 2:51 ` Linus Torvalds
@ 2007-02-15 10:24 ` Johannes Schindelin
2007-02-15 13:13 ` Michael K. Edwards
2007-02-15 11:58 ` Bill Lear
1 sibling, 1 reply; 39+ messages in thread
From: Johannes Schindelin @ 2007-02-15 10:24 UTC (permalink / raw)
To: Linus Torvalds
Cc: Shawn O. Pearce, Simon 'corecode' Schubert, Bill Lear, git
Hi,
On Wed, 14 Feb 2007, Linus Torvalds wrote:
> On Wed, 14 Feb 2007, Shawn O. Pearce wrote:
>
> > Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
> > > Bill Lear wrote:
> > > >I'm still muttering to myself that I could be that dumb...
> > >
> > > Still better than trying to backup with
> > >
> > > tar czvf data* destfile.tar.gz
> > >
> > > automatic tape backup is a real helper then :)
> >
> > or manual backup to "tape", where the tape device supplied was
> > the only disk... SunOS 4 did not take too kindly to its kernel,
> > swap space, root fs being overwritten...
>
> Hey, I can beat that (stop me at any time you've heard this story. No?
> Ok, then..)
We're having a dick contest? Well, I'm game.
> I auto-dialed my harddisk.
I connected a tape drive.
It was a SCSI tape drive, and I had a SCSI Zip drive, which was so often
connected/disconnected in-flight that the plug wore out. So I thought that
it should not be a problem to connect the SCSI tape drive to a running
system. Right? RIGHT?
BIG MISTAKE.
The SCSI adapter also hosted two RAID systems, one as a SCSI RAID, i.e.
managed by the adapter, and one as ATAPI RAID, i.e. managed by its own
embedded computer simulating one (actually, two) SCSI hard disks to the
SCSI adapter.
We wanted to backup some of the data, and that's why we connected the tape
drive.
First, we got write errors on the RAID. Then, one RAID (the SCSI one)
stopped working at all. The fans still moved air, but the bus no longer
moved _any_ bytes.
Panicked (Douglas Adams, where are you when I need you?), I disconnected
the tape drive, and the two RAID boxes (all of them were external, so
that was possible). I shut down the computer and let out a long breath of
hope.
In the course of several weeks, my days started with praying, connecting
one or both RAIDs to several SCSI adapter/computer pairings, hoping that I
could read _anything_ from them.
All of the data was lost. Four terabytes. 6-7 months work of three people.
To this date, the SCSI RAID is not working. After one week (through which
it did not work _at all_), the ATAPI RAID worked again (strangely enough),
but had lost the correct order of its 14 disks.
Even if I could reconstruct the correct order after two more weeks, I
could not get any data from the RAID, since I had nowhere nearly large
enough amounts of free disk space. And I could not teach the RAID the
correct order.
And the tape drive still does not work.
Okay, guys, top _that_.
Ciao,
Dscho
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)
2007-02-15 2:51 ` Linus Torvalds
2007-02-15 10:24 ` Johannes Schindelin
@ 2007-02-15 11:58 ` Bill Lear
1 sibling, 0 replies; 39+ messages in thread
From: Bill Lear @ 2007-02-15 11:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Shawn O. Pearce, Simon 'corecode' Schubert, git
On Wednesday, February 14, 2007 at 18:51:09 (-0800) Linus Torvalds writes:
>On Wed, 14 Feb 2007, Shawn O. Pearce wrote:
>> Simon 'corecode' Schubert <corecode@fs.ei.tum.de> wrote:
>> > Bill Lear wrote:
>> > >I'm still muttering to myself that I could be that dumb...
>> >
>> > Still better than trying to backup with
>> >
>> > tar czvf data* destfile.tar.gz
>> >
>> > automatic tape backup is a real helper then :)
>>
>> or manual backup to "tape", where the tape device supplied was
>> the only disk... SunOS 4 did not take too kindly to its kernel,
>> swap space, root fs being overwritten...
>
>Hey, I can beat that (stop me at any time you've heard this story. No? Ok,
>then..)
>
>I auto-dialed my harddisk.
>...
>That was one big (perhaps _the_) impetus for just deciding to make Linux
>good enough that I wouldn't need to actually reinstall Minix. ...
>was already able to bootstrap itself at that point, it just wasn't quite
>as good yet. I fixed that in short order, and indeed, I never did end up
>feeding the 17 floppy disks into my computer to reinstall Minix.
>
>Moral of the story: "Stupidity is what makes the world go round."
Agreed. I often think stupid mistakes are a way of injecting random
--- and at the time, unwelcome --- searches into creative solution
spaces.
As in other cases, this one involved an extremely simple answer very
close to the start of the solution space, but (thanks to me), we drug
this out all over the place and got to explore lots of things we
otherwise wouldn't have.
Bill
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)
2007-02-15 10:24 ` Johannes Schindelin
@ 2007-02-15 13:13 ` Michael K. Edwards
0 siblings, 0 replies; 39+ messages in thread
From: Michael K. Edwards @ 2007-02-15 13:13 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Shawn O. Pearce,
Simon 'corecode' Schubert, Bill Lear, git
Not quite in the same vein, but perhaps amusing to Silicon Valley veterans:
I worked for several years for a 64-bit processor + workstation vendor
that shall remain nameless. There was this one guy in the other
building who built the kernels for the 64-bit UNIX variant that
shipped with US models. He had a SunOS 4 box on his desk that
happened to be the only machine in the world where his magic
32-to-64-bit cross-compiler generated working kernels, for reasons no
one ever fully understood. The external SCSI died one day, and either
there were no backups or they wouldn't restore cleanly. I don't think
they ever shipped another kernel update.
I can't swear to the accuracy of that story, though; my mind was on
the million-dollar "high availability" NFS server deployment I was
swept up in. The vendor never did get the electricals straight on the
shared SCSI bus, possibly because we had shelled out for redundant
power supplies via independent UPSes all the way out to the backup
generator, probably creating a gimongous ground loop. Kept frying the
third-party SCSI cards that were the key to the whole system, and
scrambled the contents of the terabyte RAID more than once. I don't
think those backups ever worked, either. The whole kit got ripped out
after some months of chaos and replaced with in-house gear, which
never worked right either.
Somewhere along the way, I figured out that the whole company (a U.S.
subsidiary of a Japanese multinational) was a clever arbitrage of the
Japanese tax system. As I understand it, they got tax credits for
foreign direct investment each quarter, then turned around and sent
most of the check back to the parent company to purchase custom DIMMs
at absurd prices, earning yet more tax credits for export in a
critical high-tech product sector. They made a tidy profit at the
Japanese taxpayers' expense even if we accomplished nothing
whatsoever.
The dedicated chip design and verification team didn't seem to have
cottoned onto this, though, and went through literally dozens of spins
(using the parent's semiconductor manufacturing division, natch).
Their design simulated substantially correctly at the logic level
(nothing you couldn't work around in the compiler) from the beginning,
but actual fabrication exposed problem after problem in the cell
library associated with the parent company's recent process shrink.
(Naturally, the NRE sent back to the parent for each chip spin also
qualified for super-duper tax credits.)
By the time the similar processor division back in Japan went through
the same shrink, the cell library and design rule kinks were all
worked out. So they got working silicon on the first spin where the
logic was correct (which was not, if I recall correctly, anything
close to the first spin; but they probably weren't charged NRE).
Guess which division took the fall? Hint: the tax credits expired in
2001, and so did the US subsidiary. They got another tax credit for
liquidation losses, of course. Legend at the time had it that the
company had never had a break-even quarter in 11 years of existence,
and had burned more actual cash than any Silicon Valley startup of its
era. (In retrospect the numbers don't appear to support the latter
claim.)
I got to do some fun stuff while I was there, though, including a
Frankenstein monster of an encrypted CVS transport that slotted SSLeay
into the GSSAPI interface intended for Kerberos. (Given the choice of
Kerberizing the site or running our own CA for client certs, we picked
the latter.) Although we had the source to Solaris, UnixWare, and
Windows NT all under one roof, the "secure" version control was not
for any of these. It was reserved for the real crown-jewels-on-loan:
the source to the OpenBoot PROM. Go figure.
Cheers,
- Michael
^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?)
2007-02-15 9:13 ` Andy Parkins
@ 2007-02-15 14:30 ` Mark Wooding
0 siblings, 0 replies; 39+ messages in thread
From: Mark Wooding @ 2007-02-15 14:30 UTC (permalink / raw)
To: git
Andy Parkins <andyparkins@gmail.com> wrote:
> 4) rm -rf .*
I'm nowhere near that impressive, unfortunately.
Once upon a time, I was trying to build some package (I forget which)
from its source distribution. It was an GNU-y Autoconf kind of thing.
I didn't want to install it globally at that point, just in my home
directory. So I said
$ ./configure --prefix=~
$ make
$ make install
So far, so good. Now try to run the thing.
$ foo
bash: foo: command not found
Oh. Where's it gone?
$ ls
That's annoying. Bad shell. It's failed to expand `~', and just put
everything in a directory called `~' in my build tree. Bugger. I don't
want it there.
$ rm -rf ~
I wonder why it's taking so lo... ^C^C^C^C
-- [mdw]
^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2007-02-15 14:30 UTC | newest]
Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-14 16:12 Error converting from 1.4.4.1 to 1.5.0? Bill Lear
2007-02-14 17:07 ` Bill Lear
2007-02-14 17:15 ` Junio C Hamano
2007-02-14 17:20 ` Bill Lear
2007-02-14 17:45 ` Junio C Hamano
2007-02-14 20:49 ` Bill Lear
2007-02-14 20:58 ` Bill Lear
2007-02-14 21:19 ` Linus Torvalds
2007-02-14 21:40 ` Bill Lear
2007-02-14 21:47 ` Junio C Hamano
2007-02-14 21:52 ` Junio C Hamano
2007-02-14 22:04 ` Johannes Schindelin
2007-02-14 22:13 ` Junio C Hamano
2007-02-14 22:32 ` Johannes Schindelin
2007-02-15 0:41 ` Jakub Narebski
2007-02-15 0:54 ` Olivier Galibert
2007-02-15 1:36 ` Johannes Schindelin
2007-02-14 22:02 ` Johannes Schindelin
2007-02-14 22:27 ` Nicolas Pitre
2007-02-14 22:41 ` Bill Lear
2007-02-15 1:18 ` OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?) Simon 'corecode' Schubert
2007-02-15 2:13 ` Shawn O. Pearce
2007-02-15 2:51 ` Linus Torvalds
2007-02-15 10:24 ` Johannes Schindelin
2007-02-15 13:13 ` Michael K. Edwards
2007-02-15 11:58 ` Bill Lear
2007-02-15 9:13 ` Andy Parkins
2007-02-15 14:30 ` Mark Wooding
2007-02-14 23:24 ` Error converting from 1.4.4.1 to 1.5.0? Linus Torvalds
2007-02-14 23:03 ` Linus Torvalds
2007-02-15 8:40 ` Uwe Kleine-König
2007-02-14 21:12 ` Junio C Hamano
2007-02-14 21:18 ` Bill Lear
2007-02-14 21:14 ` Nicolas Pitre
2007-02-14 21:32 ` Junio C Hamano
2007-02-14 18:19 ` Linus Torvalds
2007-02-14 18:42 ` Linus Torvalds
2007-02-14 21:13 ` Bill Lear
2007-02-14 21:35 ` Linus Torvalds
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).