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

[Josh Triplett <josh@joshtriplett.org>]

On Sun, Nov 06, 2016 at 12:17:10PM -0800, Jacob Keller wrote:
> On Sun, Nov 6, 2016 at 9:33 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> > On Sun, Nov 06, 2016 at 09:14:56AM -0800, Junio C Hamano wrote:
> >> Josh Triplett <josh@joshtriplett.org> 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
> 
> That's still only true if the receiving end runs fsck, isn't it? I
> suppose that's a large number of receivers, and at least there are
> ways post-push to determine that objects don't make sense to that
> version of git.
> 
> I think using a new mode is the safest way, and it allows easily
> implementing RefTrees as well as other projects. Additionally, if we
> *wanted* additional "opt-in / opt-out" support we could add this by
> default to gitrefs,and they could (possibly) replace gitlinks in the
> future?

Once we have gitrefs, you have both alternatives: reachable (gitref) or
not reachable (gitlink).

However, if you want some way to mark reachable objects as not
reachable, such as for a sparse checkout, external large-object storage,
or similar, then you can use a single unified mechanism for that whether
working with gitrefs, trees, or blobs.