* 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ 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; 40+ 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] 40+ messages in thread
* OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?) @ 2023-11-05 13:33 LON CHAIHONG 0 siblings, 0 replies; 40+ messages in thread From: LON CHAIHONG @ 2023-11-05 13:33 UTC (permalink / raw) To: corecode; +Cc: git, rael [-- Attachment #1: image0.png --] [-- Type: image/png, Size: 306157 bytes --] [-- Attachment #2: image1.jpeg --] [-- Type: image/jpeg, Size: 2636251 bytes --] [-- Attachment #3: Type: text/plain, Size: 21 bytes --] Sent from my iPhone ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2023-11-05 13:33 UTC | newest] Thread overview: 40+ 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 2023-11-05 13:33 OT: data destruction classics (was: Re: Error converting from 1.4.4.1 to 1.5.0?) LON CHAIHONG
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.