Re: Storing (hidden) per-commit metadata

["\"Alejandro R. Sedeño\"" <asedeno@MIT.EDU>]

On 02/19/2010 12:11 PM, Jelmer Vernooij wrote:
> To allow round-tripping pushes from Bazaar into Git, I'm looking for a
> good place to store Bazaar semantics that can not be represented in Git
> at the moment. This data should ideally be hidden from the user as much
> as possible; it would e.g. contain mappings from git hashes to Bazaar
> ids.

I've been having similar thoughts for git-svn, since I am working with a
very large svn repository that uses svn:keywords and svn:externals in a
few places. I've written some scripts to parse the git-svn
unhandled.log, but that does not propagate to other git clones of the
repo, and rebuilding the log is about as expensive as cloning the svn
repo again. Also, querying for externals is slow, presumably because
git-svn needs to talk to svn to fetch them.

So far, I have been leaning towards having an optional tree associated
with commits, in which metadata could be stored. This metadata tree
would be propagated by git clone, used by remote helper scripts, and be
quite ignorable if unneeded. The metadata tree would use sub-trees for
namespaces. For instance, a sub-tree called git-svn would contain the
revision map, externals, ignores, properties, etc.

This isn't fully thought out yet, and I'm not even sure if it would
work, or be backwards-compatible. However, since the topic came up, I
figured I should mention what I had so far.

Preemptive: No, I don't like svn:keywords, but I can't just ignore them.

Preemptive: Yes, I considered notes in a different GIT_NOTES_REF, but I
feel those are too loosely coupled to the commits. I could be wrong, and
have not completely dismissed them yet.

-Alejandro