On Sun, Mar 20, 2016 at 12:18:04AM -0400, Jeff King wrote: > 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? > > 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.) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html