Re: extra headers in commit objects

[demerphq <demerphq@gmail.com>]

On 3 February 2010 19:15, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Wed, 3 Feb 2010, Shawn O. Pearce wrote:
>
>> Am I correct that core C developers are still under the opinion
>> that extra headers in a commit object aren't encouraged?
>
> I would say so.
>
> [...]
>> At the end of the day, is it a bug that C git doesn't support
>> working with extra commit headers?  IMHO, no, because, we've
>> rejected these in the past, and its not part of the Git standard.
>> And other implementations shouldn't be trying to sell it that way.
>
> Agreed.  And this was discussed in great length on this list on few
> occasions already (probably more than a year back).

One problem, is that if you take the approach you say then you
basically guarantee that a new git that DOES add new headers will
break an old git that doesnt know about the headers, and actually
doesnt care about them either.

So it would essentially mean that if you ever have to change the
commit format you will be in a position where new git commits will be
incompatible by design with old git commits.

Maybe I misunderstand, but this doesnt seem to accord with my reading
of the original design objectives and philosophy of git.

Shouldn't an old git just ignore headers from a new git?

I mean, forget about the fact that somebody is doing something naughty
with the git protocol, ask youself if you want this rule to basically
prevent any backwards compatible changes with older gits.

As a lurker here I understand completely if you ignore this mail
entirely. But this seems to me to be a decision that could bite you
later.

cheers,
Yves





-- 
perl -Mre=debug -e "/just|another|perl|hacker/"