Shawn O. Pearce wrote:
demerphq <demerphq@xxxxxxxxx> wrote:
On 3 February 2010 19:15, Nicolas Pitre <nico@xxxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html