On Sat, Nov 5, 2016 at 1:17 PM, Christian Couder <christian.cou...@gmail.com> wrote: > On Sat, Nov 5, 2016 at 5:42 AM, Junio C Hamano <gits...@pobox.com> wrote: >> Christian Couder <christian.cou...@gmail.com> writes: >> >>> Couldn't a RefTree be used to store refs that point to the base >>> commit, >> >> I think it is the other way around. With the new "gitref" thing >> that is a pointer to an in-repository commit, RefTree can be >> naturally implemented. > > Yeah, I should have read Shawn's RefTree email thread again before > posting and especially before replying to Josh.
By the way, reading the following email by Peff where gitlink reachability was already discussed: https://public-inbox.org/git/20151217221045.ga8...@sigill.intra.peff.net/ and where Peff wrote: > Of course, the lack of reachability has advantages, too. You can > drop commits pointed to by old reflogs without rewriting the ref > history. Unfortunately you cannot expunge the reflogs at all. That's > good if you like audit trails. Bad if you are worried that your reflogs > will grow large. :) I think that we may not need "gitref" at all. We perhaps could just have more ways to configure and tweak how a repo manages commit reachability related to gitlinks. With shallow clones we already need ways to configure and tweak commit reachability anyway. And with what Peff says above it looks like we will need ways configure and tweak commit reachability with gitlink/gitref anyway. So the point of gitref compared to gitlink would be that they just have a different reachability by default. But couldn't that be replaced by a default rule saying that when a gitlink is reached "this way or that way" then the commit reachability should be enforced, and otherwise it should not be?
