Extra metadata in the commit?

Extra metadata in the commit?

[Scott Chacon]

Hey all,

I'm working on a hg<->git bidirectional tool using Git as the
communication protocol, so there is a bunch of Hg metadata that I need
to keep in Git to ensure I can convert commits created in Hg back into
the exact same objects after they upload to the Git db and then come
back down.  This means storing explicit rename info, branch names, etc
somewhere without messing up Git clients that want to work on the same
repo.  So, I can keep this data in the commit message, but I thought
it would be cleaner to keep it as extra fields in the commit object
before the "\n\n" separator.  Before I go too far down this road, is
there anything horrible that might happen in any of the core Git tools
if extra data is there?

Thanks,
Scott

Re: Extra metadata in the commit?

[Junio C Hamano]

Scott Chacon <schacon@gmail.com> writes:

> I'm working on a hg<->git bidirectional tool using Git as the
> communication protocol, so there is a bunch of Hg metadata that I need
> to keep in Git to ensure I can convert commits created in Hg back into
> the exact same objects after they upload to the Git db and then come
> back down.  This means storing explicit rename info, branch names, etc
> somewhere without messing up Git clients that want to work on the same
> repo.  So, I can keep this data in the commit message, but I thought
> it would be cleaner to keep it as extra fields in the commit object
> before the "\n\n" separator.  Before I go too far down this road, is
> there anything horrible that might happen in any of the core Git tools
> if extra data is there?

Not that I know of but it is highly unlikely that such a patch will be
accepted, given the history of discussion around that area.

Re: Extra metadata in the commit?

[Johannes Schindelin]

Hi,

On Fri, 24 Apr 2009, Scott Chacon wrote:

> I'm working on a hg<->git bidirectional tool using Git as the 
> communication protocol, so there is a bunch of Hg metadata that I need 
> to keep in Git to ensure I can convert commits created in Hg back into 
> the exact same objects after they upload to the Git db and then come 
> back down.  This means storing explicit rename info, branch names, etc 
> somewhere without messing up Git clients that want to work on the same 
> repo.  So, I can keep this data in the commit message, but I thought it 
> would be cleaner to keep it as extra fields in the commit object before 
> the "\n\n" separator.

I'd suggest keeping it in the commit body, for better visibility and 
easier handling by tools.

Ciao,
Dscho

Re: Extra metadata in the commit?

[Alex Riesen]

2009/4/25 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Fri, 24 Apr 2009, Scott Chacon wrote:
>
>> I'm working on a hg<->git bidirectional tool using Git as the
>> communication protocol, so there is a bunch of Hg metadata that I need
>> to keep in Git to ensure I can convert commits created in Hg back into
>> the exact same objects after they upload to the Git db and then come
>> back down.  This means storing explicit rename info, branch names, etc
>> somewhere without messing up Git clients that want to work on the same
>> repo.  So, I can keep this data in the commit message, but I thought it
>> would be cleaner to keep it as extra fields in the commit object before
>> the "\n\n" separator.
>
> I'd suggest keeping it in the commit body, for better visibility and
> easier handling by tools.
>

BTW, by the same convention we treat the very first line of a commit
message specially, we can say that the last line, if non-empty
(IOW, does not end with \n), is treated specially by UI tools
(grayed out, for example):

  Subject\n
  \n
  Body\n
  \n
  something:very:special

Re: Extra metadata in the commit?

[Johan Herland]

On Saturday 25 April 2009, Johannes Schindelin wrote:
> On Fri, 24 Apr 2009, Scott Chacon wrote:
> > So, I can keep this data in the commit message, but I thought it
> > would be cleaner to keep it as extra fields in the commit object before
> > the "\n\n" separator.
>
> I'd suggest keeping it in the commit body, for better visibility and
> easier handling by tools.

Or even better: Keep it in separate commit notes (provided you can wait for 
the js/notes topic in pu to make it into a release). If you add the notes 
with GIT_NOTES_REF=refs/notes/hg_metadata, you will also keep them nicely 
out of the way of everybody else.

(I'm using this approach when building a bidirectional CVS <-> Git helper on 
top of Barkalow's foreign-scm topic).


Have fun! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net