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

From: Jeff King <peff@peff.net>
Date: Nov 5, 2016, 01:48 UTC
Message-ID: <20161105014817.vm4ush2wfbblzsc7@sigill.intra.peff.net>
In-Reply-To: <CA+P7+xpwUZscpgzLJYf5vkKKsT6SFkC3TrsyBJXJjGo9cF94nQ@mail.gmail.com>

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

Show 7 quoted lines

> > 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.

Show 6 quoted lines

> 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