{"thread":{"id":"3779","subject":"n-heads and patch dependency chains","startedAt":"2006-04-03T07:48:34Z","lastAt":"2006-04-21T08:50:44Z","messageCount":21,"participants":["Sam Vilain","Linus Torvalds","Junio C Hamano","Jakub Narebski","Andreas Ericsson","Catalin Marinas","Jon Loeliger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"18269","messageId":"4430D352.4010707@vilain.net","threadId":"3779","inReplyTo":null,"subject":"n-heads and patch dependency chains","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-04-03T07:48:34Z","receivedAt":"2006-04-03T07:48:34Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Hi all,\n\n\"Patch dependency chains\", the best plain-English term we could find for\nthe scary sounding darcs term \"patch calculus\", are said by some to be a\nvery good reason to use a system like darcs, even to some its\nfundamental advantage over systems such as git.\n\nThe question is, to what extent is this point true?\n\nTo get a feel for the issues involved, I tried applying an example\nn-head and patch dependency logic to a \"real\" project that had a small\nenough number of commits to make it feasible to construct everything\nmanually.\n\nA side-by-side comparison of the commit history with n-head commits\n(left pane) and without (right pane) is here:\n\n  http://utsl.gen.nz/git/hydra-vs-regular.png\n\nSome important points to note:\n\n  0. gitk is re-ordering the commits to try to make the graph tidy,\n     so don't worry that the commits are in a different order\n\n  1. commits were considered dependent on the last commit(s) that\n     delivered the file(s) they modified.  As in, the user specified\n     that extra heads be created wherever possible, including\n     splitting heads.\n\n  2. the \"rolling\" n-head was continually discarded.  \"n-head\" is\n     misspelt :) as \"hydra-head\" in the diagrams.\n\n  3. patches that just added new files were performed by first\n     making a new repository, adding those files and committing.\n     this is why there are a lot of \"starting points\" on the tree\n\nI think we can conclude from this:\n\n  - this is not impossible using the current model, and some extra\n    useful information can be seen in the tree that shows more real\n    dependency information and relationships between individual commits\n\n  - doing automatic n-head creation would probably be madness, as\n    far too many useless heads are created (though it is almost\n    guaranteed that supporting 'patch commuting' a la darcs would\n    make this *even worse* as it would mean that you could potentially\n    have even more heads)\n\n  - the current tools make this style of development difficult.\n\nThe bugs:\n\n  - git-merge-octopus isn't capable of merging commits where there is\n    no common commit, but none was needed as the commits' trees don't\n    overlap.\n\n    That is, with \"git-pull -s octopus . head1 head2 head3 ...\"\n    you get the error:\n\n      Unable to find common commit with 42f49cc...\n\n    But pulling the branches individually works fine;\n\n      Merging HEAD with 42f49cc...\n      Merging:\n        c0805...\n        42f49...\n      found 1 common ancestor(s):\n      1 virtual commit\n\n    That 'branch' was created by setting up a new git repo in another\n    path, then using 'git-fetch' to pull it into the local one.\n\n  - for some reason I had to list \"-s ours\" twice to git-pull when\n    manually making the octopus merge nodes\n\n  - `git-pull --no-commit -a' suffers from the same problem\n\n  - some tools (such as the diff window in gitk) produce *very*\n    strange output if you try to merge the heads and apply the next\n    patch in the same go.\n\nThe open questions:\n\n  - would it make a difference if this automatic patch dependency\n    information was stored using a different type of relationship?\n\n  - would this be more useful if the initial n-head creation was more\n    manual, like topic branches?  And if it did work like this, would\n    an n-head pull feature enable the 'pu' development model to work\n    seamlessly?\n\n  - how useful are the other benefits of dependent commits?\n\nThe IRC log:\n\n17:45 < mugwump> the other suggestions look quite good.  I don't know\n                 how I got roped into spending a whole day on this :)\n17:46 < mugwump> oh yeah, I remember now.  somebody asked for a\n                 comparison between darcs and git\n17:46  * ShadeHawk whistles innocently\n\nSo there we go, anyway.  If some form of patch dependency system is to\nbe included in git, then I hope this message helps to explain the\npractical problems and give the would-be author a good head start :)\n\nHot potato into the aether, anyone?\n\nSam.\n"},{"id":"18282","messageId":"Pine.LNX.4.64.0604030727250.3781@g5.osdl.org","threadId":"3779","inReplyTo":"4430D352.4010707@vilain.net","subject":"Re: n-heads and patch dependency chains","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-04-03T14:29:18Z","receivedAt":"2006-04-03T14:29:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 3 Apr 2006, Sam Vilain wrote:\n> \n> \"Patch dependency chains\", the best plain-English term we could find for\n> the scary sounding darcs term \"patch calculus\", are said by some to be a\n> very good reason to use a system like darcs, even to some its\n> fundamental advantage over systems such as git.\n\nI really think that darcs is just \"nice theory\", and has nothing to do \nwith real life.\n\nTerms like \"patch calculus\" may sound cool and useful, but let's face it, \nthe proof is in the pudding, and quite frankly, I would bet that trying to \ndo something like that on a real project would just be a total disaster.\n\nI want my merges simple. I want them to take a couple of seconds. I don't \nwant to see strange patch dependencies that nobody cares about. And I very \nmuch don't want to see theory over practice.\n\n\t\tLinus\n"},{"id":"18290","messageId":"1144078720.15809.49.camel@localhost.localdomain","threadId":"3779","inReplyTo":"Pine.LNX.4.64.0604030727250.3781@g5.osdl.org","subject":"Re: n-heads and patch dependency chains","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-04-03T15:38:40Z","receivedAt":"2006-04-03T15:38:40Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Mon, 2006-04-03 at 07:29 -0700, Linus Torvalds wrote:\n> I really think that darcs is just \"nice theory\", and has nothing to do \n> with real life.\n> \n> Terms like \"patch calculus\" may sound cool and useful, but let's face it, \n> the proof is in the pudding, and quite frankly, I would bet that trying to \n> do something like that on a real project would just be a total disaster.\n>\n> I want my merges simple. I want them to take a couple of seconds. I \n> don't want to see strange patch dependencies that nobody cares about.\n\nDave really was right with his keynote comment about nomenclature in\nDunedin.  I shouldn't even have put the term \"patch calculus\" in the\ne-mail body at all :-P\n\nSeriously, though, the rest of the report basically agrees with your\nposition.  Sorry if it was rambling and that key message wasn't clear.\n\nWe did kind of work out along the way that the best bits of patch\ncalculus were probably obtained with good use of topic branches.  Likely\nif there are any key advances to be made, they will be found in the form\nof clever ways to manage topic branches.\n\n>  And I very much don't want to see theory over practice.\n\nTheory?  Do I *look* like a theorist?\n\n(looks around sheepishly)\n\nThis was valuable cross-culture field research!\n\n(looks around at rather non-plussed eyes)\n\nHey, I found it quite enlightening, and at least a few other people were\namused by the ordeal.  And I learned a little bit more about git along\nthe way.\n\n(waits for a 'hear', 'hear'!  silence.)\n\nI'll get me coat.\n\nSam.\n"},{"id":"18299","messageId":"7vsloucuxk.fsf@assigned-by-dhcp.cox.net","threadId":"3779","inReplyTo":"4430D352.4010707@vilain.net","subject":"Re: n-heads and patch dependency chains","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-03T19:37:11Z","receivedAt":"2006-04-03T19:37:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Vilain <sam@vilain.net> writes:\n\n> I think we can conclude from this:\n>\n>   - this is not impossible using the current model, and some extra\n>     useful information can be seen in the tree that shows more real\n>     dependency information and relationships between individual commits\n>\n>   - doing automatic n-head creation would probably be madness, as\n>     far too many useless heads are created (though it is almost\n>     guaranteed that supporting 'patch commuting' a la darcs would\n>     make this *even worse* as it would mean that you could potentially\n>     have even more heads)\n\nI suspect people have hard time grasping _why_ you are jumping\nthrough hoops.  At least I do.  What problem are you trying to\nsolve?  You perhaps described your mechanism well enough, but it\nis not quite clear to me what kind of operations are made easier\nwith this exercise, against which possible downside of it, if\nany, would be judged.\n\n>   - the current tools make this style of development difficult.\n\nGit was born from necessity, and we have been aiming to have\ntools to do what are commonly needed.  It is not surprising to\nsee existing tools do not support modes of operations that are\n\"unusual\" (meaning, things we have not done with git so far).\nAlso we do not tend to do things only because we can.\n\nNow admittably I am guilty of having done a few things only\nbecause we can.  Octopus is an example.  Making an Octopus only\nbecause you can does not buy you much, other than its coolness\nvalue, and it would make exporting the history to other SCMs\nsomewhat harder I suspect, and it makes bisecting more\nexpensive [*1*].\n\nFor example, the point jdl raised during the discussion is far\neasier to understand.  When working on multiple topics, he often\nneeds to test them as a whole, so he pulls them into a test\nbranch (can be a throwaway branch).  When he needs to do fixups,\nit is most efficient to do compile/run test while still in the\ntest branch, but after things test out, in order to keep\nlogically different things separate, he needs to go back to\nrelevant topic branches and make a commit.  This is painful --\nare there ways to make this easier [*2*]?\n\nWould patch commutation calculus help with his problem?\n\nI suspect patch commutation could be used to solve his problem,\nbut if it does not, it does not mean what you are trying to do\nwith hydra is not interesting.  It just means from your\ndescriptions it is not clear what real problems hydra is trying\nto solve, and I misunderstood that it is related to his problem\n(just like jdl did, I suspect).\n\nSo can you step back a bit and start from describing what\nproblem you are trying to solve, before describing the\nmechanisms you think would help?\n\nOne thing I can think of that could potentially come out of your\napproach would be an alternative implementation of what StGIT\ndoes.  Inside a local developer repository, being able to\nreorder patches and rewrite them flexibly is very useful.\n\nWhile I agree with Linus's reaction \"I want my merges fast\", I\nam not necessarily so negative about the approach.  For example,\nif you use it only as a tool to reorder and clean-up local\ndevelopment history to a presentable form (IOW, using hydra to\nmanage your development, but the result exposed to the outside\nworld is exported from that hydra into a more linear form, that\ndoes not give other people a heart attach when they look at the\nancestry graph in gitk), you would not negatively affect other\npeople who work with you.\n\n\n[Footnote]\n\n*1* Do not get me wrong.  Octopus is sometimes the most natural\nway to express what happened, but the case it applies to is\nquite narrowly defined -- to merge in independent branches that\nhappened to mature at the same time together.  So the tool\ndiscourages you from making an Octopus that is not trivial,\ndeliberately.\n\n*2* I see two approaches, the more obvious being \"git checkout\n-m that-topic\".  Just edit (but not update-index) on top of\ntest, have \"checkout -m\" adjust your changes to the topic branch\nyou want to commit to, make a commit there, and then come back\nto the test branch, and merge the topic branch again.\n\nAnother obvious strategy would be to make commits on top of\n\"test\" and then cherry-pick them back on top of the relevant\ntopics later.\n    \n        topicA                  You have three topics\n         o---o                  you need to test together...\n        /\n    ---o---o topicB\n        \\ \n         o---o\n        topicC\n\n ==>\n    \n        topicA                  So merge them up and start testing.\n         o---o\n        /     \\      \n    ---o---o---T\n        \\     /\n         o---o\n        topicB\n\n ==>\n     \n        topicA                  But you find problems, and fix them\n         o---o                  up as you go along...\n        /     \\      \n    ---o---o---T---1---2\n        \\     /\n         o---o\n        topicB\n\n ==>\n    \n        topicA                  Later you cherry-pick them into\n         o---o---1'             relevant topics.\n        /\n    ---o---o topicB\n        \\ \n         o---o---2'\n        topicC\n\n ==>\n\n        topicA                  Next round of test will continue\n         o---o---1'             by rebuilding the test branch\n        /         \\\n    ---o---o-------T\n        \\         /\n         o---o---2'\n        topicC\n"},{"id":"18313","messageId":"4431B60E.3030008@vilain.net","threadId":"3779","inReplyTo":"7vsloucuxk.fsf@assigned-by-dhcp.cox.net","subject":"Re: n-heads and patch dependency chains","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-04-03T23:55:58Z","receivedAt":"2006-04-03T23:55:58Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Junio C Hamano wrote:\n\n>I suspect people have hard time grasping _why_ you are jumping\n>through hoops.  At least I do.  What problem are you trying to\n>solve?  You perhaps described your mechanism well enough, but it\n>is not quite clear to me what kind of operations are made easier\n>with this exercise, against which possible downside of it, if\n>any, would be judged.\n>[...]\n>So can you step back a bit and start from describing what\n>problem you are trying to solve, before describing the\n>mechanisms you think would help?\n>  \n>\n\nAs a research exercise the principle purpose was first to see if there\nis a natural fit with git's data model, and secondly to investigate what\nbenefits were possible from it. In a sense it was \"bottom-up\" investigation.\n\n>>  - the current tools make this style of development difficult.\n>>    \n>>\n>Git was born from necessity, and we have been aiming to have\n>tools to do what are commonly needed.  It is not surprising to\n>see existing tools do not support modes of operations that are\n>\"unusual\" (meaning, things we have not done with git so far).\n>Also we do not tend to do things only because we can.\n>  \n>\n\nAnd a good principle that is, too.\n\n>For example, the point jdl raised during the discussion is far\n>easier to understand.  When working on multiple topics, he often\n>needs to test them as a whole, so he pulls them into a test\n>branch (can be a throwaway branch).  When he needs to do fixups,\n>it is most efficient to do compile/run test while still in the\n>test branch, but after things test out, in order to keep\n>logically different things separate, he needs to go back to\n>relevant topic branches and make a commit.  This is painful --\n>are there ways to make this easier [*2*]?\n>\n>Would patch commutation calculus help with his problem?\n>  \n>\n\nI'd provisionally say \"yes, that's the fit\". It's just like having\nmultiple topic branches all checked out at once, with commits going to\nthe appropriate branch as necessary.\n\nIn my experiment, when a commit touched files on more than one head,\nthen the heads would be collapsed to a single one, like a merge. As the\nnature of the setup was such that you didn't explicitly name heads, this\nwas a natural thing to do. But if you're naming them, you probably would\nwant some way to choose between applying the commit to just one head,\nboth heads, or collapsing the two heads into one.\n\nThat approach actually offers the most flexibility - a porcelain could\ndo full darcs-like patch calculus if it wanted, or saner explicit topic\nbranching.\n\n>One thing I can think of that could potentially come out of your\n>approach would be an alternative implementation of what StGIT\n>does.  Inside a local developer repository, being able to\n>reorder patches and rewrite them flexibly is very useful.\n>  \n>\n\nOh, I didn't think of that. Were you thinking of an extra head for each\n\"uncommitted\" chain of related patches? That's an interesting idea.\n\nI think it might really help use cases like the -mm Linux tree, where\nbunches of related commits are typically applied in a series, but you\nespecially want to track inter-set dependencies. Currently stgit takes a\nvery long time to import the split -mm series :-)\n\n>Another obvious strategy would be to make commits on top of\n>\"test\" and then cherry-pick them back on top of the relevant\n>topics later.\n>    \n>        topicA                  You have three topics\n>         o---o                  you need to test together...\n>        /\n>  [...]\n>        \\         /\n>         o---o---2'\n>        topicC\n>  \n>\n\nThat's a nice illustration of it, yes.\n\nSam.\n"},{"id":"18316","messageId":"e0sfti$1nb$1@sea.gmane.org","threadId":"3779","inReplyTo":"4430D352.4010707@vilain.net","subject":"Re: n-heads and patch dependency chains","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-04T00:51:03Z","receivedAt":"2006-04-04T00:51:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sam Vilain wrote:\n\n> The IRC log:\n> \n> 17:45 < mugwump> the other suggestions look quite good.  I don't know\n>                  how I got roped into spending a whole day on this :)\n> 17:46 < mugwump> oh yeah, I remember now.  somebody asked for a\n>                  comparison between darcs and git\n> 17:46  * ShadeHawk whistles innocently\n\nLet me describe in my own words results of IRC discussion and posts on Git\nMailing List, both in this thread and in \"Multi-headed branches (hydra? :))\nfor basic patch calculus\" one\n  http://permalink.gmane.org/gmane.comp.version-control.git/18258\nand Sam Vilain work (prototype). It might help with understanding Sam's\nwork; and I hope Sam would correct me if I'm wrong.\n\nIt started I think as a way to describe (represent, save) in core GIT the\npartial ordering of patches (commits) by dependence Darcs uses in it's\npatch algebra theory {i.e. patch1 <- patch2 if patch2 depends on patch1\n(patches does not commute)} at *commit time*.\n\n> Say you've got a sequence of changes like this:\n> \n> 1. add foo.c\n> 2. add bar.c\n> 3. modify foo.c\n> 4. modify bar.c\n> \n> The darcs-like operation of this would be to have two sequences of\n> ordered patches that combine to a final result.  ie:\n> \n>   1 <- 3\n>   2 <- 4\n> \n> Unless you jump through hoops, git will represent it as:\n> \n>   1 <- 2 <- 3 <- 4.\n[the direction of arrows has changed in this quote]\n\nFirst part of the idea is to represent the partial ordering of patches by\ntheir interdependence (the sequences, chains of ordered patches) using\n\"parent\" relation. (There was also idea of adding another field(s)\n\"depends-on\" to represent only commit dependency in addition to \"parent(s)\"\nrelations defining history.)\n\nSecond part of the idea is to avoid creating, then recreating the final\nsomething (commit) which combines commit chains to a final result\n>\n>   1 -> 3  \\\n>            >- head\n>   2 -> 4  /\n> \n> Where \"head\" is a merge commit that just combines the trees of 3 and 4.\n> \nSo an idea of \"hydra\", or \"n-head\" was born, which is just virtual trivial\nmerge commit which gives us final result, HEAD of chains. (It is trivial\nbecause trees 3 and 4 are independent, merge without conflicts.) And also\nrelated idea of \"hydra commit\", which automatically adds commit to correct\nchain (places commit in correct place of partial ordering by dependence)\nand advances n-head (virtual trival merge commit which is HEAD).\n\nThe side effects (perhaps more important than making use of Darcs patch\nalgebra theory, and Darcs merge algorithm) is that we have automatical\ntopic branches, or to be more exact automatical dependency (sub)branches\n(commit/patch dependency chains).\n\nDoes it make sense?\n\n\nTo be continued...\n\nIn next installment we will see how \"hydra commits\" or \"n-heads\" might work:\nsimplifications in defining commit dependency, \"coarse\" ordering i.e. no\nbranching dependency chains, updating n-head during commit and during\nmerge. Sam Vilain wrote some scripts for \"proving of concept\"; I would\npresent my idea on that matter, untested.\n\n-- \nJakub Narębski\nShadeHawk on #git\nPoland\n"},{"id":"18332","messageId":"44323C52.2030803@op5.se","threadId":"3779","inReplyTo":"4431B60E.3030008@vilain.net","subject":"Re: n-heads and patch dependency chains","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-04-04T09:28:50Z","receivedAt":"2006-04-04T09:28:50Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Sam Vilain wrote:\n> Junio C Hamano wrote:\n> \n>>For example, the point jdl raised during the discussion is far\n>>easier to understand.  When working on multiple topics, he often\n>>needs to test them as a whole, so he pulls them into a test\n>>branch (can be a throwaway branch).  When he needs to do fixups,\n>>it is most efficient to do compile/run test while still in the\n>>test branch, but after things test out, in order to keep\n>>logically different things separate, he needs to go back to\n>>relevant topic branches and make a commit.  This is painful --\n>>are there ways to make this easier [*2*]?\n>>\n>>Would patch commutation calculus help with his problem?\n>> \n>>\n> \n> \n> I'd provisionally say \"yes, that's the fit\". It's just like having\n> multiple topic branches all checked out at once, with commits going to\n> the appropriate branch as necessary.\n> \n\n\nWouldn't \"git commit -M -b topic\", for committing to a different branch \nthan what is checked out (-b) and also to the checked out branch (-M) \nhave the same beneficial effects, but without the complexity of hydras \nand patch dependency theory? It would only remove the cherry-pick stage \nthough, but perhaps it's good enough. Although when I think about it, -b \n<branch> for committing to another branch and -B <branch> for doing the \nabove probably makes more sense.\n\nThose flags don't exist currently btw, in case someone's reading this on \nthe archives.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"18333","messageId":"7v1wwd8y9j.fsf@assigned-by-dhcp.cox.net","threadId":"3779","inReplyTo":"44323C52.2030803@op5.se","subject":"Re: n-heads and patch dependency chains","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-04T09:51:04Z","receivedAt":"2006-04-04T09:51:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n> Sam Vilain wrote:\n>> Junio C Hamano wrote:\n>>> [ made change on a test branch that bundles topic branches\n>>>   -- now want to commit back to the component topic branch ]\n>>>Would patch commutation calculus help with his problem?\n>>>\n>> I'd provisionally say \"yes, that's the fit\". It's just like having\n>> multiple topic branches all checked out at once, with commits going to\n>> the appropriate branch as necessary.\n>\n> Wouldn't \"git commit -M -b topic\", for committing to a different\n> branch than what is checked out (-b) and also to the checked out\n> branch (-M) have the same beneficial effects, but without the\n> complexity of hydras and patch dependency theory? It would only remove\n> the cherry-pick stage though, but perhaps it's good enough. Although\n> when I think about it, -b\n> <branch> for committing to another branch and -B <branch> for doing\n> the above probably makes more sense.\n\nIt feels to me that the above set of flags encourage a workflow\nthat:\n\n (1) modify the source and run tests in \"test\" branch;\n (2) have tool automatically adjust the change to match the other\n     branch (i.e. the topic to be checked in) automatically;\n (3) make a commit, without a chance to do the final sanity\n     check in the context of the branch being committed.\n\nAn individual topic branch itself might not be even testable\nstandalone, but at least I'd prefer to have a chance to double\ncheck if the \"patch commuting\" (or \"cherry-pick stage\") did a\nsensible thing [*1*].\n\nAs I said on the list in the past, I am from a school that\nbelieves in not committing anything that has not been\ntested/reviewed as a whole, especially when it comes to\nindividual developers, so I am not sure it is a good idea\nin general to make it easy to do so to begin with.\n\nBut that is just my personal preference, and it does not\nnecessarily have to stop people wishing to have that feature to\nhave it, especially when there are enough of them.\n\n> Those flags don't exist currently btw, in case someone's reading this\n> on the archives.\n\nI take it that you are volunteering to come up with an initial\nround of implementation of these flags?\n\n[Footnote]\n\n*1* ... that's where \"git checkout -m that-topic\", perhaps\n followed by \"git diff HEAD\", comes in.\n"},{"id":"18335","messageId":"44324E24.3090007@op5.se","threadId":"3779","inReplyTo":"7v1wwd8y9j.fsf@assigned-by-dhcp.cox.net","subject":"Re: n-heads and patch dependency chains","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-04-04T10:44:52Z","receivedAt":"2006-04-04T10:44:52Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson <ae@op5.se> writes:\n> \n> \n>>Sam Vilain wrote:\n>>\n>>>Junio C Hamano wrote:\n>>>\n>>>>[ made change on a test branch that bundles topic branches\n>>>>  -- now want to commit back to the component topic branch ]\n>>>>Would patch commutation calculus help with his problem?\n>>>>\n>>>\n>>>I'd provisionally say \"yes, that's the fit\". It's just like having\n>>>multiple topic branches all checked out at once, with commits going to\n>>>the appropriate branch as necessary.\n>>\n>>Wouldn't \"git commit -M -b topic\", for committing to a different\n>>branch than what is checked out (-b) and also to the checked out\n>>branch (-M) have the same beneficial effects, but without the\n>>complexity of hydras and patch dependency theory? It would only remove\n>>the cherry-pick stage though, but perhaps it's good enough. Although\n>>when I think about it, -b\n>><branch> for committing to another branch and -B <branch> for doing\n>>the above probably makes more sense.\n> \n> \n> It feels to me that the above set of flags encourage a workflow\n> that:\n> \n>  (1) modify the source and run tests in \"test\" branch;\n>  (2) have tool automatically adjust the change to match the other\n>      branch (i.e. the topic to be checked in) automatically;\n>  (3) make a commit, without a chance to do the final sanity\n>      check in the context of the branch being committed.\n> \n\nI don't fully understand 3 here. The workflow makes it easier to test \nhow different topics work together, and make fixes to those that don't \nplay well with others. Granted, it's not possible to test each topic by \nitself without checking it out, making the changes and re-compiling and \nso on, but since commits are so easy to undo I think it'd be nice to \nhave the changes tracked. Another good thing is that fixes that apply on \ntop of the \"work-together\" fixes, but that only make the topic branch \nbuild/work properly are completely rebase'able, and should result in a \nfast-forward merge since they share the same commit.\n\n\n> An individual topic branch itself might not be even testable\n> standalone, but at least I'd prefer to have a chance to double\n> check if the \"patch commuting\" (or \"cherry-pick stage\") did a\n> sensible thing [*1*].\n> \n\nUnderstandable, and this workflow would still be available, but see below.\n\n\n> As I said on the list in the past, I am from a school that\n> believes in not committing anything that has not been\n> tested/reviewed as a whole, especially when it comes to\n> individual developers, so I am not sure it is a good idea\n> in general to make it easy to do so to begin with.\n> \n\nIn short, you're from the school of centralized repositories. I used to \nbe very careful about committing things too, but since I switched to git \nI happily commit smaller and more often, and regularly toss up a \nthrow-away branch to make small commits that may or may not work and \nlater apply the (tested) combined diff as a single commit or series of \ncommits at points where I've tested one feature/fix to actually work as \nintended. This is nifty because people that help with testing can pull \nfrom my throw-away branch and get to work without me having to send them \na tar-tree and a patch.\n\nI believe in not *pushing* anything that hasn't been thoroughly tested, \nbut the ability to track and commit possibly broken changes without it \naffecting the project as a whole is what makes git so great for me. In \nthe CVS days distributed testing was a nuissance. With git it's smooth \nsailing.\n\n> \n>>Those flags don't exist currently btw, in case someone's reading this\n>>on the archives.\n> \n> \n> I take it that you are volunteering to come up with an initial\n> round of implementation of these flags?\n> \n\nUnless someone can convince me I'm on the wrong track before I get off \nwork, yes.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"18337","messageId":"e0tjpk$ktu$1@sea.gmane.org","threadId":"3779","inReplyTo":"44323C52.2030803@op5.se","subject":"Re: n-heads and patch dependency chains","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-04T11:03:17Z","receivedAt":"2006-04-04T11:03:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n\n> Wouldn't \"git commit -M -b topic\", for committing to a different branch\n> than what is checked out (-b) and also to the checked out branch (-M)\n> have the same beneficial effects, but without the complexity of hydras\n> and patch dependency theory? It would only remove the cherry-pick stage\n> though, but perhaps it's good enough. Although when I think about it, -b\n> <branch> for committing to another branch and -B <branch> for doing the\n> above probably makes more sense.\n\nDo you mean that you commit current state to the checked out (working)\nbranch, and commit *changes* (i.e. apply patch) to a different branch?\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"18338","messageId":"tnxzmj1ppm4.fsf@arm.com","threadId":"3779","inReplyTo":"4430D352.4010707@vilain.net","subject":"Re: n-heads and patch dependency chains","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2006-04-04T11:05:55Z","receivedAt":"2006-04-04T11:05:55Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Sam Vilain <sam@vilain.net> wrote:\n> \"Patch dependency chains\", the best plain-English term we could find for\n> the scary sounding darcs term \"patch calculus\", are said by some to be a\n> very good reason to use a system like darcs, even to some its\n> fundamental advantage over systems such as git.\n\nAs Linus pointed out, while darcs theory is interesting, it doesn't\nwork properly in practice. Dependency tracking can create problems\nwith merging. Darcs' patch commuting theory has (a big, IMHO) problem\nsince every time you pull a patch (or more) it needs to commute all\nthe patches back to the common ancestor. Over time, the merging\nbecomes slower and slower (i.e. even much slower than what darcs shows\nin simple tests with the Linux kernel).\n\nInexact patch commuting can be achieved using diff3 (or merge) with 3\nsnapshots of the tree (the bottom of the patch, the top of the patch\nand the current head on top of which the patch is being applied) which\nGIT handles very well and fast since there is no need to commute\nthousands of patches back to the common ancestor. The slight\ndisadvantage is that diff3 merging is not as exact as Darcs' patch\ncommuting but OK for 99% of the real cases.\n\nStGIT is based on this inexact patch commuting \"theory\" and, with the\naddition of upstream merging detection (based on reverse-applying), it\nis seems to behave properly in almost all the cases (though you can\ndeliberately create some patches to break the algorithm).\n\nI've been thinking about adding patch dependency tracking to StGIT but\nonly as a recommendation and not enforcement. The algorithm would be\nsimilar to the upstream merging detection.\n\n-- \nCatalin\n"},{"id":"18339","messageId":"44325CDB.2000101@op5.se","threadId":"3779","inReplyTo":"e0tjpk$ktu$1@sea.gmane.org","subject":"Re: n-heads and patch dependency chains","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-04-04T11:47:39Z","receivedAt":"2006-04-04T11:47:39Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> Andreas Ericsson wrote:\n> \n> \n>>Wouldn't \"git commit -M -b topic\", for committing to a different branch\n>>than what is checked out (-b) and also to the checked out branch (-M)\n>>have the same beneficial effects, but without the complexity of hydras\n>>and patch dependency theory? It would only remove the cherry-pick stage\n>>though, but perhaps it's good enough. Although when I think about it, -b\n>><branch> for committing to another branch and -B <branch> for doing the\n>>above probably makes more sense.\n> \n> \n> Do you mean that you commit current state to the checked out (working)\n> branch, and commit *changes* (i.e. apply patch) to a different branch?\n> \n\nNo, I mean that this would commit both to the testing branch (being the \nresult of several merged topic-branches) and to the topic-branch merged \nin. Commit as in regular commit, with a commit-message and a patch. The \nresulting repository would be the exact same as if the change was \ncommitted only to the topic-branch and then cherry-picked on to the \ntesting-branch.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"18356","messageId":"7vhd596ua0.fsf@assigned-by-dhcp.cox.net","threadId":"3779","inReplyTo":"4431B60E.3030008@vilain.net","subject":"Re: n-heads and patch dependency chains","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-04T19:00:07Z","receivedAt":"2006-04-04T19:00:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I was re-reading the hydra stuff and realized I've seen the \"a\ncap that bundles independent tracks together\" pattern somewhere\nelse in the history of git.\n\nIt is very similar to how \"bind commit\" would have worked.\n\nWith hydra, you keep independently mergeable tracks and bundle\ntheir tips together:\n\n    ---o--+\n    ---o--+--*\n    ---o--+\n\nand advancement of each individual track is bundled together by\nuncapping and recapping:\n\n    ---o--o--+\n    ---o--o--+--*\n    ---o-----+\n\nSo a hydra cap would record:\n\n - the result \"tree\" of the (trivial) merge of the bundled tips;\n - the commit object name of the tips.\n\nA \"bind commit\" proposal was made to support subprojects living\nin their own subdirectories.  The picture to describe the commit\nancestry chain would be almost the same as the above picture,\nexcept that it did not uncap and recap, but would have built its\nown ancestry chain.\n\nIt had two different kinds of commit relationships: parenthood\nand directory structure binding.  The component subprojects\nlived in their own subdirectories (so if you are maintaining an\nembedded Linux along with matching toolchain, you would have linux/\nsubdirectory that has the kernel hierarchy, gcc/, libc/, ...),\nand commit objects had \"bind commit-sha1 subdirectory-name\"\nlines to express how the components are bundled together.  A\ncommit object would have looked like this:\n\n\ttree fc9957b0052df6a8248420395bc9febd66194252\n        parent 052df6a8248420395bc9febd66194252fc9957b0\n        bind f6a8248420395bc9febd66194252fc9957b0052d linux/\n        bind 20395bc9febd66194252fc9957b0052df6a82484 gcc/\n\tauthor A U Thor <author@example.com> 1144111304 -0700\n        ...\n\nThe \"parent\" line is the commit ancestry as usual, and each\n\"bind\" line names a commit object of component project and where\nin the directory hierarchy the tree for that commit object would\nbe checked out.  The \"tree\" line records the result of grafting\nthe subprojects together.  So, for example, ls-tree -d fc9957\nlinux in the above example would have shown the tree object\nf6a824^{tree}.\n\nThe structure forbid you from binding two separate projects at\nthe same directory in order to enforce clean separation of\nsubprojects, but if you allow multiple commits to be bound at\nthe root level, that could be used as a hydra cap.\n\nI've done changes to support this at the core level; I think I\nstill have the code around somewhere (and the net never forgets\n;-), so if you are interested you might want to take a look.\n\nThe trickest part was to tell rev-list --objects to work\nsensibly so that an ancestry chain that contains this kind of\ncommits can be fetched and pushed.  The code unfortunately was\ndone before recent rev-list renovation so merging it to the\ncurrent codebase needs some understanding of how rev-list is\nsupposed to work, though.\n"},{"id":"18358","messageId":"e0uk9o$oj6$1@sea.gmane.org","threadId":"3779","inReplyTo":"7vhd596ua0.fsf@assigned-by-dhcp.cox.net","subject":"Re: n-heads and patch dependency chains","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-04T20:18:02Z","receivedAt":"2006-04-04T20:18:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> I was re-reading the hydra stuff and realized I've seen the \"a\n> cap that bundles independent tracks together\" pattern somewhere\n> else in the history of git.\n> \n> It is very similar to how \"bind commit\" would have worked.\n[...] \n> A \"bind commit\" proposal was made to support subprojects living\n> in their own subdirectories.  The picture to describe the commit\n> ancestry chain would be almost the same as the above picture,\n> except that it did not uncap and recap, but would have built its\n> own ancestry chain.\n\nOne of versions of \"hydra commit\" proposals, in the mail which is yet to\nappear on Gmane git mailing list archive, and Gmane NNTP interface to git\nmailing list, was to define commit dependency (to which chain commit would\nget) in the terms of affecting files in the same directory. Simple\ngeneralization to subtree (directory and its subdirectories) gives \"bind\ncommit for subprojects\".\n\n> It had two different kinds of commit relationships: parenthood\n> and directory structure binding.\n\nGreat minds think alike :-P -- we (Sam and I) were talking on #git about\nadding \"depends-on\" field to commit.\n\nIn the email to write I would propose that instead of adding \"depends-on\"\nfield (or \"bind\") one can at least in prototype stage make parallel\ndevelopment, commiting simultaneously to the tree where history is history,\nand to the tree where history is dependence, or bind. I hope I will make\nmyself clearer in upcoming message; see Sam post beginning this thread - we\nwant to make both pictures (on the left and on the right) simultaneously.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"18369","messageId":"443364F5.2040504@vilain.net","threadId":"3779","inReplyTo":"7vhd596ua0.fsf@assigned-by-dhcp.cox.net","subject":"Re: n-heads and patch dependency chains","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-04-05T06:34:29Z","receivedAt":"2006-04-05T06:34:29Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Junio C Hamano wrote:\n\n>A \"bind commit\" proposal was made to support subprojects living\n>in their own subdirectories.  The picture to describe the commit\n>ancestry chain would be almost the same as the above picture,\n>except that it did not uncap and recap, but would have built its\n>own ancestry chain.\n>  \n>\n\nI had considered that this would make directory subprojects possible,\nbut didn't want to draw attention to it.\n\nActually I'm now of the thinking that the problem is that we are using\n'parent' for two things;\n\n1. the merge bases for this merge, if a merge\n(or the base for this change for a patch)\n\n2. the historical precedent(s) for this commit.\n\nIn the single line of history case these are always the same. For an\nactual merge they are also the same. However, when you are superceding a\nmerge with a newer merge, or mucking with history they are different.\n\nSo, I think all we need to make this all work smashingly well is to have\na new field called \"prior\" or perhaps \"previous\".\n\nAs well as being mostly backwards compatible and supporting grouping\nyour commits into topics in a single checkout, this would also have the\nside effect of:\n\n- directly supporting stgit / pg style patchset evolution, without\nneeding to use seperate branches for each release of your patchset. This\nwould not replace the need for stgit etc to wind the head - while\nrevising a patchset you really don't want the system to record\nintermediate changes, just the ones you want to publish\n\n- supporting tree subprojects (as it is a more specific use case)\n\n- rewriting history! Without losing the old commits. Unless you wanted\nto - say, for archiving old commits by rebasing the whole project off a\nnew revision.\n\nIt also does not suffer from the 'problem' in Andreas' \"dual head\ncommit\" approach that one commit will thenceforth be known by two commit\nIDs.\n\n>It had two different kinds of commit relationships: parenthood\n>and directory structure binding.  The component subprojects\n>lived in their own subdirectories (so if you are maintaining an\n>embedded Linux along with matching toolchain, you would have linux/\n>subdirectory that has the kernel hierarchy, gcc/, libc/, ...),\n>and commit objects had \"bind commit-sha1 subdirectory-name\"\n>lines to express how the components are bundled together.  A\n>commit object would have looked like this:\n>\n>\ttree fc9957b0052df6a8248420395bc9febd66194252\n>        parent 052df6a8248420395bc9febd66194252fc9957b0\n>        bind f6a8248420395bc9febd66194252fc9957b0052d linux/\n>        bind 20395bc9febd66194252fc9957b0052df6a82484 gcc/\n>\tauthor A U Thor <author@example.com> 1144111304 -0700\n>\n>The \"parent\" line is the commit ancestry as usual, and each\n>\"bind\" line names a commit object of component project and where\n>in the directory hierarchy the tree for that commit object would\n>be checked out.  The \"tree\" line records the result of grafting\n>the subprojects together.  So, for example, ls-tree -d fc9957\n>linux in the above example would have shown the tree object\n>f6a824^{tree}.\n>  \n>\n\nWhile the approach I outlined supports this in a way, it is subtly\ndifferent.\n\nFirstly, the above approach makes it a hard requirement that the\nindependent series of commits are in seperate paths, you mention a fix\nfor this -\n\n>The structure forbid you from binding two separate projects at\n>the same directory in order to enforce clean separation of\n>subprojects, but if you allow multiple commits to be bound at\n>the root level, that could be used as a hydra cap.\n>  \n>\n\n- but this means you are not storing the 'merged' tree in the commit,\nwhich I think is a mistake. While we've been talking mostly about\ndealing with managing changes simple enough to merge plainly for\nsimplicity of operations, this would *force* it to be so because you\nneed to allow anyone to check it out.\n\nOn the other hand - these bind commits enables tracking a sub-project in\na sub-directory whilst retaining the same commit IDs, to make tracking\neasier.\n\nEven this works using \"prior\", too - though you'd have to use surrogate\ncommits that link to the sub-project commit and wrapper tree object.\n\nHow does that sound?\n\nSam.\n"},{"id":"18371","messageId":"e0vqjk$5dr$1@sea.gmane.org","threadId":"3779","inReplyTo":"443364F5.2040504@vilain.net","subject":"Re: n-heads and patch dependency chains","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-05T07:11:52Z","receivedAt":"2006-04-05T07:11:52Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"First, hydras or n-head was invented to avoid capping and recapping, and\njust advance it as a normal head (and to remember what are\nsubprojects/patch dependency chains/whatever to choose).\n\nSecond, we could generalize those extra commit references in commit\nstructure (be they \"bind\", \"prior\" or \"previous\", or \"depends-on\") and have\ncommit/merge pluggable helper manage them. And merge strategy may make use\nof them.\n\nThird, would using *directory* with for a N-HEAD (containing all the\nsubheads, subprojects, chains, branches, fibers, whatever) instead of an\nordinary file for HEAD be a good idea? For hydra if we want it to be easily\ninterweaved with ordinary commit I think we would also need the link for\nbottom, hydra shoulder, hydra tail i.e. common commit being starting point\nfor all the chains, or subprojects (for subprojects it can be empty tree\ncommit).\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"18373","messageId":"4433723E.1080705@vilain.net","threadId":"3779","inReplyTo":"e0vqjk$5dr$1@sea.gmane.org","subject":"Re: n-heads and patch dependency chains","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2006-04-05T07:31:10Z","receivedAt":"2006-04-05T07:31:10Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Jakub Narebski wrote:\n\n>First, hydras or n-head was invented to avoid capping and recapping, and\n>just advance it as a normal head (and to remember what are\n>subprojects/patch dependency chains/whatever to choose).\n>\n>Second, we could generalize those extra commit references in commit\n>structure (be they \"bind\", \"prior\" or \"previous\", or \"depends-on\") and have\n>  \n>\n\nNote that these are all quite different types of references. \"Bind\"\nimplies an unmerged tree to be woven in on checkout, \"prior and\n\"previous\" a historical relationship, and \"depends-on\" the previous\ncommit that the change that this commit supplies was based on.\n\nSo, I think \"parent\" already means \"depends-on\" closely enough.\n\n>commit/merge pluggable helper manage them. And merge strategy may make use\n>of them.\n>\n>Third, would using *directory* with for a N-HEAD (containing all the\n>subheads, subprojects, chains, branches, fibers, whatever) instead of an\n>ordinary file for HEAD be a good idea? For hydra if we want it to be easily\n>interweaved with ordinary commit I think we would also need the link for\n>bottom, hydra shoulder, hydra tail i.e. common commit being starting point\n>for all the chains, or subprojects (for subprojects it can be empty tree\n>commit).\n>  \n>\n\nThis was similar to the original suggestion, of heads that have multiple\nheads, or hydra. I think the basic rejection for this is that nothing is\nthen tracking the progression of the merged tree - unless you keep a\n\"cherry picked\" tree for the combined work. And of course it is a\nbackwards incompatible change.\n\nSam.\n"},{"id":"18374","messageId":"e0vtdl$e3k$1@sea.gmane.org","threadId":"3779","inReplyTo":"4433723E.1080705@vilain.net","subject":"Re: n-heads and patch dependency chains","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-04-05T07:59:48Z","receivedAt":"2006-04-05T07:59:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sam Vilain wrote:\n\n> Jakub Narebski wrote:\n\n>>Third, would using *directory* with for a N-HEAD (containing all the\n>>subheads, subprojects, chains, branches, fibers, whatever) instead of an\n>>ordinary file for HEAD be a good idea? For hydra if we want it to be\n>>easily interweaved with ordinary commit I think we would also need the\n>>link for bottom, hydra shoulder, hydra tail i.e. common commit being\n>>starting point for all the chains, or subprojects (for subprojects it can\n>>be empty tree commit).\n> \n> This was similar to the original suggestion, of heads that have multiple\n> heads, or hydra. I think the basic rejection for this is that nothing is\n> then tracking the progression of the merged tree - unless you keep a\n> \"cherry picked\" tree for the combined work. And of course it is a\n> backwards incompatible change.\n\nI thought about keeping N-HEAD and HEAD and updating them simultaneously.\nWith extra fields in commit (however they would be named) use them, without\nextra fields use ordinary branches, creating histories like in your example\nin first post in the thread.\n\nI.e. when doing [hydra] commit, add commit to ordinary history (recording\nthe time sequence of changes inside branch) advancing HEAD, and add commit\nto appropriate chain/subhead/fiber in the N-HEAD and \"advance N-HEAD\". This\nwould make change backwards compatibile.\n\nThe problem would be to keep N-HEAD and HEAD to get out of sync, e.g. when\nsomebody updates only HEAD with an older git... well, we can always advance\nN-HEAD to HEAD using commits from the time they were in sync to the current\nhead state.\n\n-- \nJakub Narebski\nShadeHawk on #git\nWarsaw, Poland\n"},{"id":"18937","messageId":"1145556505.5314.149.camel@cashmere.sps.mot.com","threadId":"3779","inReplyTo":"44325CDB.2000101@op5.se","subject":"Re: n-heads and patch dependency chains","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-04-20T18:08:25Z","receivedAt":"2006-04-20T18:08:25Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Tue, 2006-04-04 at 06:47, Andreas Ericsson wrote:\n\n> No, I mean that this would commit both to the testing branch (being the \n> result of several merged topic-branches) and to the topic-branch merged \n> in. Commit as in regular commit, with a commit-message and a patch. The \n> resulting repository would be the exact same as if the change was \n> committed only to the topic-branch and then cherry-picked on to the \n> testing-branch.\n\nI am your number one fan!  If I finish reading these 600+\nmessages, will I find out you have already implemented it,\nit's committed, and you just need me to test it now? :-)\n\njdl\n"},{"id":"18940","messageId":"7v4q0oyt3w.fsf@assigned-by-dhcp.cox.net","threadId":"3779","inReplyTo":"1145556505.5314.149.camel@cashmere.sps.mot.com","subject":"Re: n-heads and patch dependency chains","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-04-20T18:55:31Z","receivedAt":"2006-04-20T18:55:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger <jdl@freescale.com> writes:\n\n> On Tue, 2006-04-04 at 06:47, Andreas Ericsson wrote:\n>\n>> No, I mean that this would commit both to the testing branch (being the \n>> result of several merged topic-branches) and to the topic-branch merged \n>> in. Commit as in regular commit, with a commit-message and a patch. The \n>> resulting repository would be the exact same as if the change was \n>> committed only to the topic-branch and then cherry-picked on to the \n>> testing-branch.\n\nTo be consistent, I think the result should be \"as if the change\nwas commited only to the topic-branch and then the topic-branch\nwas *merged* into the testing-branch\", since you start your\ntesting branch as \"being the result of several merged topic-branches\".\n\nI do that (manually) all the time, with:\n\n\t$ git checkout next\n        $ hack hack hack\n\n        $ git checkout -m one/topic\n        $ git commit -o this-path that-path\n        $ git checkout next\n        $ git pull . one/topic\n\nGiving a short-hand for the last four-command sequence would\ncertainly be nice.\n\n> I am your number one fan!  If I finish reading these 600+\n> messages, will I find out you have already implemented it,\n> it's committed, and you just need me to test it now? :-)\n\nLikewise... ;-)\n"},{"id":"18967","messageId":"44489CE4.1050101@op5.se","threadId":"3779","inReplyTo":"7v4q0oyt3w.fsf@assigned-by-dhcp.cox.net","subject":"Re: n-heads and patch dependency chains","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-04-21T08:50:44Z","receivedAt":"2006-04-21T08:50:44Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Jon Loeliger <jdl@freescale.com> writes:\n> \n> \n>>On Tue, 2006-04-04 at 06:47, Andreas Ericsson wrote:\n>>\n>>\n>>>No, I mean that this would commit both to the testing branch (being the \n>>>result of several merged topic-branches) and to the topic-branch merged \n>>>in. Commit as in regular commit, with a commit-message and a patch. The \n>>>resulting repository would be the exact same as if the change was \n>>>committed only to the topic-branch and then cherry-picked on to the \n>>>testing-branch.\n> \n> \n> To be consistent, I think the result should be \"as if the change\n> was commited only to the topic-branch and then the topic-branch\n> was *merged* into the testing-branch\", since you start your\n> testing branch as \"being the result of several merged topic-branches\".\n> \n> I do that (manually) all the time, with:\n> \n> \t$ git checkout next\n>         $ hack hack hack\n> \n>         $ git checkout -m one/topic\n>         $ git commit -o this-path that-path\n>         $ git checkout next\n>         $ git pull . one/topic\n> \n> Giving a short-hand for the last four-command sequence would\n> certainly be nice.\n> \n\nAh. That's easier than what I originally looked at doing.\n\n> \n>>I am your number one fan!  If I finish reading these 600+\n>>messages, will I find out you have already implemented it,\n>>it's committed, and you just need me to test it now? :-)\n> \n> \n> Likewise... ;-)\n> \n\nSorry to disappoint you so far. I'll see if I can turn up my \nshell-skills a notch or two and get the hang of the commit-script enough \nto implement it.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"}]}