On Fri, Nov 04, 2016 at 04:37:34PM -0700, Jacob Keller wrote: > On Fri, Nov 4, 2016 at 2:55 PM, Josh Triplett <j...@joshtriplett.org> wrote: > > 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 > > I think that you won't really find a backwards compatible solution > other than something like automatically generating refs for each point > of history. I know that gerrit does something like this by storing > each version in "refs/changes/id/version" or something along those > lines. I think this might actually be cleaner than your parent links > hack, and could be used as a fallback for when gitrefs don't work, > though you'd have to code exactly how to tell what to push to a > repository when pushing a series?
I'm not sure what the advantage of that would be, and it would mean that if you ever have one branch without pushing the other(s), you'd get severe time-delated breakage due to pruning. (And if you pushed the series without the other ref(s), its history would look right but then you couldn't access the underlying versions of the patch series.) One of my design goals was to *not* need a special "git series push" or "git series pull"; you should just be able to use git push and git pull, and you can set up normal refspecs. That said, I could fairly easily generate the existing format with artificial parent refs for backward compatibility, and provide a way to use the new gitref-based storage format if you know that all your servers and clients can handle it. I'm also open to other suggestions for how to make such a transition while still working with every git server and git client that exists today.
