Re: fsck --full is Ok, but clones are not, "missing commits"?!

["Brian Foster" <brian.foster@innova-card.com>]

Johannes Sixt <j.sixt@viscovery.net> helpfully observes:
>  Brian Foster schrieb:
>  > Dmitry Potapov <dpotapov@gmail.com> correctly deduced:
>  >>  I suspect your original git repository has info/grafts
>  >  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.

Hannes & Dmitry,

 thanks for the suggestions.  I've made (and carefully protected)
 multiple backups, and am doing all my experiments on copies, and
 have taken other protective steps, so no worries about accidents.

 moving  info/grafts  out of the way causes `fsck --full' to issue
 the same complaints as it does for clones.  conversely, copying
 info/grafts  to a clone makes `fsck --full' happy.  furthermore,
 close examination of that one pre-existing clone shows it has the
 identical  info/grafts  as the bare repository.  so that seems to
 have been what was previously being done (I'm now attempting to
 confirm this, and also to find out WHY).

 however, no joy at all with the suggestion:

>  Your best bet is to run 'git filter-branch --tag-name-filter cat -- --all'
>  on *a copy* of your bare repository (with info/grafts in place).  [ ... ]

 at toplevel of (a copy of) the bare repository, with  info/grafts
 in-place, and `fsck --full' happy:

	$ git version
	1.5.3
	$ git filter-branch --tag-name-filter cat -- --all   # at bare toplevel
	fatal: Not a git repository: '.git'
	You need to run this command from the toplevel of the working tree.
	$

 at toplevel of a (not-bare) clone, with  info/grafts  in-place,
 and a happy `fsck -full' (same machine so same git version):

	$ git filter-branch --tag-name-filter cat -- --all  # at not-bare toplevel
	Rewrite 7df30811617517bc4d5ec7c190a435667228320c (168/168)
	Ref 'refs/heads/master' was rewritten
	Ref 'refs/remotes/origin/HEAD' was rewritten
	WARNING: Ref 'refs/remotes/origin/master' is unchanged
	Ref 'refs/tags/linux-2.6.15' was rewritten
	error: Ref refs/tags/linux-2.6.15 is at \
		26a33413c95dfda6c70ca4a83da49cddb7b236b9 but expected \
		2dcaaf2decd31ac9a21d616604c0a7c1fa65d5a4
	fatal: refs/tags/linux-2.6.15: cannot lock the ref
	Could not rewrite refs/tags/linux-2.6.15
	$

 in the later case, the  info/grafts  still existed at the end,
 and `fsck --full' was happy.  (I suppose this isn't surprising
 since the filter-branch was not happy.)   moving  info/grafts
 out of the way caused the same complaints from `fsck --full'.

 the missing commits are all(? mostly?) similar to this example:

	$ git remote
	origin
	$ git remote show origin
	* remote origin
	  URL: git://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git
        [ ... ]
	$ git show dff364d8da
	commit dff364d8da15be0b856a174062fb785acb1c363e
	Merge: bc59a40... 427abfa...
	Author: Ralf Baechle <ralf@linux-mips.org>
	Date:   Sun Jun 18 03:42:49 2006 +0100
	
	    Merge tag 'v2.6.17' of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6
	
	$

 as such, is there some way of adding them back to the bare
 repository (if that even makes sense?), or whatever?  (i.e.,
 that have not been lost, is it possible to take advantage
 of that fact?)

 also (sorry!), does anyone recognise the development process
 that apparently was used?  (the one pre-existing clone has
 few-to-no clews, since it was used for some fairly trivial
 local development, not for the "merging" (if I can call it
 that) with linux-mips repository.)

cheers!
	-blf-

-- 
"How many surrealists does it take to    |  Brian Foster
 change a lightbulb?  Three.  One calms  |  somewhere in south of France
 the warthog, and two fill the bathtub   |     Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools."  |       http://www.stopesso.com