On Fri, Nov 4, 2016 at 10:19 PM, Josh Triplett <josh@xxxxxxxxxxxxxxxx> wrote: > On Fri, Nov 04, 2016 at 09:47:41PM +0100, Christian Couder wrote: >> On Fri, Nov 4, 2016 at 6:57 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> > >> > Imagine we invent a new tree entry type, "gitref", that is similar >> > to "gitlink" in that it can record a commit object name in a tree, >> > but unlike "gitlink" it does imply reachability. And you do not add >> > phony parents to your commit object. A tree that has "gitref"s in >> > it is about annotating the commits in the same repository (e.g. the >> > tree references two commits, "base" and "tip", to point into a slice >> > of the main history). And it is perfectly sensible for such a >> > pointer to imply reachability---after all it serves different >> > purposes from "gitlink". >> >> The more I think about this (and also about how to limit ref >> advertisements as recently discussed in >> https://public-inbox.org/git/20161024132932.i42rqn2vlpocqmkq@xxxxxxxxxxxxxxxxxxxxx/), >> the more I think about Shawn's RefTree: >> >> https://public-inbox.org/git/CAJo=hJvnAPNAdDcAAwAvU9C4RVeQdoS3Ev9WTguHx4fD0V_nOg@xxxxxxxxxxxxxx/ Just to make things clear, after reading the above link that I posted :-) ... >> Couldn't a RefTree be used to store refs that point to the base >> commit, the tip commit and the blob that contains the cover letter, >> and maybe also a ref pointing to the RefTree of the previous version >> of the series? > > That's really interesting! The Software Heritage project is working on > something similar, because they want to store all the refs as part of > their data model as well. I'll point them to the reftree work. > > If upstream git supported RefTree, I could potentially use that for > git-series. However, I do want a commit message and history for the > series itself, and using refs in the reftree to refer to the parents > seems like abusing reftree to recreate commits, in a reversal of the > hack of using commit parents as a reftree. :) > > What if, rather than storing a hash reference to a reftree as a single > reference and replacing it with no history, a reftree could be > referenced from a commit and have history? (That would also allow > tagging a version of the reftree.) ... I think that indeed that's what Shawn's reftree proposal is about, so I agree that it makes sense. We just need to find a good way to specify object reachability.