Re: Storing (hidden) per-commit metadata

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, Feb 20, 2010 at 12:41 PM, Ben Gamari <bgamari@xxxxxxxxx> wrote:
> Excerpts from Jelmer Vernooij's message of Fri Feb 19 12:11:25 -0500 2010:
>> 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.
>>
> Are you sure you want to hide this? I believe git-svn puts this
> information in its commit messages (although I don't know whether it's
> stored elsewhere as well).

Note that git-svn doesn't store *all* the stuff from svn in the git
repository.  So you couldn't, for example, regenerate an svn repo
identical to the original from its git-svn clone.  This limitation is
rarely noticed since the stuff git-svn doesn't store is stuff that git
mostly does differently/automatically/etc.  But that's why git-svn can
get away with cluttering your commit messages with "only" one line of
git-svn cruft each.

However, this does bring up the question: how important is it *really*
to be able to "round trip" from bzr to git and back without losing
information?  Maybe you only need to store enough information to pull
from bzr and then push back your commits.

As for git-notes, they sound like they would be useful for this sort
of thing.  I haven't tried them yet, but my understanding is that
notes anywhere other than the "default" notes ref are not shown in
commit messages, so you can use them for whatever you want.

Have fun,

Avery
--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]