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

On Sat, Nov 5, 2016 at 1:17 PM, Christian Couder
[off-list ref] wrote:

On Sat, Nov 5, 2016 at 5:42 AM, Junio C Hamano [off-list ref] wrote:

quoted

Christian Couder [off-list ref] writes:

quoted

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.GA8150@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?