On Mon, Feb 22, 2010 at 12:59:32PM +0100, Jelmer Vernooij wrote: > > We'd like to have the extra metadata in Git so that we can push Bazaar > commits into a Git repository losslessly. If we can't do this losslessly > then the identity of the commit changes just like it does in git if you > aren't able to produce the same tree, blob and commit objects. but the problem is that you may want to add some information when you import some Git to Bazaar. For instance, Git does not record file renames explicitly and relies on content of files to detect renames automatically. So, when I use gitk, I can see that what file is renamed. If you work in Bazaar, you probably also want to see renames, but this requires that you add this information when you import commits to Bazaaar. But if you do that, the export to Git will produce a different commit just because you added this Bazaar-specific data. > > > > 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. > > No matter how many times a branch was cloned, it is exactly same branch > > (i.e. it consists of commits having exactly the same id). So, if you can > > work with the original branch, you can work with any cloned branch. So, > > I see no need to copy this data around for people who do not work with > > Bazaar directly. > The original branch is a Bazaar branch here, so that's not true. You can > only work with any cloned branch if the matching bzr/ branch is also > around. If it isn't then you won't be able to find the original commit. Obviously bzr/ branch should be around somewhere, but it does not have to be in any cloned repo. It is sufficient to have it in one place, because it refers to commit-id, which does not change when you clone it. > > hg-git already does something similar by putting a --HG-- line followed > by hg-git specific metadata in the commit message when it pushes into > Git. I'd like to find a place to put this data that's not as intruisive > for users. I still think it is wrong to hide some information in the commit object. I am not sure that the commit object is the right place to store that metadata, but hidding this information is even more problematic. Let's suppose that someone cherry-pick your Bazaar originated commit. Now when you try to synchronize with Bazaar, your synchronizer will see that it has some Bazaar revision ID and branch name, but, in fact, it is new commit on a completely different branch... 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