On 3 February 2010 20:26, Shawn O. Pearce <spearce@xxxxxxxxxxx> 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. Ignores but passes through? > 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. Right, which seems to sum to up to "that boat sailed, forget about it", which is fair enough. Which I say from the point of view of arbitrary headers not approved by the git dev team. You can ensure that any new *approved* headers have the semantics that "if they arent passed through it doesnt matter", whereas you cant know whether a header should be passed through or not that comes from some other source. Well unless you introduced a convention that some header prefix is to be preserved on amend, but other prefixes shouldnt be. I can imagine that might be a nasty place to go tho. :-) Anyway, thanks a lot for taking the time to explain this a bit more. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- 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