Dmitry Potapov schrieb: > On Wed, Apr 16, 2008 at 03:22:04PM +0200, Johannes Sixt wrote: >> Brian Foster schrieb: >>> Dmitry Potapov <dpotapov@xxxxxxxxx> correctly deduced: >>>> I suspect your original git repository has info/grafts >>> hi Dmitry, >>> >>> bingo! YES, it does: >> ... >>> the goal is to put things into a sane state so any new >>> clones are healthy. there's only one(?) existing clone, >>> which may or may not be(? become?) an issue. >> Just move info/grafts out of the way and you *may* be all set. Don't >> delete it - there might be a reason that the file exists. > > I believe that parts of history hidden by info/grafts are removed now, > otherwise git clone would not have problems to clone this repository. No. The reason why git clone'd repositories have problems is that git-upload-pack sends a pack that does not contain the hidden objects; but since the cloned repository doesn't have the info/grafts, it tries to look up the hidden, now missing, objects, and fails. >> - The repository is broken. Then 'git repack -f -d -a' was done while the >> grafts were in effect (and obviously the grafts had hidden parts of the >> history, which are now no longer available). > > Actually, 'git repack -f -d -a' does not remove hidden parts of the > history (because 'git prune-packed' does not remove hidden parts), but > 'git prune' does remove hidden parts. I believe 'git prune' relies on > 'git-fsck --unreachable', which outputs hidden parts as unreachable. > Perhaps, git-fsck should be corrected, so it will not treat hidden as > unreachable, because anything what is hidden is still reachable for > anyone who is trying to clone the repository. Actually, no. The trouble is that *all* tools obey grafts. Hence, git-repack -f -d -a will remove the hidden objects. But a subsequent fsck won't notice, because it *also* obeys the grafts. git prune will remove hidden objects only as long as they are loose; if they are already packed, then only a repack -f will remove them. Here's a thread with a proposal by Linus how to improve the situation, but nobody came along and implemented it: http://thread.gmane.org/gmane.comp.version-control.git/37744/focus=37908 -- Hannes -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
