On Sun, Nov 06, 2016 at 09:14:56AM -0800, Junio C Hamano wrote: > Josh Triplett <josh@xxxxxxxxxxxxxxxx> writes: > > We could, but if we (or one of the many third-party git implementations) > > miss a case, gitlinks+reachability may appear to work in many cases with > > dataloss afterward, while gitrefs will fail early and not appear > > functional. > > I wonder what happens if we do not introduce the "gitref" but > instead change the behaviour of "gitlink" to imply an optional > reachability. That is, when enumerating what is reachable in your > repository, if you see a gitlink and if you notice that you locally > have the target of that gitlink, you follow, but if you know you > lack it, you do not error out. This may be making things too > complex to feasibily implement by simplify them ;-) and I see a few > immediate fallout that needs to be thought through (i.e. downsides) > and a few upsides, too. I am feeling feverish and not thinking > straight, so I won't try to weigh pros-and-cons. > > This would definitely need protocol extension when transferring > objects across repositories. It'd also need a repository format extension locally. Otherwise, if you ever touched that repository with an older git (or a tool built on an older libgit2 or JGit or other library), you could lose data. It does seem conceptually appealing, though. In an ideal world, the original version of gitlink would have had opt-out reachability (and .gitmodules with an external repository reference could count as opting out). But I can't think of any case where it's OK for a git implementation to not know about this reachability extension and still operate on the gitlink. And given that, it might as well use a new object type that the old version definitely won't think it understands. - Josh Triplett