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
--
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
