On Thu, Jul 14, 2011 at 01:26:32PM -0700, Junio C Hamano wrote:
> Jeff King <peff@xxxxxxxx> writes:
>
> > There's also one other issue with generation numbers. How do you handle
> > grafts and object-replacement refs? If you graft history, your embedded
> > generation numbers will all be junk, and you can't trust them.
>
> By the way, I doubt your "invalidate and recompute generation cache when
> replacement changes" would really work when we consider object transfer
> (which is the whole point of deprecating graft with object replacement
> mechanism). For the purpose of connectivity check during object transfer,
> we deliberately _ignore_ the object replacements, so you would at least
> want to have an ability to show the generation number according to the
> "true" history recorded in commits (which can come from Linus's in-commit
> generation number once everybody migrates) and the generation number that
> takes grafts and replacements into account (for which we cannot depend on
> in-commit record).
It should actually work in that scenario, at least with replace refs,
but the performance is suboptimal. The copy of git doing the object
transfer will turn off read_replace_refs, our validity token will
not match, we will see that our cache is no longer valid, and
regenerate it. Another run with replace-refs turned on will do the same
thing in reverse. Even two programs running simultaneously will still be
correct, because the cache is replaced atomically.
However, there are two issues:
1. I don't think grafts have a "respect grafts" flag in the same way;
I haven't looked at how the packing code decides not to respect
them, but the "stir graft info into the checksum" data should use
the same check.
2. If you do a lot of object transfer, you will ping-pong back and
forth between cache versions, which is inefficient. It would
probably be better to store the cache that is valid under condition
$SHA1 as:
.git/cache/generations/$SHA1
In most cases, you would have a single file (i.e., you are not
using replace refs at all). But if you did, then you keep two
separate caches, one for the view from replace-refs, and one for
the standard view.
If we ignore replace refs and grafts, as Linus suggested, and always
store the true generation number, then we could generate it at pack time
(and even put it in the pack index if we want to deal with a version
bump there).
-Peff
--
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