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!
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.
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html