{"thread":{"id":"2584","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","startedAt":"2005-11-17T23:07:23Z","lastAt":"2005-11-23T17:14:04Z","messageCount":29,"participants":["Yann Dirson","Johannes Schindelin","sf","Josef Weidendorfer","Linus Torvalds","Junio C Hamano","Matthias Urlichs","Ryan Anderson","Paul Mackerras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"12158","messageId":"20051117230723.GD26122@nowhere.earth","threadId":"2584","inReplyTo":null,"subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-17T23:07:23Z","receivedAt":"2005-11-17T23:07:23Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Ryan wrote:\n> Junio wrote:\n> > Also another rhetorical, tongue-in-cheek question. What is your\n> > plan to ripple the graft through to update signed tags? ;-)\n> \n> :) Well, since I can't resist answering your rhetorical question:\n> \n> They signed a specific DAG. I'm providing a richer, more complete DAG\n> that is a pure-superset of the one they signed. It is not, however,\n> equivalent, so their signature is not related to the superset DAG I have\n> created. In practice, however, I don't expect that any tag-signers\n> would state that there is a meaningful difference between the two DAGs,\n> from the perspective of their signature.\n\nWell, that seems the perfect place to mention an idea that's running\nin my head since a couple of days, related to the grafing problem.\nI'll write it here in case the idea would look interesting to others,\nwho may then find a solution to the problem stated by Junio.\n\nCurrent commit objects refer to a child tree, but to parent _commits_.\nWhereas it seems necessary to walk through the history line, and\neasily get a changelog, it is semantically quite not right: the\nchanges we record with a commit indeed come from modification of\ntrees, not of commits. That is, the resulting tree does not depend on\nthe history of the parent trees, but on the parent trees themselves.\nAnd similarly, tags usually denote a particular state of the tree,\n\"somewhat\" independantly of its history: linux-2.6.11 is the same\nbeast, whereas the repository holds full history since 0.1 or not.\n\nIndeed that emphasizes that the history lines are on living on a\nhigher level of abstraction that commits. Now what if we used\ntrees->tree commits, instead of the current commits->tree ones ? The\nmain problem would be to be able to reconstruct those history lines,\nso that we can still extract the log - what's a better model if we\nloose functionnality ? ;)\n\nHowever, I must admit that at this point, I have not found a\nreasonable solution to this problem.\n\nAny genius with a solution out there ? :)\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"12164","messageId":"Pine.LNX.4.63.0511180026080.18775@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2584","inReplyTo":"20051117230723.GD26122@nowhere.earth","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-17T23:28:56Z","receivedAt":"2005-11-17T23:28:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 18 Nov 2005, Yann Dirson wrote:\n\n> Current commit objects refer to a child tree, but to parent _commits_.\n> Whereas it seems necessary to walk through the history line, and\n> easily get a changelog, it is semantically quite not right:\n\nYes, it is. You base *your* work on *some* work. So, even if the trees may \nbe equal, the base isn't.\n\n> Indeed that emphasizes that the history lines are on living on a\n> higher level of abstraction that commits. Now what if we used\n> trees->tree commits, instead of the current commits->tree ones ?\n\nNow, how exactly would that be more abstract? Trees are just that: \ncollections of files. Noone tells you what the idea was, which led from \nthe last tree(s) to this one. That is not abstract.\n\n> Any genius with a solution out there ? :)\n\nNot a genius, but me: Write down your ideas in the commit message. That it \nthe place to put abstract thoughts into.\n\nCiao,\nDscho\n"},{"id":"12222","messageId":"437DDDB1.60103@b-i-t.de","threadId":"2584","inReplyTo":"20051117230723.GD26122@nowhere.earth","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"sf","fromEmail":"sf@b-i-t.de","sentAt":"2005-11-18T13:57:05Z","receivedAt":"2005-11-18T13:57:05Z","isPatch":false,"sender":{"key":"sf@b-i-t.de","avatar":null},"body":"Yann Dirson wrote:\n...\n> Current commit objects refer to a child tree, but to parent _commits_.\n> Whereas it seems necessary to walk through the history line, and\n> easily get a changelog, it is semantically quite not right: the\n> changes we record with a commit indeed come from modification of\n> trees, not of commits. That is, the resulting tree does not depend on\n> the history of the parent trees, but on the parent trees themselves.\n\nI would go even further: The resulting tree does not depend on anything. \nA tree is a tree is a tree.\n\nA commit is really just the statement: \"I changed the tree from state A \nto state B\". After all, the commit message does not describe the new \nstate (neither the old state) but does describe the changes.\n\n> And similarly, tags usually denote a particular state of the tree,\n> \"somewhat\" independantly of its history: linux-2.6.11 is the same\n> beast, whereas the repository holds full history since 0.1 or not.\n\nExactly, the tree \"linux-2.6.11\" is the tree \"linux-2.6.11\". How it came \nabout is totally irrelevant if you are only interested in this \nparticular version (does anyone download all linux-*.tar.bz2 just to get \n linux-2.6.11.tar.bz2?).\n\n> Indeed that emphasizes that the history lines are on living on a\n> higher level of abstraction that commits. Now what if we used\n> trees->tree commits, instead of the current commits->tree ones ? The\n> main problem would be to be able to reconstruct those history lines,\n> so that we can still extract the log - what's a better model if we\n> loose functionnality ? ;)\n\nYou can traverse tree -> commit -> tree -> commit -> tree ... to get the \nhistory. No functionality lost.\n\n> However, I must admit that at this point, I have not found a\n> reasonable solution to this problem.\n> \n> Any genius with a solution out there ? :)\n\nIn your model you have a mapping from commits to sets of trees (by way \nof commit objects). Now you create the \"inverse\" mapping from trees to \nsets of commits. Both mappings together enable you to walk the history.\n\nWhy is git's model different?\n\n1. You have to watch out for circles in history (Git's model ensures \nthat history is always a DAG).\n\n2. Your model is harder to implement in the typical case (But deleting \nfrom repositiories, partial repositories, augmenting or cutting history \netc. are hard to implement as it is now, if not outright impossible).\n\n3. It is the way repositories have been organized ever since CVS (Git \nthrows out some concepts of the CVS model, but not all).\n\n\nRegards\n\tStephan\n"},{"id":"12225","messageId":"200511181654.21052.Josef.Weidendorfer@gmx.de","threadId":"2584","inReplyTo":"20051117230723.GD26122@nowhere.earth","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2005-11-18T15:54:20Z","receivedAt":"2005-11-18T15:54:20Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Friday 18 November 2005 00:07, Yann Dirson wrote:\n> Current commit objects refer to a child tree, but to parent _commits_.\n> Whereas it seems necessary to walk through the history line, and\n> easily get a changelog, it is semantically quite not right: the\n> changes we record with a commit indeed come from modification of\n> trees, not of commits.\n\nYes. The change to a tree (which is equalent to 2 trees - new old and\nthe new one; or for merges multiple old ones and the new one) does not\ndepend on any history. Unfortunately, we have no separate object to\nspecify the \"the change to a tree\". We include this information into\nthe commit object, and thus, bind it to the history.\n\nThis could be changed in git, i.e. put the tree relationship into a\nseparate object; even comments could be split up in change related and\nhistory related. The question is: is this useful, is there any\nimportant usage scenario that rectifies such a change?\nI do not really think so.\n\n> That is, the resulting tree does not depend on \n> the history of the parent trees, but on the parent trees themselves.\n\nNo, the resulting tree is an independent object, it is the tree ;-)\nDo not confuse this with the commit pointing to the tree.\n\n> And similarly, tags usually denote a particular state of the tree,\n> \"somewhat\" independantly of its history: linux-2.6.11 is the same\n> beast, whereas the repository holds full history since 0.1 or not.\n\nI agree that tags for tree objects are useful, but what is the problem?\nYou can do this already.\n\nBut tags for commit objects are equally useful, especially signed ones:\nthey include a fixed history which can not be changed. Eg. they include\nall the people which attributed code to the project, and this is important\nfor license questions. This is the reason that \"grafting\" should stay\na local workaround.\n\nThat the concrete tag \"linux-2.6.11\" points to a commit, and not to the\ntree object, probably was done on purpose; i.e. the creator of the tag\nwanted to include the history. If not, he could have made the tag for the\ntree object directly.\n\n> Indeed that emphasizes that the history lines are on living on a\n> higher level of abstraction that commits.\n\nHmm.. If you only have tree changes, there is no history. The history\nspecifies an order of the changes. The changes themselve do not include\nany such order.\n\n> Now what if we used \n> trees->tree commits, instead of the current commits->tree ones ?\n\nIt would be better to not talk about \"commits\" for tree changes (perhaps\nwith comments about the change). As said above, tree change objects\ncould be introduced. The question is why?\n\n> The\n> main problem would be to be able to reconstruct those history lines,\n> so that we can still extract the log\n\nNo problem: You still have the chain of commits, and one commit points\nto the parent commit(s) and the corresponding new introduced tree change\nobjects.\n\n> - what's a better model if we \n> loose functionnality ? ;)\n\nThere is nothing lost. If you regard the comments entered at \"git commit\"\ntime as purely change related, this comments can be put together with the\ntree change object. So if you \"apply a graft to a tree\", (signed) tags for tree\nchanges would include the comment, and stay valid after \"regrafting\".\nBut why would anyone want to sign a change?\n\n> However, I must admit that at this point, I have not found a\n> reasonable solution to this problem.\n> \n> Any genius with a solution out there ? :)\n\nWhat is the difficult problem here?\n\nJosef\n"},{"id":"12279","messageId":"Pine.LNX.4.64.0511180915560.13959@g5.osdl.org","threadId":"2584","inReplyTo":"437DDDB1.60103@b-i-t.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-18T17:25:45Z","receivedAt":"2005-11-18T17:25:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 18 Nov 2005, sf wrote:\n> \n> I would go even further: The resulting tree does not depend on anything. A\n> tree is a tree is a tree.\n\nAgreed.\n\n> A commit is really just the statement: \"I changed the tree from state A to\n> state B\". After all, the commit message does not describe the new state\n> (neither the old state) but does describe the changes.\n\nNo.\n\nA commit is _not_ just the statement of change between two trees.\n\nIt's a statement of _history_ of the resulting tree. This is important. \nIt's why a commit does not just point to the previous tree, but to the \nprevious commit(s).\n\nAnd that's really important. If you don't have a history of what has \nhappened, then all the trees are just random collections of files. They're \nnot a project any more.\n\nSo a commit doesn't just say \"tree A changed into tree B\". It very much \nsays something much much stronger, which includes how you got to A in the \nfirst place.\n\nThe history is also what allow a commit to be meaningful. Without that \nhistory, you could never say \"I fixed the bug that was introduced by xyz\", \nwhich is often a very integral part of _why_ the change happened.\n\nThere are lots of changelog entries that don't necessarily make sense \nwithout knowing what went before them, so history is actually important \neven in a local sense - it's often what allows the explanation to make \nsense.\n\n\t\t\tLinus\n"},{"id":"12302","messageId":"7v3bltea1t.fsf@assigned-by-dhcp.cox.net","threadId":"2584","inReplyTo":"Pine.LNX.4.64.0511180915560.13959@g5.osdl.org","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-19T00:49:34Z","receivedAt":"2005-11-19T00:49:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Fri, 18 Nov 2005, sf wrote:\n>> \n>> A commit is really just the statement: \"I changed the tree from state A to\n>> state B\". After all, the commit message does not describe the new state\n>> (neither the old state) but does describe the changes.\n>\n> There are lots of changelog entries that don't necessarily make sense \n> without knowing what went before them, so history is actually important \n> even in a local sense - it's often what allows the explanation to make \n> sense.\n\nI agree with what you said about commit objects and what they\nare meant to describe. At the same time, I am sympathetic if\nsomebody wants to be able to say just \"The change this commit\nbrings in can be used to modify the behaviour X to Y\". An\nimplied prerequisite for such a statement is that you can apply\nsuch a change only to something that has behaviour X, and\ninternally works in a certain way to exhibit that behaviour, to\nbegin with (IOW, otherwise the patch does not apply). While\nyour \"commit describes all the history leading to it\" obviously\nsatisfies that prerequisite, it is stronger than necessary.\n\nFor that matter, \"tree A changed into tree B\" is stronger than\nnecessary as well. There are trees other than tree A that has\nthe same behaviour X, and applying such a change would be valid\nto modify its behaviour to Y.\n\nYou are absolutely right that commit messages should be taken in\nthe context of the history leading to it. However, when we\nexchange patches via e-mail, or do \"rebase\" in the repository,\nwe also use the commit message to label the change -- and with\nthat usage, the log message becomes less about describing the\nhistory and more about \"modifies X to Y\", so it is easy to get\nconfused.\n"},{"id":"12304","messageId":"Pine.LNX.4.64.0511181705390.13959@g5.osdl.org","threadId":"2584","inReplyTo":"7v3bltea1t.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-19T01:07:38Z","receivedAt":"2005-11-19T01:07:38Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 18 Nov 2005, Junio C Hamano wrote:\n>\n> At the same time, I am sympathetic if somebody wants to be able to say \n> just \"The change this commit brings in can be used to modify the \n> behaviour X to Y\".\n\nWell, you can obviously use a commit that way, and indeed, every time we \ndo a \"rebase\", that's effectively saying \"I know the commit has history, \nbut now I want to use it purely as a tree conversion\".\n\nI'm not convinced we ever really _need_ a pure \"tree-to-tree\" thing, \nalthough you can always do that by creating an extra commit with no parent \nand thus no history ;)\n\n\t\tLinus\n"},{"id":"12306","messageId":"7vr79dcu0j.fsf@assigned-by-dhcp.cox.net","threadId":"2584","inReplyTo":"Pine.LNX.4.64.0511181705390.13959@g5.osdl.org","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-19T01:21:16Z","receivedAt":"2005-11-19T01:21:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> I'm not convinced we ever really _need_ a pure \"tree-to-tree\" thing, \n> although you can always do that by creating an extra commit with no parent \n> and thus no history ;)\n\nNah, it is more like a commit object that records its tree and\nanother tree as its parent ;-).\n\nI do not think tree-to-tree thing is very useful and that is\nwhat I meant to say by \"tree-to-tree is still stronger than\nnecessary\".\n\nWhat is recorded as a \"change\" by darcs feels more like \"This\nmakes it to do Y instead of doing X\", and it is not about\ntree-to-tree. I know David Roundy is lurking on this list;\nDavid, do you have any comment on this?\n"},{"id":"12308","messageId":"Pine.LNX.4.64.0511181728160.13959@g5.osdl.org","threadId":"2584","inReplyTo":"7vr79dcu0j.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-19T01:29:27Z","receivedAt":"2005-11-19T01:29:27Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 18 Nov 2005, Junio C Hamano wrote:\n> \n> Nah, it is more like a commit object that records its tree and\n> another tree as its parent ;-).\n\nI don't think fsck would allow that. At least it wasn't _meant_ to allow \nit, and it should complain about an object having the wrong type.\n\nAnd I'd hope that \"git-commit-tree\" would refuse to write such a thing.\n\n\t\tLinus\n"},{"id":"12309","messageId":"20051119013837.GA3393@nowhere.earth","threadId":"2584","inReplyTo":"437DDDB1.60103@b-i-t.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-19T01:38:37Z","receivedAt":"2005-11-19T01:38:37Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Nov 18, 2005 at 02:57:05PM +0100, sf wrote:\n> >Indeed that emphasizes that the history lines are on living on a\n> >higher level of abstraction that commits. Now what if we used\n> >trees->tree commits, instead of the current commits->tree ones ? The\n> >main problem would be to be able to reconstruct those history lines,\n> >so that we can still extract the log - what's a better model if we\n> >loose functionnality ? ;)\n> \n> You can traverse tree -> commit -> tree -> commit -> tree ... to get the \n> history. No functionality lost.\n\nNo, that would require that a tree knows about the commits leading to\nit, which would mix levels of abstraction as well.\n\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"12326","messageId":"20051119131656.GB3393@nowhere.earth","threadId":"2584","inReplyTo":"200511181654.21052.Josef.Weidendorfer@gmx.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-19T13:16:56Z","receivedAt":"2005-11-19T13:16:56Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Nov 18, 2005 at 04:54:20PM +0100, Josef Weidendorfer wrote:\n> On Friday 18 November 2005 00:07, Yann Dirson wrote:\n> > Current commit objects refer to a child tree, but to parent _commits_.\n> > Whereas it seems necessary to walk through the history line, and\n> > easily get a changelog, it is semantically quite not right: the\n> > changes we record with a commit indeed come from modification of\n> > trees, not of commits.\n> \n> Yes. The change to a tree (which is equalent to 2 trees - new old and\n> the new one; or for merges multiple old ones and the new one) does not\n> depend on any history. Unfortunately, we have no separate object to\n> specify the \"the change to a tree\". We include this information into\n> the commit object, and thus, bind it to the history.\n> \n> This could be changed in git, i.e. put the tree relationship into a\n> separate object; even comments could be split up in change related and\n> history related. The question is: is this useful, is there any\n> important usage scenario that rectifies such a change?\n\nThe scenario I have it mind is \"archeological work\" - see my post\nunder \"info/grafts file\" for details. With luck for future work\nvendors will switch to git and give access to their git history (or\nuse quilt or stgit and provide detailed patch stacks), so the need\ncould well disappear, but I would not could on it, as there are still\nmany firms working on a 2.4 base and only exporting monolithic\npatches.\n\n\n> > That is, the resulting tree does not depend on \n> > the history of the parent trees, but on the parent trees themselves.\n> \n> No, the resulting tree is an independent object, it is the tree ;-)\n> Do not confuse this with the commit pointing to the tree.\n\nRight, that was a wrong wording. I meant the resulting tree results\nfrom the change and and the parent trees themselves, not from the\nchange and the previous history.\n\n\n> But tags for commit objects are equally useful, especially signed ones:\n> they include a fixed history which can not be changed. Eg. they include\n> all the people which attributed code to the project, and this is important\n> for license questions. This is the reason that \"grafting\" should stay\n> a local workaround.\n\nThis, and chaining commits is also useful to prevent loops, as said in\nanother part of this thread. But I wouldn't let such considerations\nstop exploration first. If we cannot find a reasonable and useful way\nof applying those ideas without taking these 2 points into account as\na first approximation, there would be no point in adding these 2\nconstraints right away :). It can be sufficient for now to be aware\nof those and add them later.\n\n\n> > Indeed that emphasizes that the history lines are on living on a\n> > higher level of abstraction that commits.\n> \n> Hmm.. If you only have tree changes, there is no history. The history\n> specifies an order of the changes. The changes themselve do not include\n> any such order.\n\nRight, but that does not mean we cannot reconstruct history from those\nchanges. It came to my mind during the last day, that if we had\ncommits only reference trees, we could construct from them the\nequivalent of today's commit objects (which I'll call \"history\nobjects\" for clarity), but we could look at those generated \"history\nobjects\" as \"cached\" objects. Together with a cache of tree->commit\nreverse-mapping objects as Stephan mentionned, we could generate them\non-the-fly at commit time.\n\nRemember that in a first approach, I'll only consider those history\nobjects as a means to get a history log or similar.\n\nThat would give us low-intrusion grafts: we can regenerate the\nrelevant part of the \"history object\" cache when a commit gets added\nor replaced, similarly to what would be done at commit-creation time.\nBut we would not need to regenerate all subsequent commit objects, so\nthat all refs/tags pointing to those subsequent commits would not need\nto be messed with.\n\nSince we would then have history objects looking like current commits,\nwe could even get a similar safeguard against history loops.\n\n\nAnd if we want to get the \"signed tag certifies history\" stuff, we\ncould envision making some of these history objects permanent. But if\nwe allow history object to refer to tree parents as well, we do not\n_need_to_ certify on every such tag the entire history plus changes\nsince the previous tag: a chain of \"history objects\" could stop on a\ntree, thus making the tag a certificate of an incremental patch (ie,\nwhat we get from signed patches in pub/linux/kernel, with the added\nbonus of signing the invididual bits making up this patch).\n\n\n> > However, I must admit that at this point, I have not found a\n> > reasonable solution to this problem.\n> > \n> > Any genius with a solution out there ? :)\n> \n> What is the difficult problem here?\n\nGetting a pure superset of the functionnality we currently have (while\nnot impairing git use in term of computing time). But finally that\nmay not be as hard as I expected :)\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"12327","messageId":"20051119132720.GC3393@nowhere.earth","threadId":"2584","inReplyTo":"7vr79dcu0j.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-19T13:27:20Z","receivedAt":"2005-11-19T13:27:20Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Nov 18, 2005 at 05:21:16PM -0800, Junio C Hamano wrote:\n> I do not think tree-to-tree thing is very useful and that is\n> what I meant to say by \"tree-to-tree is still stronger than\n> necessary\".\n> \n> What is recorded as a \"change\" by darcs feels more like \"This\n> makes it to do Y instead of doing X\", and it is not about\n> tree-to-tree.\n\nI'm not sure we could go that path. I see git and darcs as quite\nopposed in approach, since darcs works by explicitely describing the\nstructure of changes, whereas git allows to use arbitrary ways to\nderive this structure from the trees.\n\nBut then if we could reconcile those 2 approaches...\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"12330","messageId":"20051119140404.GD3393@nowhere.earth","threadId":"2584","inReplyTo":"Pine.LNX.4.63.0511180026080.18775@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-19T14:04:05Z","receivedAt":"2005-11-19T14:04:05Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Fri, Nov 18, 2005 at 12:28:56AM +0100, Johannes Schindelin wrote:\n> On Fri, 18 Nov 2005, Yann Dirson wrote:\n> \n> > Current commit objects refer to a child tree, but to parent _commits_.\n> > Whereas it seems necessary to walk through the history line, and\n> > easily get a changelog, it is semantically quite not right:\n> \n> Yes, it is. You base *your* work on *some* work. So, even if the trees may \n> be equal, the base isn't.\n\nHm, I'm not sure I get your point here.\n\n> > Indeed that emphasizes that the history lines are on living on a\n> > higher level of abstraction that commits. Now what if we used\n> > trees->tree commits, instead of the current commits->tree ones ?\n> \n> Now, how exactly would that be more abstract? Trees are just that: \n> collections of files. Noone tells you what the idea was, which led from \n> the last tree(s) to this one. That is not abstract.\n\nTrees have an existence outside any consideration of what changes led\nto them, as shown by the fact that git trees do not reference anything\noutside them. And it is right that, at that level, noone tells you\nhow you got there - not less nor more than when you fetch a\nlinux-x.y.z.tar.gz2 from kernel.org.\n\nThen at a bit higher level, you can consider changes from a tree to a\ntree. What you usually do when you commit a change is explaining what\nyou change to the tree. Then changes themselves are just derived from\nthe trees (iow, \"abstracted from\" the trees), and you augment this\ninformation with a message explaining what you did.\n\nThen at a still higher level, you can derive history lines from the\nindividual trees and changes, and augment this information, eg. by\nsigning them.\n\n\nThe fact is, currently git does not distinguish much between those 2nd\nand 3rd levels. It is my understanding that one of the most basic\ndesign decisions of git was precisely to make the tool \"aware\" of the\n1st level, and that it played an important part of why git works so\nwell: it maps to the reality closer than any other tool.\n\nI was not convinced at all by the ideas when git appeared, but that\nwas probably because I was too much influenced by previous tools, all\nfocussing either on the history line (most of them), or on the changes\n(darcs).\n\nI think that if we can formalize into git the disctinction between\nthose two higher levels (and possibly other levels in the future), we\ncould get to an even more powerful and usable tool, even if, like git,\nthe basic ideas may look weird and possibly even counter-productive at\nfirst sight.\n\n\nAs an example, here is an idea I had while formalizing the above 3rd\nlevel: we also work at this level when rolling back a previous change,\nsince we take the history line into account. We could add, at that\nHistory level, the possiblity to record this information, by linking\nto that previous commit.\n\nNow maybe I was mistaken in thinking the objects at the History level\nshould be only \"cached\" and temporary objects - that, and loop\nprevention, and signed history lines, make too many reasons for them\nto be permanent already :).\n\nBut their existence as such should not prevent to work at a lower\nlevel. I'll have to reconsider the way I intended to design my\nArcheoloGIT toolkit, but I'm afraid it would need a new generation of\nGIT ;)\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"12331","messageId":"20051119141341.GE3393@nowhere.earth","threadId":"2584","inReplyTo":"20051119140404.GD3393@nowhere.earth","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-19T14:13:41Z","receivedAt":"2005-11-19T14:13:41Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sat, Nov 19, 2005 at 03:04:05PM +0100, Yann Dirson wrote:\n> Trees have an existence outside any consideration of what changes led\n> to them, as shown by the fact that git trees do not reference anything\n> outside them. And it is right that, at that level, noone tells you\n> how you got there - not less nor more than when you fetch a\n> linux-x.y.z.tar.gz2 from kernel.org.\n> \n> Then at a bit higher level, you can consider changes from a tree to a\n> tree. What you usually do when you commit a change is explaining what\n> you change to the tree. Then changes themselves are just derived from\n> the trees (iow, \"abstracted from\" the trees), and you augment this\n> information with a message explaining what you did.\n> \n> Then at a still higher level, you can derive history lines from the\n> individual trees and changes, and augment this information, eg. by\n> signing them.\n\nIOW,\n- 1st level describes states that existed\n- 2nd level describes events that occured, causing the state to change\n- 3rd level describes the succession of events\n\nand for the record, I am likely to introduce with ArcheoloGIT a 4th\nlevel, which will describe how our idea of history evolves over time.\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"12332","messageId":"Pine.LNX.4.63.0511191612350.4895@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2584","inReplyTo":"20051119141341.GE3393@nowhere.earth","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-19T15:27:12Z","receivedAt":"2005-11-19T15:27:12Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 19 Nov 2005, Yann Dirson wrote:\n\n> - 1st level describes states that existed\n> - 2nd level describes events that occured, causing the state to change\n> - 3rd level describes the succession of events\n\nBut using git's approach you have these levels. Only that you do not \nstrictly record them as such:\n\n\t- 1st level is trees, agreed.\n\n\t- 2nd level is inside the commits, i.e. if you look at the tree(s)\n\t of the parent commit(s), you can extract that tree->tree change.\n\n\t- 3rd level is not just the succession of events: commit->commit\n\t is much stronger.\n\nBy the last, I mean that in the commit, by referencing the parent(s) \n(which itself references its parent(s)) you have the whole history. And by \nvalidating the commit object by its SHA1, you have the history immutable, \ntoo.\n\nNow, the original purpose of this thread was to discuss a way to un-graft \nsome commit objects, i.e. to re-record a history which was not recorded as \nsuch.\n\nThis may be nice for completeness purposes, but it contradicts the main \nidea behind git: You want to be certain about things. By signing off on \nsome commit (together with the meta information about its parent(s) and \nthe tree), you state that you actually placed your work on *that* \nparticular history. And if you based your work on a commit I have, I can \nbe certain that we agree.\n\nThe proposed rewriting of the history is very lax about that:\n\nSay, you introduce a history line, where you start with -- say -- some \nobsolete proprietary code from some telephone company, and then change -- \nsay, by a primitive algorithm -- the code to match git-0.99.8, all the \ntime committing with some random commit message.\n\nThen you make a graft which says git-0.99.8 was derived from that history \n, too. Now, you ungraft the tree. It looks like other developers and I \nsigned off on working on a \"derivative\" of some obscure, copyrighted code.\n\nNice?\n\nHth,\nDscho\n"},{"id":"12333","messageId":"20051119170929.GF3393@nowhere.earth","threadId":"2584","inReplyTo":"Pine.LNX.4.63.0511191612350.4895@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-19T17:09:29Z","receivedAt":"2005-11-19T17:09:29Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"Hi,\n\nOn Sat, Nov 19, 2005 at 04:27:12PM +0100, Johannes Schindelin wrote:\n> On Sat, 19 Nov 2005, Yann Dirson wrote:\n> > - 1st level describes states that existed\n> > - 2nd level describes events that occured, causing the state to change\n> > - 3rd level describes the succession of events\n> \n> But using git's approach you have these levels. Only that you do not \n> strictly record them as such:\n> \n> \t- 1st level is trees, agreed.\n> \n> \t- 2nd level is inside the commits, i.e. if you look at the tree(s)\n> \t of the parent commit(s), you can extract that tree->tree change.\n> \n> \t- 3rd level is not just the succession of events: commit->commit\n> \t is much stronger.\n\nI think we do agree on this too - it's just the usual problem with\nwritten discussions.\n\n> By the last, I mean that in the commit, by referencing the parent(s) \n> (which itself references its parent(s)) you have the whole history. And by \n> validating the commit object by its SHA1, you have the history immutable, \n> too.\n\nRight. But the 2nd and 3rd levels are not currently distinct in git.\nSee below.\n\n\n> Now, the original purpose of this thread was to discuss a way to un-graft \n> some commit objects, i.e. to re-record a history which was not recorded as \n> such.\n> \n> This may be nice for completeness purposes, but it contradicts the main \n> idea behind git: You want to be certain about things. By signing off on \n> some commit (together with the meta information about its parent(s) and \n> the tree), you state that you actually placed your work on *that* \n> particular history. And if you based your work on a commit I have, I can \n> be certain that we agree.\n\nMy proposal only introduces an additional level. You will still be\nable to sign history lines, and they will still be immutable.\n\nThis proposal is only meant to add some flexibility. With the current\nmodel, if I take Linus' 2.6 tree, I only have the 2.6 history back to\n2.6.12rc2. I would first like to note that any signed commit in this\ntree can assert nothing prior to that version: we are only able to\ncheck part of the history.\n\nNow let's suppose that I am interested in adding some prior history,\nsay 2.6.11->2.6.12rc2. I can add the tree and commit objects for that\nrange, and I now want to graft to current tree. That is, I will add a\nnew history line, which will have to duplicate all subsequent commits\nfrom the current tree. That includes for example duplicating\ncomments, whereas in my model they would belong to the level below,\nand would not need duplicating: the new history line will just\nreference the lower-level commits, which do contain\ncomment/date/author information. The history-level objects will\nprobably just need to contain the following information:\n\n- commit to describe\n- previous history\n- history commiter, which may be distinct from the commiter of the\n change\n- date of the record of the history object, which will be distinct\n from the commit date, except usually for the history line on which\n the change author works\n\nWe can then note that:\n\n- to provide the same level of information with current objects, the\ncommits on the new history line would have to also point to their\ncounterpart in the original history line, adding information that\nbelongs to the 4th level (how our view of history evolves with time)\n\n- the number of history objects could be made much less than the\nnumber of commits, by using a single one to describe the full path\nbetween two branchpoints of that history line:\n\nparent: xxxxxx\nparent: yyyyyy\ncommit: zzzzzz\ncommit: aaaaaa\ncommit: bbbbbb\ncommitter: ...\ndate: ...\n\n> The proposed rewriting of the history is very lax about that:\n> \n> Say, you introduce a history line, where you start with -- say -- some \n> obsolete proprietary code from some telephone company, and then change -- \n> say, by a primitive algorithm -- the code to match git-0.99.8, all the \n> time committing with some random commit message.\n> \n> Then you make a graft which says git-0.99.8 was derived from that history \n> , too. Now, you ungraft the tree. It looks like other developers and I \n> signed off on working on a \"derivative\" of some obscure, copyrighted code.\n\nNo, the grafted commits should not be accessible from a\npreviously-signed history line. The operation you describe will\nproduce a different history line, and I can already do the same with\ngit now :)\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"12334","messageId":"pan.2005.11.19.17.23.17.920228@smurf.noris.de","threadId":"2584","inReplyTo":"20051119170929.GF3393@nowhere.earth","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-11-19T17:23:20Z","receivedAt":"2005-11-19T17:23:20Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Yann Dirson wrote:\n\n> But the 2nd and 3rd levels are not currently distinct in git.\n\nI don't think you *can* make them distinct. Sure, you could introduce \n\"change\" object which refers to a couple of source trees and a destination\ntree, and then create a \"history\" object which links previous history and\na change, but what's the point? What can you do with such a thing\nthat you cannot do now, just as easily, besides slow down your programs\nwith an unnecessary level of indirection?\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\n\"To those who wish to punish others--or at least to see them punished, if\n the avengers are too cowardly to take matters in to their own hands-- the\n belief in a fiery, hideous hell appears to be a great source of comfort.\"\n [Steve Allen, \"Steve Allen, on\n the Bible Religion & Morality\"]\n"},{"id":"12352","messageId":"Pine.LNX.4.63.0511200217200.11653@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2584","inReplyTo":"pan.2005.11.19.17.23.17.920228@smurf.noris.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-20T01:24:53Z","receivedAt":"2005-11-20T01:24:53Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 19 Nov 2005, Matthias Urlichs wrote:\n\n> [...] What can you do with such a thing that you cannot do now, just as \n> easily, besides slow down your programs with an unnecessary level of \n> indirection?\n\nI tend to agree. In fact, if I would like to introduce earlier history \n(for the sake of archeology or whatever), I would import the earlier \nhistory into git, possibly finding the best match in the current \ndevelopment branch (for example, when the original project continued for a \nwhile to be tracked in CVS), and then make a merge between these two.\n\nThen, I'd merge the new development's HEAD, and it would be fine:\n\nORIG1 .. ORIG2 .. .. ORIG_HEAD\n |\n | GIT1 .. GIT2 .. .. GIT_HEAD\n | / /\n | / /\n UNIFYING_MERGE /\n \\ /\n \\ /\n NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES\n\nWhere ORIG_HEAD's tree is identical with GIT1's tree. The resulting branch \nwould serve every research purpose I can think of (just be sure not to \nuse \"-m\" with git-whatchanged).\n\nCiao,\nDscho\n"},{"id":"12363","messageId":"20051120073244.GA7902@kiste.smurf.noris.de","threadId":"2584","inReplyTo":"Pine.LNX.4.63.0511200217200.11653@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-11-20T07:32:44Z","receivedAt":"2005-11-20T07:32:44Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n\nJohannes Schindelin:\n> Then, I'd merge the new development's HEAD, and it would be fine:\n> \nWhy not simply use info/grafts?\n\nORIG1 .. ORIG2 .. .. ORIG_HEAD\n \\\\\n GIT1 .. GIT2 .. .. GIT_HEAD\n\nwhere the \\\\ link is the graft entry.\n\nIf we want (need, these days -- the history is so long that gitk draws\nspurious lines becase of 16-bit window coordinate overflow) to chop off\nhistory at some point, we can use the newfangled date parser + config\nfile stuff to set a sane default.\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nJuly 4. Statistics show that we loose more fools on this day than in all the\nother days of the year put together. This proves, by the number left in stock,\nthat one Fourth of July per year is now inadequate, the country has grown so.\n"},{"id":"12369","messageId":"Pine.LNX.4.63.0511201242210.27791@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2584","inReplyTo":"20051120073244.GA7902@kiste.smurf.noris.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-20T11:44:28Z","receivedAt":"2005-11-20T11:44:28Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 20 Nov 2005, Matthias Urlichs wrote:\n\n> Why not simply use info/grafts?\n\n'Cause you can't fetch a graft. But I agree, instead of telling somebody: \n\"I have this new branch which unifies history\", you can send your friend a \noneliner which appends a graft.\n\nCiao,\nDscho\n"},{"id":"12396","messageId":"20051120223249.GI3393@nowhere.earth","threadId":"2584","inReplyTo":"Pine.LNX.4.63.0511200217200.11653@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-20T22:32:49Z","receivedAt":"2005-11-20T22:32:49Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, Nov 20, 2005 at 02:24:53AM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Sat, 19 Nov 2005, Matthias Urlichs wrote:\n> \n> > [...] What can you do with such a thing that you cannot do now, just as \n> > easily, besides slow down your programs with an unnecessary level of \n> > indirection?\n> \n> I tend to agree. In fact, if I would like to introduce earlier history \n> (for the sake of archeology or whatever), I would import the earlier \n> history into git, possibly finding the best match in the current \n> development branch (for example, when the original project continued for a \n> while to be tracked in CVS), and then make a merge between these two.\n> \n> Then, I'd merge the new development's HEAD, and it would be fine:\n> \n> ORIG1 .. ORIG2 .. .. ORIG_HEAD\n> |\n> | GIT1 .. GIT2 .. .. GIT_HEAD\n> | / /\n> | / /\n> UNIFYING_MERGE /\n> \\ /\n> \\ /\n> NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES\n> \n> Where ORIG_HEAD's tree is identical with GIT1's tree. The resulting branch \n> would serve every research purpose I can think of (just be sure not to \n> use \"-m\" with git-whatchanged).\n\nNote: it's not only about research (ie. something that would be static\nfor browsing only), it's also about using the results of the research\nin further developement.\n\nWell, no doubt this approach can be used in many cases. But it makes\nIMHO the history somewhat confusing, and has limitations. Let's say I\nhad a patch against ORIG2, and at a later date I find a successor for\nit, based on GIT2. I would not have an incarnation of GIT2 with ORIG2\nas ancestor: to be on the safe side I would have had to duplicate the\nwhole GIT1..* history.\n\nAnd after I have done some work on my branch of duplicate commits, if\nI used the type of unifying merges you suggest, I'm stuck forever with\nthe old GIT1..GIT_HEAD line, whether I need it or not (if it comes\nfrom import of 2.4 patches, and thus has no signed tags whatsoever, I\ndo not need it any more).\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"12397","messageId":"20051120223503.GJ3393@nowhere.earth","threadId":"2584","inReplyTo":"Pine.LNX.4.63.0511201242210.27791@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-20T22:35:03Z","receivedAt":"2005-11-20T22:35:03Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Sun, Nov 20, 2005 at 12:44:28PM +0100, Johannes Schindelin wrote:\n> On Sun, 20 Nov 2005, Matthias Urlichs wrote:\n> \n> > Why not simply use info/grafts?\n> \n> 'Cause you can't fetch a graft. But I agree, instead of telling somebody: \n> \"I have this new branch which unifies history\", you can send your friend a \n> oneliner which appends a graft.\n\nIt can also be useful to work with grafts locally, and then use a\nscript to convert the grafted tree into real commits.\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"12402","messageId":"Pine.LNX.4.63.0511210041370.24681@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"2584","inReplyTo":"20051120223249.GI3393@nowhere.earth","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-11-20T23:46:50Z","receivedAt":"2005-11-20T23:46:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 20 Nov 2005, Yann Dirson wrote:\n\n> On Sun, Nov 20, 2005 at 02:24:53AM +0100, Johannes Schindelin wrote:\n> > \n> > ORIG1 .. ORIG2 .. .. ORIG_HEAD\n> > |\n> > | GIT1 .. GIT2 .. .. GIT_HEAD\n> > | / /\n> > | / /\n> > UNIFYING_MERGE /\n> > \\ /\n> > \\ /\n> > NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES\n> > \n> Note: it's not only about research (ie. something that would be static\n> for browsing only), it's also about using the results of the research\n> in further developement.\n\nThen you could base your future development on \nNEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES.\n\n> Well, no doubt this approach can be used in many cases. But it makes\n> IMHO the history somewhat confusing, and has limitations. Let's say I\n> had a patch against ORIG2, and at a later date I find a successor for\n> it, based on GIT2. I would not have an incarnation of GIT2 with ORIG2\n> as ancestor: to be on the safe side I would have had to duplicate the\n> whole GIT1..* history.\n\nYou could still branch from GIT2, cherry picking from the patch to ORIG2, \nand then committing the successor based on GIT2, thus reinstating the \nhypothetical history.\n\nNote: the history may be confusing, but ask any history teacher: history \n*is* confusing! It is all about people. If you want to make it less \nconfusing, I am afraid you have to leave the path of true history.\n\n> And after I have done some work on my branch of duplicate commits, if\n> I used the type of unifying merges you suggest, I'm stuck forever with\n> the old GIT1..GIT_HEAD line, whether I need it or not (if it comes\n> from import of 2.4 patches, and thus has no signed tags whatsoever, I\n> do not need it any more).\n\nBut the GIT1..GIT_HEAD line was actually the correct history! Remember: He \nwho forgets his past is doomed to repeat his mistakes! Don't pretend that \nthe past was different than it was. It's not worth the hassle.\n\nCiao,\nDscho\n"},{"id":"12407","messageId":"20051121022428.GB7902@kiste.smurf.noris.de","threadId":"2584","inReplyTo":"Pine.LNX.4.63.0511210041370.24681@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-11-21T02:24:28Z","receivedAt":"2005-11-21T02:24:28Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n\nJohannes Schindelin:\n> > > ORIG1 .. ORIG2 .. .. ORIG_HEAD\n> > > |\n> > > | GIT1 .. GIT2 .. .. GIT_HEAD\n> > > | / /\n> > > | / /\n> > > UNIFYING_MERGE /\n> > > \\ /\n> > > \\ /\n> > > NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES\n> > > \n> > Note: it's not only about research (ie. something that would be static\n> > for browsing only), it's also about using the results of the research\n> > in further developement.\n> \n> Then you could base your future development on \n> NEW_HEAD_FOR_ARCHEOLOGICAL_PURPOSES.\n> \nIf you need a new HEAD *anyway*, then re-basing your trees would\nIMHO be a better solution.\n\nORIG1 .. ORIG2 .. .. ORIG_HEAD\n |\n | GIT1 .. GIT2 .. .. GIT_HEAD\n | // // // \\\n | // // // TAG\n NEWGIT1 .. GIT2 .. .. NEW_HEAD\n \\\n NEW_TAG\n\nThose // links might be real parent pointers, which allows you to keep \nyour old tags -- or not, which allows you to have a sane history. The\ngood part is that you can do this incrementally, so you won't need a\nflag day.\n\nI seriously doubt that all of this is worth the effort, given that you\ncan do the same thing with a graft line... and most people could care\nless whether their histor starts at 2.6.11-whatever, 2.4, or 0.11.\n(*Has* anybody imported the old tarballs into git, by the way?)\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nlately waking up i'm not sure where i've been\n\t\t-- Indigo Girls, \"Language or the Kiss\"\n"},{"id":"12413","messageId":"43815894.20602@michonline.com","threadId":"2584","inReplyTo":"20051121022428.GB7902@kiste.smurf.noris.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-11-21T05:18:12Z","receivedAt":"2005-11-21T05:18:12Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"Matthias Urlichs wrote:\n\n> If you need a new HEAD *anyway*, then re-basing your trees would\n> IMHO be a better solution.\n> \n> ORIG1 .. ORIG2 .. .. ORIG_HEAD\n> |\n> | GIT1 .. GIT2 .. .. GIT_HEAD\n> | // // // \\\n> | // // // TAG\n> NEWGIT1 .. GIT2 .. .. NEW_HEAD\n> \\\n> NEW_TAG\n> \n> Those // links might be real parent pointers, which allows you to keep \n> your old tags -- or not, which allows you to have a sane history. The\n> good part is that you can do this incrementally, so you won't need a\n> flag day.\n\nThis is exactly what the script I started this thread with does. It\nwould be mostly useful if someone had serious development work based of\nan old, out-of-git branch, and wanted to use the git merging tools to\nget it merged into something based against the current development.\n\nI would expect that they would then want to rebase it or do something\nelse to clean up the mess that is created, and apply it directly to the\ncurrent development tree, rather than leaving it as part of that very\nmessy tree.\n\nMy other goal was to provide myself (and others) an example of using the\nbarebones core tools for some strange tasks that no *real* porcelain\nwould ever find useful.\n\n\n"},{"id":"12489","messageId":"20051121223000.GK3393@nowhere.earth","threadId":"2584","inReplyTo":"20051121022428.GB7902@kiste.smurf.noris.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2005-11-21T22:30:00Z","receivedAt":"2005-11-21T22:30:00Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Mon, Nov 21, 2005 at 03:24:28AM +0100, Matthias Urlichs wrote:\n> If you need a new HEAD *anyway*, then re-basing your trees would\n> IMHO be a better solution.\n\nHell, that does look like a nice solution using current git - thanks.\nI'll have to dig into that, and I'll come back if/when I hit its\nlimits too hard ;)\n\n\n> I seriously doubt that all of this is worth the effort, given that you\n> can do the same thing with a graft line...\n\nWell, unfortunately there is still some things to get ironed out\nbefore we have grafts propagated without yet another wrapper - which\nends up with them being still really private at that time.\n\nBut then, grafts may povide an inexpensive scratch space, which could\nthen be carved into rebased objects when the historian gets happy with\nhis work.\n\n\n> and most people could care\n> less whether their histor starts at 2.6.11-whatever, 2.4, or 0.11.\n\nRight ! But then someone will occasionally want to use a release\nbefore the start of his history, and it would be a shame to force full\nkernel history on all poor developers who only need fresh-enough code.\n\nBut I still think we could reconcile those 2 approaches, if we would\nallow partial history lines (ie, signing eg. commit chain from 2.6.n\nto 2.6.(n+1), with the initial commit starting on a tree and not a\nfaked \"commit from nil\").\n\nThis would indeed a generalisation of what we have, since we only have\na signed chain of commits from 2.6.12rc2 in the official repo - and\nmaybe one more ancient from bk history. It would even formally\nacknowledge that we do not have the whole of the real history, and it\nwould leave the Unknown to be well-delimited, for any explorers who\nwould want to rebuild it, in case it would have any value, IP-wise.\n\nAnd, more practically, where will the current kernel repo be when its\nsize will be 100 or 10000 times its current size ? That would allow\nto split it without too many problems.\n\nBest regards,\n-- \nYann Dirson |\nDebian-related: | Support Debian GNU/Linux:\n | Freedom, Power, Stability, Gratis\n http://ydirson.free.fr/ | Check \n"},{"id":"12593","messageId":"17283.57854.256145.253465@cargo.ozlabs.ibm.com","threadId":"2584","inReplyTo":"20051120073244.GA7902@kiste.smurf.noris.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Paul Mackerras","fromEmail":"paulus@samba.org","sentAt":"2005-11-23T03:29:02Z","receivedAt":"2005-11-23T03:29:02Z","isPatch":false,"sender":{"key":"paulus@samba.org","avatar":"https://avatars.githubusercontent.com/u/1606439?v=4"},"body":"Matthias Urlichs writes:\n\n> If we want (need, these days -- the history is so long that gitk draws\n> spurious lines becase of 16-bit window coordinate overflow) to chop off\n\nI have it on good authority that canvas coordinates in Tcl/Tk are\n*not* limited to 16 bits. The Tcl/Tk core developers acknowledged\nthat there might be a bug in the code that translates canvas\ncoordinates to X coordinates (which are 16 bit), and asked me for a\nscreenshot or repro-case to illustrate the problem.\n\nHowever, I was unable to get current gitk to exhibit the problem, even\nwith Thomas Gleixner's enormous history.git repository. Do you have a\nspecific example (repository and commit ID) where you see the problem\noccur?\n\nPaul.\n"},{"id":"12599","messageId":"20051123072738.GI20960@kiste.smurf.noris.de","threadId":"2584","inReplyTo":"17283.57854.256145.253465@cargo.ozlabs.ibm.com","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-11-23T07:27:40Z","receivedAt":"2005-11-23T07:27:40Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n\nPaul Mackerras:\n> However, I was unable to get current gitk to exhibit the problem, even\n> with Thomas Gleixner's enormous history.git repository. Do you have a\n> specific example (repository and commit ID) where you see the problem\n> occur?\n> \nI've seen it in the past ... hmmm ... testing ... and it seems to\nmajickally have fixed itself.\n\nOh well...\n\n-- \nMatthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\nThe Tenth Commandment of Frisbee: The single most difficult move with a disc\nis to put it down. (Just one more.)\n\t\t\t\t\t-- Dan Roddick\n"},{"id":"12627","messageId":"Pine.LNX.4.64.0511230913360.13959@g5.osdl.org","threadId":"2584","inReplyTo":"20051123072738.GI20960@kiste.smurf.noris.de","subject":"Re: [RFC] Applying a graft to a tree and \"rippling\" the changes through","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-11-23T17:14:04Z","receivedAt":"2005-11-23T17:14:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 23 Nov 2005, Matthias Urlichs wrote:\n\n> Hi,\n> \n> Paul Mackerras:\n> > However, I was unable to get current gitk to exhibit the problem, even\n> > with Thomas Gleixner's enormous history.git repository. Do you have a\n> > specific example (repository and commit ID) where you see the problem\n> > occur?\n> > \n> I've seen it in the past ... hmmm ... testing ... and it seems to\n> majickally have fixed itself.\n\nI saw it all the time before adding the \"arrows\" logic. \n\nWith the arrows, the graph never gets so complex that you'd see it.\n\n\t\tLinus\n"}]}