"Eric S. Raymond" <e...@thyrsus.com> writes:
> Felipe Contreras <felipe.contre...@gmail.com>:
>> On Thu, Nov 29, 2012 at 8:11 AM, Junio C Hamano <gits...@pobox.com> wrote:
>> > Steven Michalske <smichal...@gmail.com> writes:
>> >> Would having arbitrary key value pairs be useful in the git data
>> >> model?
>> > My answer to the question is that it is harmful to the data model,
>> > but the benefit of going against the data model _may_ outweigh the
>> > downside. It is all relative.
> My use case for a capability like this is one of the more common ones.
> I want to be able to store a fossil commit-ID inherited from another
> VCS outside the commit comment.
That is exactly why I said it is all relative. If it helps your
application, you can weigh the pros-and-cons yourself and choose to
throw "junk" extended header fields in the commit objects you
create, using hash-object (or commit-tree). You can read it out
using cat-file and do whatever you want to do with it, and modern
Git (v1.5.0 was from early 2007) and tools that are designed to work
with Git know to ignore such "junk" field.
> The absence of a key/value store forces me into some annoying
Do not do annoying kludge, then. Come up with a method to encode
your list of (key,value) tuples into a single string, throw a
custom extra header after all the standard header fields in, perhaps
author A U Thor <aut...@example.xz> 1355999999 +0900
committer C O Mitter <commit...@example.xz> 1355999999 +0900
My first commit
Signed-off-by: A U Thor <aut...@example.xz>
Signed-off-by: C O Mitter <commit...@example.xz>
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html