From: A Large Angry SCM Date: Thu, 04 Feb 2010 00:41:36 GMT Subject: Re: extra headers in commit objects Message-ID: <4B6A17C0.8030007@gmail.com> In-Reply-To: <20100203192612.GD14799@spearce.org> Shawn O. Pearce wrote: > demerphq wrote: >> On 3 February 2010 19:15, Nicolas Pitre 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. > > As I understand it, the current stance is: > > 1) A compliant Git implementation ignores any headers it doesn't > recognize that appear *after* the optional "encoding" header. > > 2) A compliant Git implementation does not produce any additional > headers in a commit object, because other implementations cannot > perform any machine based reasoning on them. > > 3) All implementations would (eventually) treat all headers equally, > that is they all understand what author, committer, encoding are > and process them the same way. Any new headers should equally > be fully cross-implementation. > >> 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. > > So, we can change the format by adding a new header, after the > optional "encoding" header. > > But such a change needs to be something that an older Git will > safely ignore (due to rule 1), and something that a newer Git can > make really effective use of (due to rule 2 and 3). And that newer > Git must also safely deal with commits missing that new header, due > to the huge number of commits out in the wild without said header. > > And don't even get me started on amending commits with new unknown > headers. Existing implementions of Git tools will drop the extra > headers during the amend, because the headers are viewed as part > of the commit object data... and during an amend you are making a > totally new object. > > For example, git-gui would drop any extra headers during an amend, > because its running `git commit-tree` directly without any way to > tell commit-tree this is for an amend of an existing commit, vs. a > completely new commit... because either way its a new commit object. > >> Shouldn't an old git just ignore headers from a new git? > > Yes, see above. > 4) C-git "owns" the header name space. The git ML is _the_ controlling standards body.