git-repair - [no description]

	Commit message (Collapse)	Author	Age
*	Add swapping 2 files test case.	Joey Hess	2014-02-24
\|
*	merge from git-annex	Joey Hess	2014-02-24
\|
*	Check git version at run time.	Joey Hess	2014-01-21
\|
*	update	Joey Hess	2014-01-15
\|
*	prep releasedebian/1.20140115 1.20140115	Joey Hess	2014-01-15
\|
*	repair: Fix bug in packed refs file exploding code that caused a .gitrefs ↵	Joey Hess	2014-01-15
\| \| \| \|	directory to be created instead of .git/refs
*	Support old git versions from before git fsck --no-dangling was implemented.	Joey Hess	2014-01-13
\|
*	prep release1.20131213	Joey Hess	2013-12-13
\|
*	merge from git-annex	Joey Hess	2013-12-10
\|
*	prep release	Joey Hess	2013-12-03
\|
*	Fix build deps. Closes: #731179	Joey Hess	2013-12-03
\|
*	update descs	Joey Hess	2013-11-22
\|
*	releasing package git-repair version 1.201311221.20131122	Joey Hess	2013-11-22
\|
*	clean up	Joey Hess	2013-11-21
\|
*	improve findMissing	Joey Hess	2013-11-21
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	git cat-file -p cannot be relied on to tell when an object is corrupt. If it fails, the fsck may not find all bad objects -- but as long as fsck exits nonzero, it will return a failing fsckresult, and so recovery will run. In recovery, the objects get unpacked. This allows the improved findMissing to find all corrupt loose objects when fsck is run again as part of the recovery. Removed the repack / prune-packed workaround that I added earlier to find corrupt loose objects that fsck wasn't finding. That was slow, and we want to keep all loose objects, so that findMissing will work. And, it's unncessary, now that findMissing is fixed. Also, fixed some places where unreadable files would crash recovery.
*	combine test program into git-repair	Joey Hess	2013-11-21
\|
*	more 0s	Joey Hess	2013-11-21
\|
*	remove fsck tryharder code	Joey Hess	2013-11-20
\| \| \| \| \| \|	It turned out to be broken, and led to failures. 6d67245728bbbc07ad1eeaf5b3c49f64c6bbcd11 was a better fix for the problem that code tried to fix.
*	update	Joey Hess	2013-11-20
\|
*	try to recover even if git fsck cannot be coaxed to tell us any bad objects	Joey Hess	2013-11-20
\| \| \| \| \| \| \|	Sometimes git fsck outputs no shas even with --verbose, but fails, due to badly corrupt objects. The best thing to do in this situation is to try to pull and rsync from remotes, hoping that the bad objects will be overwritten.
*	Write a dummy .git/HEAD if the file is missing, as git otherwise will not ↵	Joey Hess	2013-11-20
\| \| \| \|	treat the repository as a git repo.
*	changelog	Joey Hess	2013-11-19
\|
*	use optparse-applicative	Joey Hess	2013-11-18
\|
*	debianization	Joey Hess	2013-11-18