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

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

Hannes suggested:
> Brian Foster schrieb:
> >[ ... ] is there some way of adding [ the missing commits,
> >  all of which seem to be from linux-mips, ] back to the bare
> >  repository (if that even makes sense?), or whatever?  (i.e.,
> >  [ they ] have not been lost, [ so ] is it possible to take
> >  advantage of that fact?)   [ ... ]
>
> In this case you might be able to salvage missing objects by cloning
> linux-mips. Just copy the objects/pack/* from that clone into your
> objects/pack, remove info/grafts, and maybe things "just work"?

Hannes et al.,

 thanks for the suggestion.  bingo!  that basically worked.
 after copying linux-mips  objects/pack/*  into my goofy
 bare repository,  `fsck --full'  (after moving  grafts
 out of the way) found different issues.  it complained
 about a zillion dangling tags (yawn), plus a handful of
 dangling commits.

 the dangling tags were the linux-mips  refs/tags/*.  copying
 them into my repository's  ref/tags  fixed that.  (there were
 no name collisions with the existing tags, so this was easy.)

 the dangling commits were linux-mips  refs/remotes/origin/*,
 and again could be safely/easily copied into my repository.

 `fsck --full' is now 100% happy.  (yea!)

 the obvious missing thing (which I _think_ is easy to fix?)
 is the remote URL &tc is not in my now-not-so-goofy bare
 repository.  hence `branch -r' shows  origin/*  branches,
 but (I speculate) a `pull' (e.g.) will be confused.

 at this point in time I've not done any extensive testing
 of the seemingly-fixed repository, but things are looking
 much better.

 before trying the copying suggestion, I played some
 more with `filter-branch'.  I had no success at all.
 as one example, with `--branches' instead of `--all'
 (one of Brandon's suggestions) produced:

	$ git filter-branch --tag-name-filter cat -- --branches
	Which ref do you want to rewrite?
	$

 also, Dmitry's suggestion of cloning (with grafts still
 in-place) after `filter-branch ... --all' accomplished
 nothing obvious:  `fsck --full' of the new clone was
 still unhappy (same set of complaints).

 whilst I'm still trying to understand the rationale for
 why things were set-up(? left-in?) this weird state,
 browsing the history gives some vague hints.  however,
 the intended usage model remains opaque.

 and that will soon be my next problem:  what's a better
 (best?) usage model (for this project)?  I need to do
 some more reading here ....  ;-\

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