Re: Storing (hidden) per-commit metadata

From: Jelmer Vernooij <jelmer@samba.org>
Date: Feb 22, 2010, 09:56 UTC
Message-ID: <1266832607.31769.37.camel@ganieda>
In-Reply-To: <20100222051748.GB10191@dpotapov.dyndns.org>

On Mon, 2010-02-22 at 08:17 +0300, Dmitry Potapov wrote:

Show 23 quoted lines

> On Sun, Feb 21, 2010 at 01:17:26PM +0100, Jelmer Vernooij wrote:
> > 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.
> The problem with storying this meta data in the commit object is that
> any newly created commits in Git will not have this information, and you
> probably have to add it later when you export these commits to Bazaar,
> which means that the history in Git should be re-written, and Git users
> will have to rebase their branches from one commit to another that are
> identical except this Bazaar-specific information, which you try to hide
> from them. So much for don't care about Bazaar!

Show 26 quoted lines

> In other words, no matter what git-log displays, as long as you put this
> meta data wherever it changes commit-id, it is visible to Git users, and
> trying to hide this fact is utterly stupid.
> 
> There are many ways to store Bazaar data in Git without confronting git
> users who don't care about Bazaar with it. For instance, you can create
> a separate branch that will hold this meta data.
> 
>    master      bzr/master
> 
>       /---------o
>      o          |
>      |          |
>      |/---------o
>      o          |
>      |          |
> 
> Commits on bzr/master are fast-forward merges that have the same tree-id
> as corresponding commits on master, but the commit message contains
> Bazaar specific information. So, if someone does not care about Bazaar,
> this is a throw away branch for him. Also, there is no problem to add
> Bazaar specific information to any git commit later when it is pushed
> to Bazaar. The only problem is if you try to rebase commits that were
> pushed to Bazaar, but AFAIK Bazaar does not support overwriting history,
> so you cannot expect anything good of this attempt anyway. The published
> history should not rebased.

There is no need for that data to be added later for revisions that did not originate from Bazaar. All of the metadata that has to be stored will be known at the time the commit is created. Those commits that were made in Git later will not have any metadata that can not be represented in Git (they were made with Git, after all). There is no need for rebasing/overwriting history for existing revisions to enable access by Bazaar.

Having a bzr/master ref means that the extra metadata will not always be copied around (unless git is patched), so if I push my work from Bazaar into Git, somebody works on it in Git and pushes a derived branch and then somebody else clones that derived Git branch into Bazaar again, I will not be able to communicate with that person's branch.

Cheers,

Jelmer