{"thread":{"id":"22506","subject":"extra headers in commit objects","startedAt":"2010-02-03T17:40:41Z","lastAt":"2010-02-04T06:24:49Z","messageCount":20,"participants":["Shawn O. Pearce","Nicolas Pitre","demerphq","Petr Baudis","Sverre Rabbelier","Scott Chacon","Junio C Hamano","Jelmer Vernooij","A Large Angry SCM","Mike Hommey"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"133484","messageId":"20100203174041.GC14799@spearce.org","threadId":"22506","inReplyTo":null,"subject":"extra headers in commit objects","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-02-03T17:40:41Z","receivedAt":"2010-02-03T17:40:41Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Am I correct that core C developers are still under the opinion\nthat extra headers in a commit object aren't encouraged?\n\nThat is, we shouldn't see something like this made-up example:\n\n $ git cat-file commit HEAD\n tree e0fb24d872e2daa1507ea5879e1cdce5c0da9902\n parent ec0865178ad6d8dab9ccd82b07bc3f3dae20542a\n parent 89d61592bddda4dfcb90314be9e06479f712bb7f\n author Junio C Hamano 1265176189 -0800\n committer Junio C Hamano 1265176189 -0800\n bug 18389\n url http://example.com/some/mailing/list/post\n message-id \n\n Merge git://repo.or.cz/git-gui into next\n\n(Sorry Junio for picking on your latest next merge...)\n\n\nToday I came across this \"bug fix\" [1,2] in Dulwich, which is\nclaiming to be a pure-Python implementation of Git.\n\n[1] http://git.samba.org/?p=jelmer/dulwich.git;a=commit;h=bc8d73f1146afba8828a7dadbb4320f592cddcab\n[2] http://git.samba.org/?p=jelmer/dulwich.git;a=commitdiff;h=bc8d73f1146afba8828a7dadbb4320f592cddcab;hp=4e50426fb72e6c9259feecbba5bfcf053af62335\n\nI haven't spoken with Jelmer Vernooij directly about it, but after\nsome indirect email through a 3rd party, it seems he might be under\nthe impression that this really is a bug in Dulwich, because \"other\ngit implementations do it\".\n\nUhm.\n\n\nI thought the canonical reference implementation was C Git\n(aka git-core), as maintained by Junio Hamano, and the object\nformats, core data structures, and network protocols were\nfairly well documented between the Git Community Book and the\nDocumentation/technical/ directory.\n\nThe only other widely used Git implementation that I know of is JGit.\nIt sure as hell doesn't do this, and it sure as hell isn't what I\nwould call the reference implementation for Git... and that project\nis my own baby.\n\nYes, there are many other Git implementations. But I thought nearly\nall of them were toys, and none of them were even close to serving\nthe kind of production volume that JGit serves, and JGit isn't even\nconsidered a production library by most. Yet JGit always tries to\nconform to whatever standard is set by the C implementation.\n\n\nBasically, aside from having a pretty horrible morning thus far,\nand being in a really bad mood, I'm starting to get a bit worried\nabout the proliferation of Git implementations, and what the notion\nof the standard network protocol and file formats is.\n\nWe're starting to see a fork in the basic protocols happen. Hell,\nDulwich 0.4.1 isn't even capable of speaking over the network to\nC Git, but it does talk to itself, so its valid, right? :-(\n\n $ PYTHONPATH=`pwd` ./bin/dul-daemon . &\n $ git clone git://localhost/.git\n Initialized empty Git repository in /usr/local/google/users/sop/tmp/localhost/.git/\n fetch-pack: protocol error: bad band #78\n fatal: early EOF\n fatal: index-pack failed\n\nFortunately a friend of mine is spending some time trying to patch\nit up... trying to get it back in compliance with the C reference\nimplementation.\n\n\nAt the end of the day, is it a bug that C git doesn't support\nworking with extra commit headers? IMHO, no, because, we've\nrejected these in the past, and its not part of the Git standard.\nAnd other implementations shouldn't be trying to sell it that way.\n\n\n\n-- \nShawn.\n"},{"id":"133488","messageId":"alpine.LFD.2.00.1002031311010.1681@xanadu.home","threadId":"22506","inReplyTo":"20100203174041.GC14799@spearce.org","subject":"Re: extra headers in commit objects","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-02-03T18:15:45Z","receivedAt":"2010-02-03T18:15:45Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 3 Feb 2010, Shawn O. Pearce wrote:\n\n> Am I correct that core C developers are still under the opinion\n> that extra headers in a commit object aren't encouraged?\n\nI would say so.\n\n[...]\n> At the end of the day, is it a bug that C git doesn't support\n> working with extra commit headers? IMHO, no, because, we've\n> rejected these in the past, and its not part of the Git standard.\n> And other implementations shouldn't be trying to sell it that way.\n\nAgreed. And this was discussed in great length on this list on few \noccasions already (probably more than a year back).\n\n\nNicolas\n"},{"id":"133500","messageId":"9b18b3111002031101p3385ecdfo638433bc269791aa@mail.gmail.com","threadId":"22506","inReplyTo":"alpine.LFD.2.00.1002031311010.1681@xanadu.home","subject":"Re: extra headers in commit objects","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2010-02-03T19:01:17Z","receivedAt":"2010-02-03T19:01:17Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 3 February 2010 19:15, Nicolas Pitre wrote:\n> On Wed, 3 Feb 2010, Shawn O. Pearce wrote:\n>\n>> Am I correct that core C developers are still under the opinion\n>> that extra headers in a commit object aren't encouraged?\n>\n> I would say so.\n>\n> [...]\n>> At the end of the day, is it a bug that C git doesn't support\n>> working with extra commit headers?  IMHO, no, because, we've\n>> rejected these in the past, and its not part of the Git standard.\n>> And other implementations shouldn't be trying to sell it that way.\n>\n> Agreed.  And this was discussed in great length on this list on few\n> occasions already (probably more than a year back).\n\nOne problem, is that if you take the approach you say then you\nbasically guarantee that a new git that DOES add new headers will\nbreak an old git that doesnt know about the headers, and actually\ndoesnt care about them either.\n\nSo it would essentially mean that if you ever have to change the\ncommit format you will be in a position where new git commits will be\nincompatible by design with old git commits.\n\nMaybe I misunderstand, but this doesnt seem to accord with my reading\nof the original design objectives and philosophy of git.\n\nShouldn't an old git just ignore headers from a new git?\n\nI mean, forget about the fact that somebody is doing something naughty\nwith the git protocol, ask youself if you want this rule to basically\nprevent any backwards compatible changes with older gits.\n\nAs a lurker here I understand completely if you ignore this mail\nentirely. But this seems to me to be a decision that could bite you\nlater.\n\ncheers,\nYves\n\n\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"133502","messageId":"20100203192612.GD14799@spearce.org","threadId":"22506","inReplyTo":"9b18b3111002031101p3385ecdfo638433bc269791aa@mail.gmail.com","subject":"Re: extra headers in commit objects","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-02-03T19:26:12Z","receivedAt":"2010-02-03T19:26:12Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"demerphq wrote:\n> On 3 February 2010 19:15, Nicolas Pitre wrote:\n> > On Wed, 3 Feb 2010, Shawn O. Pearce wrote:\n> >\n> >> Am I correct that core C developers are still under the opinion\n> >> that extra headers in a commit object aren't encouraged?\n> >\n> > I would say so.\n> >\n> > [...]\n> >> At the end of the day, is it a bug that C git doesn't support\n> >> working with extra commit headers? ?IMHO, no, because, we've\n> >> rejected these in the past, and its not part of the Git standard.\n> >> And other implementations shouldn't be trying to sell it that way.\n> >\n> > Agreed. ?And this was discussed in great length on this list on few\n> > occasions already (probably more than a year back).\n> \n> One problem, is that if you take the approach you say then you\n> basically guarantee that a new git that DOES add new headers will\n> break an old git that doesnt know about the headers, and actually\n> doesnt care about them either.\n\nAs I understand it, the current stance is:\n\n1) A compliant Git implementation ignores any headers it doesn't\n recognize that appear *after* the optional \"encoding\" header.\n\n2) A compliant Git implementation does not produce any additional\n headers in a commit object, because other implementations cannot\n perform any machine based reasoning on them.\n\n3) All implementations would (eventually) treat all headers equally,\n that is they all understand what author, committer, encoding are\n and process them the same way. Any new headers should equally\n be fully cross-implementation.\n\n> So it would essentially mean that if you ever have to change the\n> commit format you will be in a position where new git commits will be\n> incompatible by design with old git commits.\n\nSo, we can change the format by adding a new header, after the\noptional \"encoding\" header.\n\nBut such a change needs to be something that an older Git will\nsafely ignore (due to rule 1), and something that a newer Git can\nmake really effective use of (due to rule 2 and 3). And that newer\nGit must also safely deal with commits missing that new header, due\nto the huge number of commits out in the wild without said header.\n\nAnd don't even get me started on amending commits with new unknown\nheaders. Existing implementions of Git tools will drop the extra\nheaders during the amend, because the headers are viewed as part\nof the commit object data... and during an amend you are making a\ntotally new object.\n\nFor example, git-gui would drop any extra headers during an amend,\nbecause its running `git commit-tree` directly without any way to\ntell commit-tree this is for an amend of an existing commit, vs. a\ncompletely new commit... because either way its a new commit object.\n\n> Shouldn't an old git just ignore headers from a new git?\n\nYes, see above.\n \n-- \nShawn.\n"},{"id":"133503","messageId":"20100203192658.GP9553@machine.or.cz","threadId":"22506","inReplyTo":"9b18b3111002031101p3385ecdfo638433bc269791aa@mail.gmail.com","subject":"Re: extra headers in commit objects","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-02-03T19:26:59Z","receivedAt":"2010-02-03T19:26:59Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Feb 03, 2010 at 08:01:17PM +0100, demerphq wrote:\n> Shouldn't an old git just ignore headers from a new git?\n> \n> I mean, forget about the fact that somebody is doing something naughty\n> with the git protocol, ask youself if you want this rule to basically\n> prevent any backwards compatible changes with older gits.\n\nWe have done similar changes in the past and if there would be such\na change, we can phase-in it over the course of several releases.\nI think the fall-out would not be that bad; we have some experience\nwith even making Debian-stable Git compatible with new stuff. ;-)\nAlso, what if any extra header would be essential and we _wanted_\nnon-compatible Git to break down on it?\n\nOn the other hand, allowing this preventively would apparently have\nthe immediate effect of alternative implementations users happily\nstarting to use it, and then to get to the data, people would demand\ngit-core support as well. _And_ so far everyone seems really really\nfairly sure we don't want the headers and it's not likely to change.\n\n\nP.S.: On the other hand, I think that change was probably just\nmisguided, not malicious. And I wouldn't be that hard on Dulwich,\nit's an early-0.x software after all, it's allowed to crash and have\nprotocol issues. ;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nIf you can't see the value in jet powered ants you should turn in\nyour nerd card. -- Dunbal (464142)\n"},{"id":"133505","messageId":"9b18b3111002031140u66acfebbu9e398a600cbcabaa@mail.gmail.com","threadId":"22506","inReplyTo":"20100203192612.GD14799@spearce.org","subject":"Re: extra headers in commit objects","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2010-02-03T19:40:17Z","receivedAt":"2010-02-03T19:40:17Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 3 February 2010 20:26, Shawn O. Pearce wrote:\n> demerphq wrote:\n>> On 3 February 2010 19:15, Nicolas Pitre wrote:\n>> > On Wed, 3 Feb 2010, Shawn O. Pearce wrote:\n>> >\n>> >> Am I correct that core C developers are still under the opinion\n>> >> that extra headers in a commit object aren't encouraged?\n>> >\n>> > I would say so.\n>> >\n>> > [...]\n>> >> At the end of the day, is it a bug that C git doesn't support\n>> >> working with extra commit headers? ?IMHO, no, because, we've\n>> >> rejected these in the past, and its not part of the Git standard.\n>> >> And other implementations shouldn't be trying to sell it that way.\n>> >\n>> > Agreed. ?And this was discussed in great length on this list on few\n>> > occasions already (probably more than a year back).\n>>\n>> One problem, is that if you take the approach you say then you\n>> basically guarantee that a new git that DOES add new headers will\n>> break an old git that doesnt know about the headers, and actually\n>> doesnt care about them either.\n>\n> As I understand it, the current stance is:\n>\n> 1) A compliant Git implementation ignores any headers it doesn't\n>   recognize that appear *after* the optional \"encoding\" header.\n\nIgnores but passes through?\n\n> 2) A compliant Git implementation does not produce any additional\n>   headers in a commit object, because other implementations cannot\n>   perform any machine based reasoning on them.\n>\n> 3) All implementations would (eventually) treat all headers equally,\n>   that is they all understand what author, committer, encoding are\n>   and process them the same way.  Any new headers should equally\n>   be fully cross-implementation.\n>\n>> So it would essentially mean that if you ever have to change the\n>> commit format you will be in a position where new git commits will be\n>> incompatible by design with old git commits.\n>\n> So, we can change the format by adding a new header, after the\n> optional \"encoding\" header.\n>\n> But such a change needs to be something that an older Git will\n> safely ignore (due to rule 1), and something that a newer Git can\n> make really effective use of (due to rule 2 and 3).  And that newer\n> Git must also safely deal with commits missing that new header, due\n> to the huge number of commits out in the wild without said header.\n>\n> And don't even get me started on amending commits with new unknown\n> headers.  Existing implementions of Git tools will drop the extra\n> headers during the amend, because the headers are viewed as part\n> of the commit object data... and during an amend you are making a\n> totally new object.\n>\n> For example, git-gui would drop any extra headers during an amend,\n> because its running `git commit-tree` directly without any way to\n> tell commit-tree this is for an amend of an existing commit, vs. a\n> completely new commit... because either way its a new commit object.\n>\n>> Shouldn't an old git just ignore headers from a new git?\n>\n> Yes, see above.\n\nRight, which seems to sum to up to \"that boat sailed, forget about\nit\", which is fair enough.\n\nWhich I say from the point of view of arbitrary headers not approved\nby the git dev team. You can ensure that any new *approved* headers\nhave the semantics that \"if they arent passed through it doesnt\nmatter\", whereas you cant know whether a header should be passed\nthrough or not that comes from some other source.\n\nWell unless you introduced a convention that some header prefix is to\nbe preserved on amend, but other prefixes shouldnt be.\n\nI can imagine that might be a nasty place to go tho. :-)\n\nAnyway, thanks a lot for taking the time to explain this a bit more.\n\ncheers,\nYves\n\n\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"133507","messageId":"9b18b3111002031143h63aaa6bpa4c91d140a769bb0@mail.gmail.com","threadId":"22506","inReplyTo":"20100203192658.GP9553@machine.or.cz","subject":"Re: extra headers in commit objects","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2010-02-03T19:43:48Z","receivedAt":"2010-02-03T19:43:48Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 3 February 2010 20:26, Petr Baudis wrote:\n> On Wed, Feb 03, 2010 at 08:01:17PM +0100, demerphq wrote:\n>> Shouldn't an old git just ignore headers from a new git?\n>>\n>> I mean, forget about the fact that somebody is doing something naughty\n>> with the git protocol, ask youself if you want this rule to basically\n>> prevent any backwards compatible changes with older gits.\n>\n> We have done similar changes in the past and if there would be such\n> a change, we can phase-in it over the course of several releases.\n> I think the fall-out would not be that bad; we have some experience\n> with even making Debian-stable Git compatible with new stuff. ;-)\n> Also, what if any extra header would be essential and we _wanted_\n> non-compatible Git to break down on it?\n\nRight. The only solution i can see would have had to have been\nimplemented already. And that would involved some headers being marked\n\"pass through\", some \"marked throw away on cherry-pick\" and some\n\"choke horribly if you find this and dont know what it is\".\n\nAnd even with somethng like that one wonders if notes arent really a\nbetter alternative to user defined headers anyway?\n\n> On the other hand, allowing this preventively would apparently have\n> the immediate effect of alternative implementations users happily\n> starting to use it, and then to get to the data, people would demand\n> git-core support as well. _And_ so far everyone seems really really\n> fairly sure we don't want the headers and it's not likely to change.\n\n\nYes, right understood.\n\n>\n> P.S.: On the other hand, I think that change was probably just\n> misguided, not malicious. And I wouldn't be that hard on Dulwich,\n> it's an early-0.x software after all, it's allowed to crash and have\n> protocol issues. ;-)\n\nHeh. I have no opinion on Dulwich. Didnt even know it existed until this mail.\n\nYves\n\n\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"},{"id":"133511","messageId":"fabb9a1e1002031153n6d579484vbd2ea3251fb72738@mail.gmail.com","threadId":"22506","inReplyTo":"20100203174041.GC14799@spearce.org","subject":"Re: extra headers in commit objects","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2010-02-03T19:53:12Z","receivedAt":"2010-02-03T19:53:12Z","isPatch":false,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\n[+cc Jelmer]\n\nOn Wed, Feb 3, 2010 at 18:40, Shawn O. Pearce wrote:\n> I haven't spoken with Jelmer Vernooij directly about it, but after\n> some indirect email through a 3rd party, it seems he might be under\n> the impression that this really is a bug in Dulwich, because \"other\n> git implementations do it\".\n\nThat would seem like the #1 thing to do, I'm sure Jelmer (cc-ed) can\nboth benefit from this discussion, and perhaps explain what is going\non from first hand. Full thread as it's developing can be found here\n[0]. Jelmer, you can just reply to this, no need to subscribe or such.\nAlso, it's custom on the git list to cc all involved, so you should be\nin on the conversation for any emails that are a reply to mine.\n\n[0] http://thread.gmane.org/gmane.comp.version-control.git/138848\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"133515","messageId":"d411cc4a1002031158k3e50db30l3f7d73d49e3dad23@mail.gmail.com","threadId":"22506","inReplyTo":"20100203174041.GC14799@spearce.org","subject":"Re: extra headers in commit objects","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2010-02-03T19:58:25Z","receivedAt":"2010-02-03T19:58:25Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey,\n\nOn Wed, Feb 3, 2010 at 9:40 AM, Shawn O. Pearce wrote:\n> Today I came across this \"bug fix\" [1,2] in Dulwich, which is\n> claiming to be a pure-Python implementation of Git.\n>\n> I haven't spoken with Jelmer Vernooij directly about it, but after\n> some indirect email through a 3rd party, it seems he might be under\n> the impression that this really is a bug in Dulwich, because \"other\n> git implementations do it\".\n\nAt the risk of pissing you off for the second time in as many days,\nthis is entirely my fault. I was having a beer with Jelmer in\nWellington a few weeks ago during LinuxConf.au and we were talking\nabout the difficulties in storing metadata having to do with cross-vcs\nmigrations - specifically his work with an bzr-git bridge and mine\nwith the hg-git project. He was noting that I kept all my metadata\nabout original Hg commits in Git as formatted text in the commit\nmessage, which is pretty uggo (especially with the amount of sometimes\ninconsistent denormalization of data Hg does on commit, explicitly\nrecording renames and manifests and whatnot).\n\nAnyhow, I was saying that _technically_ you can artificially write\nextra headers into the commit object (though at the time Dulwich\ndidn't support reading them because of how it parsed commit objects -\nI believe it would actually explode if it saw something it didn't\nexpect). I said I was still going to keep the metadata in my\nimplementation in the message, but he was very interested in hiding\nhis in the commit headers. To my defense, we (you and I, Shawn)\ntalked about this at the GitTogether this year and you and a few\nothers told me that CGit would not blow up but would just ignore them,\nwhich is fine for his purposes. I certainly did not get the\nimpression from that short discussion that this was something to be\nabsolutely avoided, but rather that it just wasn't really encouraged\nor explicitly supported.\n\nOddly enough, this whole thing basically came up because we were\nnoting that you can hide extra data in Hg changesets, but it's a\nridiculous hack involving adding it after a null byte in the timestamp\nfield, much like we do in adding the capabilities after the first ref\nin the negotiation phase of the tranfer protocol. I was just casually\nsaying, \"yeah, you can actually technically do that a lot cleaner in\nGit\"...\n\nSorry. So, for future reference, though CGit _can_ handle it, don't?\n\nthanks,\nScott\n"},{"id":"133516","messageId":"alpine.LFD.2.00.1002031456510.1681@xanadu.home","threadId":"22506","inReplyTo":"20100203192658.GP9553@machine.or.cz","subject":"Re: extra headers in commit objects","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-02-03T20:03:42Z","receivedAt":"2010-02-03T20:03:42Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 3 Feb 2010, Petr Baudis wrote:\n\n> On Wed, Feb 03, 2010 at 08:01:17PM +0100, demerphq wrote:\n> > Shouldn't an old git just ignore headers from a new git?\n> > \n> > I mean, forget about the fact that somebody is doing something naughty\n> > with the git protocol, ask youself if you want this rule to basically\n> > prevent any backwards compatible changes with older gits.\n> \n> We have done similar changes in the past and if there would be such\n> a change, we can phase-in it over the course of several releases.\n> I think the fall-out would not be that bad; we have some experience\n> with even making Debian-stable Git compatible with new stuff. ;-)\n\nHeh... That's because I was crazy enough to do that work so the new \nfeatures I implemented in the latest version could be enabled by default \nsooner. And incidentally those features weren't controvertial at all \nwhich sorta helped.\n\n\nNicolas\n"},{"id":"133521","messageId":"20100203203148.GF14799@spearce.org","threadId":"22506","inReplyTo":"9b18b3111002031143h63aaa6bpa4c91d140a769bb0@mail.gmail.com","subject":"Re: extra headers in commit objects","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-02-03T20:31:48Z","receivedAt":"2010-02-03T20:31:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"demerphq wrote:\n> On 3 February 2010 20:26, Petr Baudis wrote:\n> Right. The only solution i can see would have had to have been\n> implemented already. And that would involved some headers being marked\n> \"pass through\", some \"marked throw away on cherry-pick\" and some\n> \"choke horribly if you find this and dont know what it is\".\n> \n> And even with somethng like that one wonders if notes arent really a\n> better alternative to user defined headers anyway?\n\nYes, exactly.\n\nI think notes turn out to be a much better way to store this extra\ndata, provided you are OK with them being disconnected during an\namend, cherry-pick, filter-branch, or rebase... :-)\n\nAnd unlike additional headers, git implementations will likely\nsupport notes, because they are a good way to attach additional\nuser data onto commits.\n \n-- \nShawn.\n"},{"id":"133528","messageId":"7vwryugifz.fsf@alter.siamese.dyndns.org","threadId":"22506","inReplyTo":"20100203192612.GD14799@spearce.org","subject":"Re: extra headers in commit objects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-03T20:42:08Z","receivedAt":"2010-02-03T20:42:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> As I understand it, the current stance is:\n>\n> 1) A compliant Git implementation ignores any headers it doesn't\n> recognize that appear *after* the optional \"encoding\" header.\n\nI first read the above to mean that you need to add encoding if you want\nto throw in other garbage.\n\nI would say \"*after* the mandatory 'tree', 'parent' (0 or more), 'author',\nand 'committer' headers that must appear in this order\", for clarity.\n\n> 2) A compliant Git implementation does not produce any additional\n> headers in a commit object, because other implementations cannot\n> perform any machine based reasoning on them.\n>\n> 3) All implementations would (eventually) treat all headers equally,\n> that is they all understand what author, committer, encoding are\n> and process them the same way. Any new headers should equally\n> be fully cross-implementation.\n\nThese are very important points.\n\nIn your made-up example you added \"bug\" (presumably to mean \"fixes this\nbug\") and \"message-id\" (\"am-ed from this message\"). The latter might make\nsense, but the former does not belong to the header, as it is not a\nstatement of the fact.\n\nForcing people to say \"this fixes\" at the commit time means you do not\nallow mistakes---it may turn out to be an incorrect or non fix later.\nWhen you are amending the commit to say \"this does not really fix it\", you\nwould want to lose the old \"bug\" header, but you would want to keep the\n\"message-id\" one. There simply is not enough hint as to which ones must\nbe carried across amending in the \"we allow people to randomly throw extra\nheaders into the commit object\" model. It is not a model--it is chaos.\n\nAlso it wouldn't be obvious to other people what got changed while\ncomparing two commits (before and after the amend) if the information is\nhidden in the header. The right place for that kind of information is in\nthe log message (if the nature of the information is for everybody to see)\nor in notes.\n\nAnother major difference between extra random headers and notes is that\nthe former changes the commit's object name, and if it is due to \"random\nheaders\", it means you are breaking the object model for no good reason.\n\nIntroducing extra headers needs to be done _very_ carefully after thinking\nthings through, judging the pros and cons. Even though we kept the format\nopen to allow us to extend the format to add essential statement of fact\nthat we can make at the commit time (e.g. \"encoding\"), I do not foresee us\nadding any official extra headers in near future.\n"},{"id":"133535","messageId":"1265230702.7429.54.camel@ganieda","threadId":"22506","inReplyTo":"20100203174041.GC14799@spearce.org","subject":"Re: extra headers in commit objects","fromName":"Jelmer Vernooij","fromEmail":"jelmer@samba.org","sentAt":"2010-02-03T20:58:22Z","receivedAt":"2010-02-03T20:58:22Z","isPatch":false,"sender":{"key":"jelmer@samba.org","avatar":"https://avatars.githubusercontent.com/u/49032?v=4"},"body":"Hi Shawn,\n\nOn Wed, 2010-02-03 at 09:40 -0800, Shawn O. Pearce wrote:\n> Am I correct that core C developers are still under the opinion\n> that extra headers in a commit object aren't encouraged?\n> \n> That is, we shouldn't see something like this made-up example:\n> \n> $ git cat-file commit HEAD\n> tree e0fb24d872e2daa1507ea5879e1cdce5c0da9902\n> parent ec0865178ad6d8dab9ccd82b07bc3f3dae20542a\n> parent 89d61592bddda4dfcb90314be9e06479f712bb7f\n> author Junio C Hamano 1265176189 -0800\n> committer Junio C Hamano 1265176189 -0800\n> bug 18389\n> url http://example.com/some/mailing/list/post\n> message-id \n> \n> Merge git://repo.or.cz/git-gui into next\n> \n> (Sorry Junio for picking on your latest next merge...)\n\n> Today I came across this \"bug fix\" [1,2] in Dulwich, which is\n> claiming to be a pure-Python implementation of Git.\n> \n> [1] http://git.samba.org/?p=jelmer/dulwich.git;a=commit;h=bc8d73f1146afba8828a7dadbb4320f592cddcab\n> [2] http://git.samba.org/?p=jelmer/dulwich.git;a=commitdiff;h=bc8d73f1146afba8828a7dadbb4320f592cddcab;hp=4e50426fb72e6c9259feecbba5bfcf053af62335\n> \n> I haven't spoken with Jelmer Vernooij directly about it, but after\n> some indirect email through a 3rd party, it seems he might be under\n> the impression that this really is a bug in Dulwich, because \"other\n> git implementations do it\".\nIf you have concerns like this in the future, please don't hesitate to\ncontact me directly. I don't follow the git list because it's a\nhigh-volume list where pretty much all traffic is irrelevant to me. The\nonly reason I became aware of this thread was because Sverre CC'ed me.\n\n> Uhm.\nOriginally I was under the impression that custom headers would break\n(by reading the C Git source code) and so Dulwich made that assumption,\nbut after hearing from several people (among whom Scott, see his reply)\nat Linux.Conf.Au that custom headers could be added and were ignored by\nC git I made this change.\n\nSince Dulwich would blow up when it encountered custom headers that\nmight be set by other Git implements and since (as I understand) C git\nignores unknown headers, I called this a bug fix. This change made it\npossible to deal with custom headers whenever they would appear *and*\nallowed users of the Dulwich API to set custom headers. \n\n(FWIW I haven't actually seen anybody setting custom headers)\n\nIf this is indeed a misunderstanding, I'll happily make this\ndatastructure with custom headers read-only.\n\n[...]\n> Yes, there are many other Git implementations. But I thought nearly\n> all of them were toys, and none of them were even close to serving\n> the kind of production volume that JGit serves, and JGit isn't even\n> considered a production library by most. Yet JGit always tries to\n> conform to whatever standard is set by the C implementation.\nSo does Dulwich. I've fixed issues in the compatibility with C Git when\nI've noticed them or have been made aware of them. Any incompatibilities\nare the result of ignorance on my part rather than malicious intent.\n\n[...]\n\n> We're starting to see a fork in the basic protocols happen. Hell,\n> Dulwich 0.4.1 isn't even capable of speaking over the network to\n> C Git, but it does talk to itself, so its valid, right? :-(\nI've been using Dulwich's client to talk to C Git servers for ages and\nhaven't seen issues. I would appreciate hearing about\nincompatibilities. \n\nIf you're talking about the server side - we know it's broken, at least\ndul-daemon. Nobody (except for API changes) has really cared about it\nsince John Carr originally hacked it up. I'd be surprised if it even\nworks with the Dulwich client.\n\nCheers,\n\nJelmer\n"},{"id":"133534","messageId":"20100203210407.GG14799@spearce.org","threadId":"22506","inReplyTo":"7vwryugifz.fsf@alter.siamese.dyndns.org","subject":"Re: extra headers in commit objects","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-02-03T21:04:07Z","receivedAt":"2010-02-03T21:04:07Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> \"Shawn O. Pearce\" writes:\n> \n> > As I understand it, the current stance is:\n> >\n> > 1) A compliant Git implementation ignores any headers it doesn't\n> > recognize that appear *after* the optional \"encoding\" header.\n> \n> I first read the above to mean that you need to add encoding if you want\n> to throw in other garbage.\n> \n> I would say \"*after* the mandatory 'tree', 'parent' (0 or more), 'author',\n> and 'committer' headers that must appear in this order\", for clarity.\n\nYes, sorry, of course that is what I meant. Thanks for the\nclarification.\n\nTo add to that, \"after encoding, if encoding is present\".\n \n> > 2) A compliant Git implementation does not produce any additional\n> > headers in a commit object, because other implementations cannot\n> > perform any machine based reasoning on them.\n> >\n> > 3) All implementations would (eventually) treat all headers equally,\n> > that is they all understand what author, committer, encoding are\n> > and process them the same way. Any new headers should equally\n> > be fully cross-implementation.\n> \n> These are very important points.\n> \n> In your made-up example you added \"bug\" (presumably to mean \"fixes this\n> bug\") and \"message-id\" (\"am-ed from this message\"). The latter might make\n> sense, but the former does not belong to the header, as it is not a\n> statement of the fact.\n\nThis all came out of what appears to be a tool to bridge another\nVCS system data into Git. Ala git-svn.\n\nWe all know that some other systems, e.g. SVN, permit adding\nadditional properties to commits, and that often these are used\nto make statements like \"Fixed bug NNNN\", and bug tracking systems\nintegrate into SVN by reading or updating those properties.\n\nSo you, Nico, myself, might all agree that \"bug\" does not belong\nin the header, but many others see it like SVN sees additional\nproperties on a revision, and thus it goes there.\n\nHence the artifical example. It seems that it is not that artifical\noutside of our mailing list.\n \n> Forcing people to say \"this fixes\" at the commit time means you do not\n> allow mistakes---it may turn out to be an incorrect or non fix later.\n\nYup, happens often.\n\n> When you are amending the commit to say \"this does not really fix it\", you\n> would want to lose the old \"bug\" header, but you would want to keep the\n> \"message-id\" one. There simply is not enough hint as to which ones must\n> be carried across amending in the \"we allow people to randomly throw extra\n> headers into the commit object\" model. It is not a model--it is chaos.\n\nExactly. That's what I had thought our position was, for exactly\nthis reason, it very quickly devolves into a chaos we can't reason\nabout, let alone write code to support for end-users.\n\n> Also it wouldn't be obvious to other people what got changed while\n> comparing two commits (before and after the amend) if the information is\n> hidden in the header. The right place for that kind of information is in\n> the log message (if the nature of the information is for everybody to see)\n> or in notes.\n\nI'm afraid users might insert their own headers, then come report\nthe bug that `git log` and `git show` don't make those headers\nvisible when formatting the commit. After all, they show the author\ncommitter, and parent information when you use the right flags.\n\nWe'll of course say, its not in the message, and suggest using the\nfooter style like our Signed-off-by lines, or notes, which appear\nbelow the message if requested.\n\n> Introducing extra headers needs to be done _very_ carefully after thinking\n> things through, judging the pros and cons. Even though we kept the format\n> open to allow us to extend the format to add essential statement of fact\n> that we can make at the commit time (e.g. \"encoding\"), I do not foresee us\n> adding any official extra headers in near future.\n\nRight, me neither, because everything that has been proposed for an\nextra header (e.g. bug id, Message-Id from the email it as git-amed\nfrom, rename tracking, ...) has all been suggested to be better\npositioned in the message itself, or in a note, or not at all...\n\n-- \nShawn.\n"},{"id":"133538","messageId":"alpine.LFD.2.00.1002031612480.1681@xanadu.home","threadId":"22506","inReplyTo":"1265230702.7429.54.camel@ganieda","subject":"Re: extra headers in commit objects","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-02-03T21:17:23Z","receivedAt":"2010-02-03T21:17:23Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 3 Feb 2010, Jelmer Vernooij wrote:\n\n> Since Dulwich would blow up when it encountered custom headers that\n> might be set by other Git implements and since (as I understand) C git\n> ignores unknown headers, I called this a bug fix. This change made it\n> possible to deal with custom headers whenever they would appear *and*\n> allowed users of the Dulwich API to set custom headers. \n> \n> (FWIW I haven't actually seen anybody setting custom headers)\n> \n> If this is indeed a misunderstanding, I'll happily make this\n> datastructure with custom headers read-only.\n\nPlease do so.\n\nIt is best to consider the Git note facility for the addition of such \ncustom notations. Notes can be attached to commits and changed at will \nwhile the commit objects themselves cannot (unless you rewrite history).\n\n\nNicolas\n"},{"id":"133548","messageId":"20100203223901.GJ14799@spearce.org","threadId":"22506","inReplyTo":"1265230702.7429.54.camel@ganieda","subject":"Re: extra headers in commit objects","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-02-03T22:39:01Z","receivedAt":"2010-02-03T22:39:01Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jelmer Vernooij wrote:\n> On Wed, 2010-02-03 at 09:40 -0800, Shawn O. Pearce wrote:\n> > \n> > I haven't spoken with Jelmer Vernooij directly about it, but after\n> > some indirect email through a 3rd party, it seems he might be under\n> > the impression that this really is a bug in Dulwich, because \"other\n> > git implementations do it\".\n>\n> If you have concerns like this in the future, please don't hesitate to\n> contact me directly.\n\nOK.\n\n> I don't follow the git list because it's a\n> high-volume list where pretty much all traffic is irrelevant to me. The\n> only reason I became aware of this thread was because Sverre CC'ed me.\n\nI probably should have CC'd you in from the beginning, sorry.\n\nIts true, this is a high-volume list. But we don't see much, if\nanything, about Dulwich here. Yet I for one like to see discussion\nabout other implementations here, to some extent, so its easier\nto make sure everyone is staying close to the C implementation's\nreference standard.\n\n> Originally I was under the impression that custom headers would break\n> (by reading the C Git source code) and so Dulwich made that assumption,\n> but after hearing from several people (among whom Scott, see his reply)\n> at Linux.Conf.Au that custom headers could be added and were ignored by\n> C git I made this change.\n\nYes, apparently Scott didn't quite represent things accurately.\nOh well, it seems its been raised now, and beaten to death.\n \n> Since Dulwich would blow up when it encountered custom headers that\n> might be set by other Git implements and since (as I understand) C git\n> ignores unknown headers, I called this a bug fix.\n\nThat's true, and I'm glad you have made that change to Dulwich. It is\na good bug fix to skip over headers you don't recognize.\n\nBut, its a new incompatible feature to support writing extra headers.\n\n> If this is indeed a misunderstanding, I'll happily make this\n> datastructure with custom headers read-only.\n\nYes. Please see the other messages in this thread, especially from\nNico and Junio. Setting other headers is not a good idea, and you\nshouldn't encourage it in Dulwich by making an API available.\n \n> > Yes, there are many other Git implementations. But I thought nearly\n> > all of them were toys, and none of them were even close to serving\n> > the kind of production volume that JGit serves, and JGit isn't even\n> > considered a production library by most. Yet JGit always tries to\n> > conform to whatever standard is set by the C implementation.\n>\n> So does Dulwich. I've fixed issues in the compatibility with C Git when\n> I've noticed them or have been made aware of them. Any incompatibilities\n> are the result of ignorance on my part rather than malicious intent.\n\nI'm glad to hear that.\n\nSee above about keeping discussion related to other Git implementations\nhere. We're happy to help explain something that is perhaps vague or\npoorly specified. Not everyone has the answer right away, but usually\nthe list fills in everything.\n \n> > We're starting to see a fork in the basic protocols happen. Hell,\n> > Dulwich 0.4.1 isn't even capable of speaking over the network to\n> > C Git, but it does talk to itself, so its valid, right? :-(\n>\n> I've been using Dulwich's client to talk to C Git servers for ages and\n> haven't seen issues. I would appreciate hearing about\n> incompatibilities. \n\nOK, I haven't actually looked at the Dulwich client code... so I\ndon't know what its current state is.\n \n> If you're talking about the server side - we know it's broken, at least\n> dul-daemon. Nobody (except for API changes) has really cared about it\n> since John Carr originally hacked it up. I'd be surprised if it even\n> works with the Dulwich client.\n\nOK, then you may be interested in some of the patches my friend\nDave worked up (he said he was going to send them to you).\nDave discovered the server wasn't playing nice with C git, and\nasked me for some protocol help to get it going again.\n\nI'm glad its only an issue of neglect (lack of time) and not\nsomething else that has caused it to be incompatible.\n\n-- \nShawn.\n"},{"id":"133549","messageId":"20100203224835.GK14799@spearce.org","threadId":"22506","inReplyTo":"d411cc4a1002031158k3e50db30l3f7d73d49e3dad23@mail.gmail.com","subject":"Re: extra headers in commit objects","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-02-03T22:48:35Z","receivedAt":"2010-02-03T22:48:35Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Scott Chacon wrote:\n> On Wed, Feb 3, 2010 at 9:40 AM, Shawn O. Pearce wrote:\n> > Today I came across this \"bug fix\" [1,2] in Dulwich, which is\n> > claiming to be a pure-Python implementation of Git.\n> >\n> > I haven't spoken with Jelmer Vernooij directly about it, but after\n> > some indirect email through a 3rd party, it seems he might be under\n> > the impression that this really is a bug in Dulwich, because \"other\n> > git implementations do it\".\n> \n> At the risk of pissing you off for the second time in as many days,\n> this is entirely my fault.\n\nApparently, s**t happens is a good phrase. One I need to learn.\n\n> I was having a beer with Jelmer in Wellington a few weeks ago\n\nAnd... beer doesn't promote clear thinking.\n\nAll is forgiven. As is yesterday's remark about not telling me\nsooner about a JGit bug. You really didn't do anything bad, I\njust woke up on the wrong side of the bed the past couple of days,\nand sort of went off...\n\nSorry. :-\\\n\n> Anyhow, I was saying that _technically_ you can artificially write\n> extra headers into the commit object (though at the time Dulwich\n> didn't support reading them because of how it parsed commit objects -\n> I believe it would actually explode if it saw something it didn't\n> expect). I said I was still going to keep the metadata in my\n> implementation in the message, but he was very interested in hiding\n> his in the commit headers.\n\nYea, everyone wants to hide that extra metadata. I never get why.\nEven in SVN. Why wouldn't I want to see the bug(s) fixed by\na commit? Difference of opinion. I also happen to prefer the\ncolor blue. Dammit, everyone should prefer blue.\n\n> To my defense, we (you and I, Shawn)\n> talked about this at the GitTogether this year and you and a few\n> others told me that CGit would not blow up but would just ignore them,\n> which is fine for his purposes. I certainly did not get the\n> impression from that short discussion that this was something to be\n> absolutely avoided, but rather that it just wasn't really encouraged\n> or explicitly supported.\n\nSorry. I've held this same opinion as Junio and Nico have expressed\nin this thread, that although we ignore extra headers, its only to\nleave us an escape hatch in case we add something like \"encoding\"\nin the future. Adding encoding was almost a nightmare because we\ndidn't have that escape hatch.\n\nI also hold the opinion that the C implementation is correct,\nand everyone else is wrong. Even JGit. Unless its a bug in the\nC implementation, in which case the bug fix is correct. :-)\n\nWhich in this case means, if the C implementation doesn't give\nthe user plumbing to do something (aside from using git mkobject),\nyou really should think twice before doing it.\n\nSo I apologize if I gave you the wrong impression at the GitTogether.\nI claim stupidity as my only defense.\n\n> Sorry. So, for future reference, though CGit _can_ handle it, don't?\n\nC Git won't choke if there are extra headers.\n\nBut we _really_ don't want them. And C Git won't be writing any new\nheaders anytime soon. I think we're more likely to shift the entire\nhashing scheme to SHA-512 or something before we add a new header.\n\n-- \nShawn.\n"},{"id":"133556","messageId":"7v8wb96die.fsf@alter.siamese.dyndns.org","threadId":"22506","inReplyTo":"20100203210407.GG14799@spearce.org","subject":"Re: extra headers in commit objects","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-02-04T00:38:49Z","receivedAt":"2010-02-04T00:38:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" writes:\n\n> We all know that some other systems, e.g. SVN, permit adding\n> additional properties to commits, and that often these are used\n> to make statements like \"Fixed bug NNNN\", and bug tracking systems\n> integrate into SVN by reading or updating those properties.\n>\n> So you, Nico, myself, might all agree that \"bug\" does not belong\n> in the header, but many others see it like SVN sees additional\n> properties on a revision, and thus it goes there.\n>\n> Hence the artifical example. It seems that it is not that artifical\n> outside of our mailing list.\n\nAren't the meta-properties like \"Fixed bug NNNN\" something you can add\nafter the fact, even in SVN?\n\nWe have that in \"notes\". I never said people are wrong for wanting to\nrecord additional information _about_ commits somewhere (and I didn't say\n\"artificial\" at all---it was you who said it was a \"made-up\" example).\n\nMy point was that they do not belong to the commit _header_, and \"but many\nothers see\" doesn't contradict with that. Many others may feel the need\nto be able to express random things _about_ the commit; it does not mean\nthese random things have to go _in_ the commit.\n"},{"id":"133557","messageId":"4B6A17C0.8030007@gmail.com","threadId":"22506","inReplyTo":"20100203192612.GD14799@spearce.org","subject":"Re: extra headers in commit objects","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2010-02-04T00:41:36Z","receivedAt":"2010-02-04T00:41:36Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Shawn O. Pearce wrote:\n> demerphq wrote:\n>> On 3 February 2010 19:15, Nicolas Pitre wrote:\n>>> On Wed, 3 Feb 2010, Shawn O. Pearce wrote:\n>>>\n>>>> Am I correct that core C developers are still under the opinion\n>>>> that extra headers in a commit object aren't encouraged?\n>>> I would say so.\n>>>\n>>> [...]\n>>>> At the end of the day, is it a bug that C git doesn't support\n>>>> working with extra commit headers? ?IMHO, no, because, we've\n>>>> rejected these in the past, and its not part of the Git standard.\n>>>> And other implementations shouldn't be trying to sell it that way.\n>>> Agreed. ?And this was discussed in great length on this list on few\n>>> occasions already (probably more than a year back).\n>> One problem, is that if you take the approach you say then you\n>> basically guarantee that a new git that DOES add new headers will\n>> break an old git that doesnt know about the headers, and actually\n>> doesnt care about them either.\n> \n> As I understand it, the current stance is:\n> \n> 1) A compliant Git implementation ignores any headers it doesn't\n> recognize that appear *after* the optional \"encoding\" header.\n> \n> 2) A compliant Git implementation does not produce any additional\n> headers in a commit object, because other implementations cannot\n> perform any machine based reasoning on them.\n> \n> 3) All implementations would (eventually) treat all headers equally,\n> that is they all understand what author, committer, encoding are\n> and process them the same way. Any new headers should equally\n> be fully cross-implementation.\n> \n>> So it would essentially mean that if you ever have to change the\n>> commit format you will be in a position where new git commits will be\n>> incompatible by design with old git commits.\n> \n> So, we can change the format by adding a new header, after the\n> optional \"encoding\" header.\n> \n> But such a change needs to be something that an older Git will\n> safely ignore (due to rule 1), and something that a newer Git can\n> make really effective use of (due to rule 2 and 3). And that newer\n> Git must also safely deal with commits missing that new header, due\n> to the huge number of commits out in the wild without said header.\n> \n> And don't even get me started on amending commits with new unknown\n> headers. Existing implementions of Git tools will drop the extra\n> headers during the amend, because the headers are viewed as part\n> of the commit object data... and during an amend you are making a\n> totally new object.\n> \n> For example, git-gui would drop any extra headers during an amend,\n> because its running `git commit-tree` directly without any way to\n> tell commit-tree this is for an amend of an existing commit, vs. a\n> completely new commit... because either way its a new commit object.\n> \n>> Shouldn't an old git just ignore headers from a new git?\n> \n> Yes, see above.\n> \n\n4) C-git \"owns\" the header name space. The git ML is _the_ controlling \nstandards body.\n"},{"id":"133588","messageId":"20100204062449.GC6097@glandium.org","threadId":"22506","inReplyTo":"20100203224835.GK14799@spearce.org","subject":"Re: extra headers in commit objects","fromName":"Mike Hommey","fromEmail":"mh@glandium.org","sentAt":"2010-02-04T06:24:49Z","receivedAt":"2010-02-04T06:24:49Z","isPatch":false,"sender":{"key":"mh@glandium.org","avatar":"https://avatars.githubusercontent.com/u/1038527?v=4"},"body":"On Wed, Feb 03, 2010 at 02:48:35PM -0800, Shawn O. Pearce wrote:\n> > Anyhow, I was saying that _technically_ you can artificially write\n> > extra headers into the commit object (though at the time Dulwich\n> > didn't support reading them because of how it parsed commit objects -\n> > I believe it would actually explode if it saw something it didn't\n> > expect). I said I was still going to keep the metadata in my\n> > implementation in the message, but he was very interested in hiding\n> > his in the commit headers.\n> \n> Yea, everyone wants to hide that extra metadata. I never get why.\n> Even in SVN. Why wouldn't I want to see the bug(s) fixed by\n> a commit? Difference of opinion. I also happen to prefer the\n> color blue. Dammit, everyone should prefer blue.\n\nNote, though, that such information may change in the future, in which\ncase you can't rewrite the commit to fit that.\nBut for all that, there are git-notes, now, aren't there ?\n\nMike\n"}]}