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
May 5, 2008, 14:44 UTC
Message-ID
<a537dd660805050744h7602e553u21c70168a621fe76@mail.gmail.com>
In-Reply-To
<200805051608.55200.brian.foster@innova-card.com>
On Monday 05 May 2008 06:25:46 Bryan Donlan asked:
Show 10 quoted lines
> On Wed, Apr 16, 2008 at 08:37:39AM +0200, Brian Foster wrote:
> >  I've recently inherited a bare git repository,
> >  which, as far as I can tell (I'm something of
> >  a newbie with git), seems Ok: `git fsck --full'
> >  does not report any problems.    however, any
> >  clones I make from it are not Ok [ ... ]
>
> Is there an info/grafts file?  If the repository doesn't have sensitive
> information in it, it would probably be helpful to tarball it up and
> upload it somewhere, so we can take a look at things directly.
Bryan,
 Yes, the proximate cause was an info/grafts.
 The repository in question is for a port of Linux
 to the MIPS-based "secure" SoC made by the company
 I work for.  The repository was very simple:
    master:  o---o---o---o---o--...--o  HEAD
 where each `o' was a tagged version/release of the
 Linux port.  Since the chip is MIPS-based, some `o'
 were the result of merges with mips-linux baseline.
 Hence, the real history was, broadly:
       master:          o--o--o--o--o--o-----o--...--o
                       /           /  /     /
   mips-linux:  o--o--o----o------o--o--o--o--...--o
 where, of course, `mips-linux' has its own rather
 complicated history (not shown).  As implied by
 the diagrams above, grafts were used to "suppress"
 mips-linux and its history.  (Since the situation
 really was as trivial as drawn above, it was easy
 to recover:  Add the pack representing mips-linux,
 remove grafts, and ensure all the tags exist.)
 What I don't know is the root-cause, that is, WHY
 this was done.  It wasn't a disc-space issue, and
 I've no evidence it was a network-bandwidth issue,
 but there is some anecdotal evidence it was some
 sort of a CPU-cycles issue, albeit just what the
 performance hit was is unknown.
 Another possibility is the repository started life
 as CVS (ugh!) before being migrated to git.  It's
 my (vague) understanding grafts is somehow useful
 as a (temporary?) aid when doing a CVS-->git move;
 and I speculate it was found so useful/simple the
 practice simply continued.
 The developers tended to work from tarballs (not
 clones), so the cloning problem was either unknown,
 not a concern, or mis-understood.
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: Bryan DonlanNext: Johannes Sixt
Message 4 of 7 in “fsck --full is Ok, but clones are not, "missing commits"?!”
  1. Brian FosterApr 16, 2008
  2. David KastrupApr 16, 2008
  3. Bryan DonlanMay 5, 2008
  4. Brian FosterMay 5, 2008
  5. Johannes SixtMay 5, 2008
  6. Brian FosterMay 6, 2008
  7. Johannes SixtMay 6, 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.