git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Christian Couder <christian.couder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git <git@vger.kernel.org>,
	"Shawn O. Pierce" <spearce@spearce.org>,
	Jeff King <peff@peff.net>
Subject: Re: Regarding "git log" on "git series" metadata
Date: Fri, 4 Nov 2016 15:19:59 -0600	[thread overview]
Message-ID: <20161104211959.3532uiud27nhumt7@x> (raw)
In-Reply-To: <CAP8UFD2+A0MUKazAfSwCvv61TJRPuoOzH5EkqcrBOUi4TcuoDw@mail.gmail.com>

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@pobox.com> 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@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.

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

  reply	other threads:[~2016-11-04 21:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-04 17:57 Regarding "git log" on "git series" metadata Junio C Hamano
2016-11-04 19:19 ` Jacob Keller
2016-11-04 19:49   ` Jeff King
2016-11-04 21:55     ` Josh Triplett
2016-11-04 23:37       ` Jacob Keller
2016-11-04 23:46         ` Josh Triplett
2016-11-04 23:34     ` Jacob Keller
2016-11-05  1:48       ` Jeff King
2016-11-05  3:55         ` Josh Triplett
2016-11-05  4:41           ` Jeff King
2016-11-05  4:41     ` Junio C Hamano
2016-11-05  4:44       ` Jeff King
2016-11-05  5:00       ` Junio C Hamano
2016-11-04 20:47 ` Christian Couder
2016-11-04 21:19   ` Josh Triplett [this message]
2016-11-04 23:04     ` Christian Couder
2016-11-13 17:50       ` Stefano Zacchiroli
2016-11-05 21:56     ` Christian Couder
2016-11-05  4:42   ` Junio C Hamano
2016-11-05 12:17     ` Christian Couder
2016-11-05 12:45       ` Christian Couder
2016-11-05 15:18         ` Josh Triplett
2016-11-05 20:21           ` Christian Couder
2016-11-05 20:25             ` Josh Triplett
2016-11-06  4:50               ` Jacob Keller
2016-11-06 16:34                 ` Josh Triplett
2016-11-06 17:14                   ` Junio C Hamano
2016-11-06 17:33                     ` Josh Triplett
2016-11-06 20:17                       ` Jacob Keller
2016-11-07  1:18                         ` Josh Triplett
2016-11-07  5:35                           ` Jacob Keller
2016-11-07  9:42                           ` Duy Nguyen
2016-11-07 16:11                             ` Josh Triplett
2016-11-09 22:57                       ` Junio C Hamano
2016-11-04 21:06 ` Josh Triplett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161104211959.3532uiud27nhumt7@x \
    --to=josh@joshtriplett.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).