Re: extra headers in commit objects

From: demerphq <demerphq@gmail.com>
Date: Feb 3, 2010, 19:01 UTC
Message-ID: <9b18b3111002031101p3385ecdfo638433bc269791aa@mail.gmail.com>
In-Reply-To: <alpine.LFD.2.00.1002031311010.1681@xanadu.home>

On 3 February 2010 19:15, Nicolas Pitre <nico@fluxnic.net> wrote:

Show 15 quoted lines

> 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/"