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

On Fri, Nov 4, 2016 at 10:19 PM, Josh Triplett [off-list ref] wrote:

On Fri, Nov 04, 2016 at 09:47:41PM +0100, Christian Couder wrote:

quoted

On Fri, Nov 4, 2016 at 6:57 PM, Junio C Hamano [off-list ref] wrote:

quoted

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@sigill.intra.peff.net/),
the more I think about Shawn's RefTree:

https://public-inbox.org/git/CAJo=hJvnAPNAdDcAAwAvU9C4RVeQdoS3Ev9WTguHx4fD0V_nOg@mail.gmail.com/

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.

Yeah, I know them :-) and I think I have already told Stefano
Zacchiroli about this, but I am not sure anymore.
Anyway I am CC'ing him.

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. :)

Yeah, maybe :-) But the properties of the existing Git objects we
already use wouldn't change at all.

What if, rather than storing a hash reference to a reftree as a single
reference and replacing it with no history,

In what I suggest the history is kept because the new reftree has a
ref that points to the old one it is replacing.

Yeah, this reftree history maybe seen as "redundant" with the commit
history, but in my opinion this can be seen as a "feature" that will
prevent us from "mucking" too much with the commit object.

a reftree could be
referenced from a commit and have history?  (That would also allow
tagging a version of the reftree.)

I think that tags are already allowed to point to any kind of Git
object, so tagging a reftree should be allowed anyway if we add a
reftree object.