On Fri, Nov 04, 2016 at 04:34:34PM -0700, Jacob Keller wrote: > > 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