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