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

From: Josh Triplett <josh@joshtriplett.org>
Date: Nov 4, 2016, 21:55 UTC
Message-ID: <20161104215538.xmpth6qfuou6nde6@x>
In-Reply-To: <20161104194907.3yxu2rkayfyic4dr@sigill.intra.peff.net>

On Fri, Nov 04, 2016 at 03:49:07PM -0400, Jeff King wrote:

Show 29 quoted lines

> On Fri, Nov 04, 2016 at 12:19:55PM -0700, Jacob Keller wrote:
> 
> > I agree with your assessment here. The main difficulty in implementing
> > gitrefs is to ensure that they actually do get picked up by
> > reachability checks to prevent dropping commits. I'm not sure how easy
> > this is, but I would much rather we go this route rather than
> > continuing along with the hack. This seems like the ideal solution,
> > since it solves the entire problem and doesn't need more hacks bolted
> > on.
> 
> 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".

This seems like the critical problem, here. The parent hack I used in git-series might be a hack, but it transparently works with old servers and clients. So, for instance, I can push a git-series ref to github, with no changes required on github's part. If git added gitrefs, and I started using them in git-series, then that'd eliminate parent hack and allow many standard git tools to work naturally on git-series commits and history, but it'd also mean that people couldn't push git-series commits to any server until that server updates git.

That said, I'd *love* to have gitrefs available, for a wide variety of applications, and I can see an argument for introducing them and waiting a few years for them to become universally available, similar to the process gitlinks went through.

But I'd also love to have a backward-compatible solution.

- Josh Triplett