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

On Monday 05 May 2008 06:25:46 Bryan Donlan asked:

On Wed, Apr 16, 2008 at 08:37:39AM +0200, Brian Foster wrote:

quoted

 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

Brian Foster schrieb:

 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.

How about this theory:

What happens if you fire up gitk as simple as

   $ gitk

in the history if no grafts are present? Some months ago this took ages to
complete, and even today you get a *huge* list of commits in a *short*
window; hence, the scrollbar thumb is tiny, and if you succeed to get hold
of it without a magnifying glass, it scrolls way more than a page of
commits if you move it by only one pixel.

No wonder that $user wants to have a shorter history. So $user, being
smart, truncates the history at a suitable point with a graft.

-- Hannes