| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <1153929715.13509.12.camel@localhost.localdomain> Date: Wed, 26 Jul 2006 17:01:55 +0100 From: Alan Cox <alan@...rguk.ukuu.org.uk> To: linux-kernel@...r.kernel.org, torvalds@...l.org Subject: Nasty git corruption problem Just hit a real nasty, although I suspect its not a common case but it does seem to show a problem git has other version control systems don't (so far anyway) During a git rebase my machine crashed. Git claims that the rebase is complete but contains none of the outstanding 30 odd patches. There is no .dotest directory and git-fsck-objects produces some warnings about a few dangling objects, but these objects aren't the relevant ones (at least directly) CVS and SVN in crashes don't lose old stuff, though they are pretty good at losing the last commit or two. Git rebase appears to be able to lose two weeks of old changes even though they were stable on disk, which is not good at all. Doing for i in *; do (cd $i; for j in *; do git-unpack-file $i$j; done; ); done shows that lots of the changes are still somewhere in the object tree but there seems to be no tool for fixing rather than moaning about objects dangling, and also no obvious way to fix it. Also curiously many of the objects appear linked somewhere but don't show up in the git-log for the afflicted branch at all. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists