Re: Bug: segfault during git-prune

[Andy Parkins <andyparkins@gmail.com>]

On Thursday 2007, June 28, Linus Torvalds wrote:
> On Thu, 28 Jun 2007, Andy Parkins wrote:
> > I ran git-prune on a repository and got this:
> >
> > $ git-prune
> > error: Object 228f8065b930120e35fc0c154c237487ab02d64a is a blob, not a
> > commit Segmentation fault (core dumped)
>
> Do you have subprojects in that git repo?

Yes.  I'm also doing something that is possibly very naughty; and I'm sure 
you're going to say "what on earth do you expect when you've done _that_"

The subproject is the same repository...  It's a git conversion of the 
ffmpeg history; ffmpeg uses svn:externals for the libswscale directory; so 
I set that as an independent branch in the same repository, fetched with 
git-svn as well.  Then I cloned the repository into a subdirectory of 
itself.

 $ git clone -n . libswscale

Then I went into libswscale/.git/ and ln -s objects, refs, info, and logs.  
In fact the only thing that isn't shared is HEAD.

Then I changed into libswscale and checked out the libswscale branch.  Back 
in the ffmpeg repository I git-add the libswscale directory and everything 
seems to be working wonderfully.

> And the only case I know of that does that is using an old git binary, or
> a unconverted git code-path program, on a repository with subprojects
> when the code-path doesn't understand that a tree can contain pointers to
> commits.

Sounds like the last one to me.  I tend to be only a few days behind 
upstream git.

> Yeah, git-fsck knows about subprojects. I bet git-prune just doesn't.
>
> And indeed.. Here's a patch for it, but the fact is, you really should
> *not* prune that repository, because you'll prune away all the subproject
> data, which you seem to have in the same repo!

Correct; you did well figuring that out from the meagre information I gave.

I had hoped that git-prune wouldn't be a risk because I have:

 * -- * -- * -- * -- * (ffmpeg-svn)

      * -- * -- * -- * (libswscale-svn)

Then I forked master from ffmpeg-svn and added the libswscale-svn branch as 
a submodule as described above.  Now, because the submodule always refers 
to commits that are ancestors of libswscale-svn, they'll never be seen as 
dangling and pruned?

> (General rule: never *ever* prune a shared object repository!)

Even when I'm sure that every object of interest is behind a head ref?

> ---
>  reachable.c |   11 +++++++++++
>  1 files changed, 11 insertions(+), 0 deletions(-)

The repository in question is on my work computer, so I won't be able to try 
this patch until Monday.  I'll report back then.


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com