Re: Bug: segfault during git-prune
- From
- Andy Parkins <andyparkins@gmail.com>
- Date
- Jun 28, 2007, 22:21 UTC
- Message-ID
- <200706282321.44244.andyparkins@gmail.com>
- In-Reply-To
- <alpine.LFD.0.98.0706280844460.8675@woody.linux-foundation.org>
On Thursday 2007, June 28, Linus Torvalds wrote:
Show 8 quoted lines
> 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.
Show 5 quoted lines
> 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