Re: Storing (hidden) per-commit metadata

From: Jelmer Vernooij <jelmer@samba.org>
Date: Feb 21, 2010, 12:17 UTC
Message-ID: <1266754646.12035.23.camel@ganieda>
In-Reply-To: <20100221063433.GA2840@coredump.intra.peff.net>

On Sun, 2010-02-21 at 01:34 -0500, Jeff King wrote:

Show 13 quoted lines

> On Sat, Feb 20, 2010 at 01:57:31PM -0500, Avery Pennarun wrote:
> > As for git-notes, they sound like they would be useful for this sort
> > of thing.  I haven't tried them yet, but my understanding is that
> > notes anywhere other than the "default" notes ref are not shown in
> > commit messages, so you can use them for whatever you want.
> I would want to hear more about the actual data being stored. The
> strength of notes is that you can _change_ them after the commit has
> been created. And the price you pay is that they are more annoying to
> move around, because they are in a totally different ref.
> 
> If this is data that is being generated at the time the commit is
> created and then set in stone, then it probably should be part of the
> commit object.

This data is supposed to be set in stone, since Bazaar revisions are intended to be immutable, like Git commits are.

For each file we would need to store:

 * the Bazaar revision id
 * any Bazaar revision properties. This is typically a list of URLs of
bugs that were fixed, name of the branch the commit was on, any
additional parents, or anything arbitrary set by plugins (e.g. the
rebase plugin sets 'rebase-of' to the id of the original revision)
 * For each file that was added or moved around in the revision, a path
to fileid mapping
 * Optionally, a list of ghost parent ids and "unusual" revisions for
each file but these should be rare.

This is at least a couple of lines of data and in some cases a lot more. I would rather avoid confronting git users who don't care about Bazaar with it.

> If the only problem is that the data is ugly in "git show", then perhaps
> we need a "suppress these pseudo-headers" feature for showing logs. It
> keeps them easily available for inspection or for --grep, but most of
> the time you would not see them.

That seems like a sensible thing to do, and would work well for me.

Cheers,

Jelmer