{"thread":{"id":"11991","subject":"[RFC] New commit object headers: generation and note headers","startedAt":"2008-02-09T16:46:07Z","lastAt":"2008-02-11T10:08:30Z","messageCount":7,"participants":["Jakub Narebski","Daniel Barkalow","Nguyen Thai Ngoc Duy","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"68096","messageId":"200802091746.09102.jnareb@gmail.com","threadId":"11991","inReplyTo":null,"subject":"[RFC] New commit object headers: generation and note headers","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-09T16:46:07Z","receivedAt":"2008-02-09T16:46:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"As new major git release 1.6.0 is close (BTW. I wonder if git would ever \nreach/get 2.0.0 release...), I'd like to sum up here, adding my own \nthoughts and comments, ideas about extending commit object by adding \nnew headers. I think it would be better to have such major feature \nintroduced in major release, and not with only minor number changed.\nFor some headers the faster it is introduced the better.\n\n\n1. 'generation' header\n\nIn the \"[BUG?] git log picks up bad commit\" thread:\n http://permalink.gmane.org/gmane.comp.version-control.git/72274\nlater \"[RFH] revision limiting sometimes ignored\" there was resurrected \nidea of the 'generation' header. This header is meant to simplify \nremoving uninteresting commits in the presence of clock skew, to \nreplace various commit-time related heuristics.\n\nThe proposed solution (which was at least once discussed in the past on \ngit mailing list) is to use for this \"generation number\":\n 1. For parentless (root) commits it equals 1 (or 0)\n 2. For each commit, it equals maximum of generation numbers of parents,\n plus 1.\nOf course to not to have to recalculate it from beginning it must be \nsaved somewhere. Best solution is to use 'generation' header for that.\n\nUnfortunately there is complication that commits written before this \nheader introduced doesn't have generation number handy. It was proposed\nthen to use generation number if possible, and fallback to old date \nbased heuristic if it does not exist, and do not (re)calculate it;\nthe idea is to avoid such cost.\n\nMy comments:\n============\nThe problem is twofold: when to calculate generation header, and what to \ndo with commits that lacks it. We could require to calculate generation \nheader when creating a commit (commit, amend, rebase, filter-branch), \nbut this might mean that a few first commits after 'generation' header \nis introduced would be much slower.\n\nAs for older commits which lacks generation number header: perhaps some \n(pack)-index-like external storage/cache, where generation numbers will \nbe saved as we generate them? And perhaps some command to generate \ngeneration numbers in advance, in a free time.\n\nNote that keeping generation numbers externally to the object database \nis more error prone (cache sync), and would not propagate.\n\nThe question is if to take grafts and shallows when creating version \nnumbers: if they are to be saved in object database, then no. If saving \nto external pack-index like storage, then perhaps.\n\n\n2. 'note' header (no semantical meaning)\n\nThere was some time ago discussion about adding 'note' header, initially \nto save original sha-1 of a commit for cherry-picking and rebase; then \nfor saving explicit rename or corrected rename info, for saving chosen \nmerge strategy, and for saving original ID of SCM import.\n\nMy comments:\n============\n\n>From all those I think what makes most sense is saving foreign SCM ID \nfor a commit, for commits imported from other SCM. This way we do not \nhave to parse commit message (fragile and ugly, and makes it harder for \ntwo-way exchange: no pristine commit message), or store them externally \n(not propagated, prone to be lost).\n\nAnother would be to save rename and copy info when importing from \nanother SCM which tracks renames and not detects code movement. This \nwould allow (at least theoretically) for lossless import. When \ndetecting renames, in the process of finding common merge base(s), we \ncould check and take into account such information. It would be purely \nadvisory...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"68104","messageId":"alpine.LNX.1.00.0802091220030.13593@iabervon.org","threadId":"11991","inReplyTo":"200802091746.09102.jnareb@gmail.com","subject":"Re: [RFC] New commit object headers: generation and note headers","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-09T17:35:11Z","receivedAt":"2008-02-09T17:35:11Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Sat, 9 Feb 2008, Jakub Narebski wrote:\n\n> As new major git release 1.6.0 is close (BTW. I wonder if git would ever \n> reach/get 2.0.0 release...), I'd like to sum up here, adding my own \n> thoughts and comments, ideas about extending commit object by adding \n> new headers. I think it would be better to have such major feature \n> introduced in major release, and not with only minor number changed.\n> For some headers the faster it is introduced the better.\n> \n> \n> 1. 'generation' header\n> \n> In the \"[BUG?] git log picks up bad commit\" thread:\n> http://permalink.gmane.org/gmane.comp.version-control.git/72274\n> later \"[RFH] revision limiting sometimes ignored\" there was resurrected \n> idea of the 'generation' header. This header is meant to simplify \n> removing uninteresting commits in the presence of clock skew, to \n> replace various commit-time related heuristics.\n> \n> The proposed solution (which was at least once discussed in the past on \n> git mailing list) is to use for this \"generation number\":\n> 1. For parentless (root) commits it equals 1 (or 0)\n> 2. For each commit, it equals maximum of generation numbers of parents,\n> plus 1.\n> Of course to not to have to recalculate it from beginning it must be \n> saved somewhere. Best solution is to use 'generation' header for that.\n> \n> Unfortunately there is complication that commits written before this \n> header introduced doesn't have generation number handy. It was proposed\n> then to use generation number if possible, and fallback to old date \n> based heuristic if it does not exist, and do not (re)calculate it;\n> the idea is to avoid such cost.\n> \n> My comments:\n> ============\n> The problem is twofold: when to calculate generation header, and what to \n> do with commits that lacks it. We could require to calculate generation \n> header when creating a commit (commit, amend, rebase, filter-branch), \n> but this might mean that a few first commits after 'generation' header \n> is introduced would be much slower.\n\nSurely, at least sombody has to do the slow commit that's the first one \nwith a generation number. Maybe make it optional? If Linus calculates the \ngeneration number of some v2.6.x and only merges trees that have been \nrebased on it by people with sufficiently recent git, it should only take \na lot of time once.\n\nIt's probably best to start by only including them if all parents have \nthem, then having a cycle where figuring them out slowly is optional and \ndefaults to off, and then make it default to on once projects are likely \nto have them in general, or at least would be likely to retain them once a \nfew slow commits are done.\n\n> 2. 'note' header (no semantical meaning)\n> \n> There was some time ago discussion about adding 'note' header, initially \n> to save original sha-1 of a commit for cherry-picking and rebase; then \n> for saving explicit rename or corrected rename info, for saving chosen \n> merge strategy, and for saving original ID of SCM import.\n\nProbably want to have a prescribed syntax for specifying what note this \nis, so that different programs using notes don't confuse each other.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"68106","messageId":"fcaeb9bf0802090950l27aa247ei5d067e0f24fcade0@mail.gmail.com","threadId":"11991","inReplyTo":"alpine.LNX.1.00.0802091220030.13593@iabervon.org","subject":"Re: [RFC] New commit object headers: generation and note headers","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2008-02-09T17:50:12Z","receivedAt":"2008-02-09T17:50:12Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sun, Feb 10, 2008 at 12:35 AM, Daniel Barkalow wrote:\n>\n> On Sat, 9 Feb 2008, Jakub Narebski wrote:\n> > 2. 'note' header (no semantical meaning)\n> >\n> > There was some time ago discussion about adding 'note' header, initially\n> > to save original sha-1 of a commit for cherry-picking and rebase; then\n> > for saving explicit rename or corrected rename info, for saving chosen\n> > merge strategy, and for saving original ID of SCM import.\n>\n> Probably want to have a prescribed syntax for specifying what note this\n> is, so that different programs using notes don't confuse each other.\n\nHow about git ignoring all X- headers and let programs freely add\nthem? For example, X-SVN may be used for git-svn.\n\n-- \nDuy\n"},{"id":"68122","messageId":"7vlk5tetaa.fsf@gitster.siamese.dyndns.org","threadId":"11991","inReplyTo":"fcaeb9bf0802090950l27aa247ei5d067e0f24fcade0@mail.gmail.com","subject":"Re: [RFC] New commit object headers: generation and note headers","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-09T21:03:57Z","receivedAt":"2008-02-09T21:03:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Nguyen Thai Ngoc Duy\" writes:\n\n> On Sun, Feb 10, 2008 at 12:35 AM, Daniel Barkalow wrote:\n>>\n>> On Sat, 9 Feb 2008, Jakub Narebski wrote:\n>> > 2. 'note' header (no semantical meaning)\n>> >\n>> > There was some time ago discussion about adding 'note' header, initially\n>> > to save original sha-1 of a commit for cherry-picking and rebase; then\n>> > for saving explicit rename or corrected rename info, for saving chosen\n>> > merge strategy, and for saving original ID of SCM import.\n>>\n>> Probably want to have a prescribed syntax for specifying what note this\n>> is, so that different programs using notes don't confuse each other.\n>\n> How about git ignoring all X- headers and let programs freely add\n> them? For example, X-SVN may be used for git-svn.\n\nPlease don't.\n\nWhen two people/programs create an otherwise identical (for the\npurpose of git) commits that have two different object names,\nthere'd better be a very good reason other than \"I felt like\nadding an extra header that I can use willy-nilly\".\n\nPlease separate the 'note' part and the 'generation' part and\nmake two separate discussion threads.\n\nAnd kill 'note' part altogether, but that can be done in that\nthread ;-).\n"},{"id":"68130","messageId":"200802100026.39340.jnareb@gmail.com","threadId":"11991","inReplyTo":"7vlk5tetaa.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC] New commit object headers: note headers","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-09T23:26:38Z","receivedAt":"2008-02-09T23:26:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sat, 9 Feb 2008, Junio C Hamano wrote:\n> \"Nguyen Thai Ngoc Duy\" writes:\n>> On Sun, Feb 10, 2008 at 12:35 AM, Daniel Barkalow wrote:\n>>> On Sat, 9 Feb 2008, Jakub Narebski wrote:\n>>>>\n>>>> 2. 'note' header (no semantical meaning)\n>>>>\n>>>> There was some time ago discussion about adding 'note' header, initially\n>>>> to save original sha-1 of a commit for cherry-picking and rebase; then\n>>>> for saving explicit rename or corrected rename info, for saving chosen\n>>>> merge strategy, and for saving original ID of SCM import.\n>>>\n>>> Probably want to have a prescribed syntax for specifying what note this\n>>> is, so that different programs using notes don't confuse each other.\n>>\n>> How about git ignoring all X- headers and let programs freely add\n>> them? For example, X-SVN may be used for git-svn.\n> \n> Please don't.\n> \n> When two people/programs create an otherwise identical (for the\n> purpose of git) commits that have two different object names,\n> there'd better be a very good reason other than \"I felt like\n> adding an extra header that I can use willy-nilly\".\n> \n> Please separate the 'note' part and the 'generation' part and\n> make two separate discussion threads.\n> \n> And kill 'note' part altogether, but that can be done in that\n> thread ;-).\n\nAh, well... very good reservation. So here it goes generic 'note'\n(or 'X-*', similarly to non-standarized email headers) header...\n\nStill I think it is would be nice to have original commit id in\na header when importing from foreign SCM. First, it would not pollute\ncommit message, which would be identical with the original commit\nmessage (which allows easy two-way interaction). Second, it is\nmuch easier and much less error prone to extract it by machine.\n\nAs to marking explicitely renames and copies...\n-- \nJakub Narebski\nPoland\n"},{"id":"68137","messageId":"alpine.LSU.1.00.0802100106330.11591@racer.site","threadId":"11991","inReplyTo":"200802100026.39340.jnareb@gmail.com","subject":"Re: [RFC] New commit object headers: note headers","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-02-10T01:08:32Z","receivedAt":"2008-02-10T01:08:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 10 Feb 2008, Jakub Narebski wrote:\n\n> Still I think it is would be nice to have original commit id in a header \n> when importing from foreign SCM. First, it would not pollute commit \n> message, which would be identical with the original commit message \n> (which allows easy two-way interaction). Second, it is much easier and \n> much less error prone to extract it by machine.\n\nI cannot agree to either reason. It is _not_ a git specific header, so it \ndoes not belong in the commit header.\n\nAlso, I find it does not clutter the commit message _at all_, but adds \ninformation that the user might find useful.\n\nLastly, I cannot see _any_ reason why it should be _easier_ or _less error \nprone_ to put an \"original commit id\" into the commit header than into the \ncommit body.\n\nCiao,\nDscho\n"},{"id":"68355","messageId":"200802111108.31828.jnareb@gmail.com","threadId":"11991","inReplyTo":"alpine.LSU.1.00.0802100106330.11591@racer.site","subject":"Re: [RFC] New commit object headers: note headers","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-11T10:08:30Z","receivedAt":"2008-02-11T10:08:30Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sunday, 10 February 2008, Johannes Schindelin wrote:\n> On Sun, 10 Feb 2008, Jakub Narebski wrote:\n> \n>> Still I think it is would be nice to have original commit id in a header \n>> when importing from foreign SCM. First, it would not pollute commit \n>> message, which would be identical with the original commit message \n>> (which allows easy two-way interaction). Second, it is much easier and \n>> much less error prone to extract it by machine.\n> \n> I cannot agree to either reason. It is _not_ a git specific header, so it \n> does not belong in the commit header.\n\nWell, that, and the fact that the same commit imported using two\ndifferent tools, one using this header and one didn't would result\nin different commit object... although if they differ in adding\noriginal revision id to the commit message commit objects would\ndiffer too.\n\n> Also, I find it does not clutter the commit message _at all_, but adds \n> information that the user might find useful.\n\nRevisions ids can be long, and together with prefix introducing\noriginal SCM revision identifier be longer than customary 80\ncharacters.\n\nBesides, \"git cherry-pick\" was changed to _not_ add information\nabout original commit id by default. Shouldn't this apply also\nfor import?\n\n> Lastly, I cannot see _any_ reason why it should be _easier_ or _less error \n> prone_ to put an \"original commit id\" into the commit header than into the \n> commit body.\n\nWell, if commit message talks about foreign commit IDs...\n\n-- \nJakub Narebski\nPoland\n"}]}