git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
BFBrian Foster <brian.foster@innova-card.com>
Date
Apr 17, 2008, 14:53 UTC
Message-ID
<a537dd660804170753i4dcfd189m45a9581294ce5091@mail.gmail.com>
In-Reply-To
<200804171643.15504.brian.foster@innova-card.com>
Hannes suggested:
Show 10 quoted lines
> 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
Previous: Dmitry PotapovNext: Brandon Casey
Message 5 of 9 in “Re: fsck --full is Ok, but clones are not, "missing commits"?!”
  1. Brian FosterApr 16, 2008
  2. Johannes SixtApr 16, 2008
  3. Brandon CaseyApr 16, 2008
  4. Dmitry PotapovApr 16, 2008
  5. Brian FosterApr 17, 2008
  6. Brandon CaseyApr 17, 2008
  7. Brian FosterApr 18, 2008
  8. Johannes SixtApr 18, 2008
  9. Brian FosterApr 18, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.