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

On Fri, Nov 04, 2016 at 04:34:34PM -0700, Jacob Keller wrote:

quoted

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.

Is it possible currently for a protocol extension to result in "oh the
server doesn't support this so I'm going to stop pushing"?

Yes, it would be easy for the client to abort if the server fails to
advertise a particular extension.

What I would worry about more is that "somehow" an older client gets
hold of history with a gitref, and then pushes it. It would be nice if
even an old server said "nope, I don't understand this and I won't take
it" rather than propagating the data to a server that will throw it
away.

Right. I'm assuming tree objects don't get checked for invalid mode
already? If they do, we could just change the mode to something
unsupported currently. But... that seems like it might not be the case
because it requires checking every tree object coming in?

I'm not familiar with what sort of checking already exists... Thoughts?

If the server sets receive.fsckObjects, then fsck_tree() runs and will
reject any non-standard mode. That option is not the default, though
some big hosters set it (GitHub does, but I am actually not that worried
about GitHub; if gitrefs support materialized I would probably ship it
there fairly promptly).

-Peff