Re: Regarding "git log" on "git series" metadata

> I think the main complication is that the reachability rules are used
> during object transfer. So you'd probably want to introduce some
> protocol extension to say "I understand gitrefs", so that when one side
> says "I have sha1 X and its reachable objects", we know whether they are
> including gitrefs there. And likewise receivers with
> transfer.fsckObjects may complain about the new gitref tree mode
> (fortunately a new object type shouldn't be needed).
>
> You might also want fallback rules for storing gitrefs on "old" servers
> (e.g., backfilling gitrefs you need if the server didn't them in the
> initial fetch). But I guess storing any gitrefs on such a server is
> inherently dangerous, because the server might prune them at any time.
>

> So perhaps a related question is: how can gitrefs be designed such that
> existing servers reject them (rather than accepting the push and then
> later throwing away half the data). It would be easy to notice in the
> client during a push that we are sending gitrefs to a server which does
> not claim that capability. But it seems more robust if it is the server
> who decides "I will not accept these bogus objects".
>
> I haven't thought all that hard about this. That's just my initial
> thoughts on what sound hard. Tweaking the reachability code doesn't seem
> all that bad; we already know all of the spots that care about
> S_ISGITLINK(). It may even be that some of those spots work out of the
> box (because gitlinks are usually about telling the graph-walking code
> that we _don't_ care about reachability; we do by default for trees and
> blobs).

>
> I'd be surprised if all such sites work out of the box, though. Even if
> they see "ah, sha1 X is referenced by tree Y and isn't a gitlink, and
> therefore should be reachable", they need to also note that "X" is a
> commit and recursively walk its objects.
>