Linus Torvalds wrote:
On Wed, 14 May 2008, Nicolas Pitre wrote:
On Wed, 14 May 2008, Linus Torvalds wrote:
Of course, the more aggressively we prune, the more we end up having to
depend on the fact that a commit that is in a pack that is marked "keep"
must *always* have everything that leads to it in that pack or others also
marked "keep". We effectively have that already (because we've always
pruned away the commits early), but it's a thing to keep in mind whenever
we prune even more aggressively.
I wonder if this is a good thing. Such a rule would effectively put
restrictions on how objects like big blobs could be distributed amongst
many .keep packs. I just wish we're not painting ourselves in a corner.
You can distribute big objects arbitrarily among many .keep packs, but
what you can *NOT* do (and which has _always_ been a bug to do) is to have
a *.keep pack that refers to objects that are not in a .keep pack!
So keep<->keep you can do anything you want, and distribute objects any
way.
But a keep pack must only refer to objects in itself or in other keep
packs.
Because otherwise, if we ever hit an object in a keep pack, we'll stop
even looking further when we use --unpacked. And that has always been true
(admittedly only for "commit" objects, but those are the ones that most
commonly refer to other objects, so ..)
Sounds like git-fsck needs to start checking for this.
--
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
