On Mon, 2010-02-22 at 17:20 +0300, Dmitry Potapov wrote: > On Mon, Feb 22, 2010 at 02:44:49PM +0100, Jelmer Vernooij wrote: > > On Mon, 2010-02-22 at 16:08 +0300, Dmitry Potapov wrote: > > > 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... > > I don't see how the fact that the bzr-git/hg-git data is being hidden is > > the problem in the scenario you mention. > Because you can easily remove that information manually when you cherry-pick > some commit. It is more difficult to do when it is hidden. My point is that if you don't make it part of the user-visible commit message there is no need to remove it at all, it'll just disappear by itself. > > It'd be nice if this sort of information was discarded by "git rebase", > > but that's another good reason to treat it in a different way from the > > commit message instead. > Well, I do not see any other place in the commit object aside the commit > message where you can easily put information, and I do not think it is a > good idea for "git rebase" to edit the commit message automatically. > Maybe, you should look at git-notes. (I don't know enough about them to > tell whether they are suitable or not). Some other people have suggested putting e.g. a RFC822-style header in the commit message field and using the headers in that to allow custom revision properties, only displaying the body in "git log", "git show" etc. What do you think about that? Cheers, Jelmer
Attachment:
signature.asc
Description: This is a digitally signed message part