On Fri, Nov 04, 2016 at 03:49:07PM -0400, Jeff King wrote: > 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
