Re: Properties of trees referencing commit objects (mode 160000)?

From: Josh Triplett <josh@joshtriplett.org>
Date: Mar 20, 2016, 18:45 UTC
Message-ID: <20160320184524.GA16064@x>
In-Reply-To: <20160320041803.GC18312@sigill.intra.peff.net>

On Sun, Mar 20, 2016 at 12:18:04AM -0400, Jeff King wrote:

Show 11 quoted lines

> On Sat, Mar 19, 2016 at 03:13:48PM -0700, Josh Triplett wrote:
> 
> > I'm building some tools to track commit objects, and I'm thinking of
> > using submodule-style references to commit objects in tree objects (mode
> > 160000) to do so.  I'm trying to figure out some of the properties of
> > that.
> > 
> > Can a commit object referenced that way live in the same repository,
> > rather than some external repository?
> 
> Yes, it can be in the same repository, but...

Will git clone/checkout/etc handle it properly in that case, in the absence of a .gitmodules file? Or would it only work with custom tools?

Show 9 quoted lines

> > Will git treat such a reference as keeping the commit object (and
> > everything recursively referenced by it) live and reachable?  If that
> > commit object is only reachable by the tree, and not by following the
> > parents of any commit directly referenced from refs/*, will git discard
> > it as unreachable?
> 
> No, we do not follow "gitlinks" like this for reachability. Neither for
> pruning, nor for object transfer via push/fetch. So you'd need to have a
> separate reference to it (or history containing it).

Argh. If I have a pile of disconnected commits, is there anything git *would* follow to see them, other than a pile of refs?

I suppose I could artificially generate a stack of merge commits with those otherwise disconnect commits as parents, which would let me reference them all from a single ref. Still unsatisfying, though.

Also, thanks, "gitlink" was the term I was trying to think of.

(I'd also be tempted to ask whether a patch to teach git to follow gitlinks for reachability and/or object transfer would be acceptable.)