{"thread":{"id":"12059","subject":"Re: new stacked git feature","startedAt":"2008-02-12T16:42:46Z","lastAt":"2008-02-22T15:19:14Z","messageCount":8,"participants":["Catalin Marinas","Karl Hasselström"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"68531","messageId":"1202834567.14175.68.camel@pc1117.cambridge.arm.com","threadId":"12059","inReplyTo":"20080111194946.GA7504@redhat.com","subject":"Re: new stacked git feature","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2008-02-12T16:42:46Z","receivedAt":"2008-02-12T16:42:46Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Hi Jason,\n\nOn Fri, 2008-01-11 at 14:49 -0500, Jason Baron wrote:\n> I was just wondering if there was any progress on the feature, mentioned \n> below that we were discussing...I'd be more than happy to help explain\n> it further or help out with it...maybe there a mailing i should be sending\n> this to?\n\nSorry for the loooooong delay. I've been pretty busy and not able to do\nmuch work on StGIT (though the other contributors did a lot of changes).\nNow I'm trying to get up to speed with the latest StGIT structure :-).\n\nI cc'ed the other StGIT people and the GIT mailing list.\n\nCatalin Marinas wrote:\n> Jason Baron wrote:\n> > I also want to be able to go back to a git tag and reproduce a state of\n> > the tree...i'm not sure i can do this with two git repositories...i almost\n> > want an stgit mode where changes to the patches directory resulst in git\n> > commits. IE if i refresh and patch or remove a patch i get a commit to the\n> > patches directory. Maybe this can be a 'commit' mode or something that is\n> > set when we do 'stgit init'? thoughts?\n> \n> This could be made to work but I usually run refresh really often. Maybe\n> the commits to the patches directory should have an additional log\n> describing what it does (like the 'refresh --annotate').\n\nThe background of this discussion is to have two or more StGIT\nrepositories and keep them in sync. An idea is to share the exported\npatches directory and automatically synchronise them between various\nrepositories (we already have a 'stg sync' command which I use for this\nkind of things but it's not automated).\n\nYet another idea is to add some metadata to each commit log, something\nlike a unique id so that one can recreate the stack with only a GIT\nrevision id, without knowing the base.\n\n-- \nCatalin\n"},{"id":"68574","messageId":"20080213000806.GB25839@diana.vm.bytemark.co.uk","threadId":"12059","inReplyTo":"1202834567.14175.68.camel@pc1117.cambridge.arm.com","subject":"Re: new stacked git feature","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-02-13T00:08:06Z","receivedAt":"2008-02-13T00:08:06Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-02-12 16:42:46 +0000, Catalin Marinas wrote:\n\n> The background of this discussion is to have two or more StGIT\n> repositories and keep them in sync. An idea is to share the exported\n> patches directory and automatically synchronise them between various\n> repositories (we already have a 'stg sync' command which I use for\n> this kind of things but it's not automated).\n>\n> Yet another idea is to add some metadata to each commit log,\n> something like a unique id so that one can recreate the stack with\n> only a GIT revision id, without knowing the base.\n\nI've been trying to come up with a good way to represent undo\ninformation, and my current plan is this:\n\n  * Every time the patch stack is modified (that is, any time an StGit\n    command modifies anything at all), a new commit is made to a log\n    branch. Each StGit branch has one such log branch.\n\n  * The tree of a log commit contains:\n\n      - A \"patches\" subtree, with one subtree per patch, named after\n        the patch.\n\n          + Each patch tree contains an \"a\" and a \"b\" tree, and a blob\n            with the commit details including the sha1 of the commit\n            object we use to represent the patch.\n\n      - \"applied\" and \"unapplied\" blobs.\n\n      - A version stamp blob, to make it easier to extend the log\n        format in the future if we ever need to.\n\n  * The log commit has one or more parents: zero or more log commits,\n    and the current branch head commit.\n\nThis has a couple of features:\n\n  * The log contains all the information necessary for resetting back\n    to any given prior state. We might lose the commit objects of\n    unapplied patches since they aren't reachable from the branch\n    head, but we can recreate equivalent commit objects.\n\n      - This means that one could pull a log branch from another\n        repository and continue working on it.\n\n      - It also means that all the other StGit metadata becomes\n        redundant.\n\n  * The log is able to represent any state, even \"broken\" states. This\n    means that it's possible to undo \"stg repair\".\n\n  * The log can represent nonlinear history -- that is, forks and\n    merges in the state of the patch stack -- but, like git, says\n    nothing about how the result of a merge is to be computed.\n\nI've started to build this, but haven't gotten very far yet.\n\nI wasn't planning to try to build patch stack merging until later, but\nhere's how I imagine it would work:\n\n  1. All patches are popped, and set to a special \"conflicting\" state\n     with three or more \"a\" trees: a.ours, a.theirs, a.base0, a.base1,\n     a.base2, .... Similarly for the \"b\" tree and the commit details.\n     (Of course, trivial conflicts could be sorted out automatically\n     at this point.)\n\n  2. The merged stack base is created with a normal recursive merge.\n\n  3. When a conflicting patch is pushed, we do the following:\n\n       1. For each of .ours, .theirs, .base0, ..., create a new \"b\"\n          tree just like we do when we normally push a patch. If there\n          are conflicts, autoresolve them like merge-recursive does\n          internally.\n\n       2. Create the single new \"b\" tree by making a recursive merge\n          of all these updated \"b\" trees. Represent any conflicts like\n          we usually do when pushing patches.\n\nI haven't even gotten far enough to test if this kind of merging gives\nsane results, but I think it might.\n\nFeedback welcome on all of this, obviously.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"68679","messageId":"b0943d9e0802131429p76f0981cm6e54a6a07042f229@mail.gmail.com","threadId":"12059","inReplyTo":"20080213000806.GB25839@diana.vm.bytemark.co.uk","subject":"Re: new stacked git feature","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2008-02-13T22:29:34Z","receivedAt":"2008-02-13T22:29:34Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 13/02/2008, Karl Hasselström <kha@treskal.com> wrote:\n> On 2008-02-12 16:42:46 +0000, Catalin Marinas wrote:\n> > The background of this discussion is to have two or more StGIT\n> > repositories and keep them in sync. An idea is to share the exported\n> > patches directory and automatically synchronise them between various\n> > repositories (we already have a 'stg sync' command which I use for\n> > this kind of things but it's not automated).\n> >\n> > Yet another idea is to add some metadata to each commit log,\n> > something like a unique id so that one can recreate the stack with\n> > only a GIT revision id, without knowing the base.\n>\n> I've been trying to come up with a good way to represent undo\n> information, and my current plan is this:\n>\n>   * Every time the patch stack is modified (that is, any time an StGit\n>     command modifies anything at all), a new commit is made to a log\n>     branch. Each StGit branch has one such log branch.\n\nWe already have another commit for the patch history. If we add this,\nwe end up with 3 commit for each patch command. People already\ncomplained that StGIT is slow, I wouldn't go this route. I even think\nwe should drop the patch history log and maybe use some git features\nlike reflog.\n\nFor undo, can we not keep the HEAD of the old stacks in a simple text\nfile? Or maybe use reflogs and only allow as many undos as information\navailable in reflog.\n\n> I wasn't planning to try to build patch stack merging until later, but\n> here's how I imagine it would work:\n>\n>   1. All patches are popped, and set to a special \"conflicting\" state\n>      with three or more \"a\" trees: a.ours, a.theirs, a.base0, a.base1,\n>      a.base2, .... Similarly for the \"b\" tree and the commit details.\n>      (Of course, trivial conflicts could be sorted out automatically\n>      at this point.)\n>\n>   2. The merged stack base is created with a normal recursive merge.\n\nA recursive merge with the HEAD of another stack containing similar\npatches? If yes, when pushing it is likely that the patches already in\nthe base will be emptied during a three-way merge.\n\n>   3. When a conflicting patch is pushed, we do the following:\n>\n>        1. For each of .ours, .theirs, .base0, ..., create a new \"b\"\n>           tree just like we do when we normally push a patch. If there\n>           are conflicts, autoresolve them like merge-recursive does\n>           internally.\n>\n>        2. Create the single new \"b\" tree by making a recursive merge\n>           of all these updated \"b\" trees. Represent any conflicts like\n>           we usually do when pushing patches.\n\nMy idea is to merge each patch with the corresponding commit in the\nother branch and leave the base unchanged (like \"stg sync\"). The\ndifficulty is in identifying which commit from the other branch has to\nbe used. We could try guessing by the number of changes or just using\nthe subject line, assuming that it won't change (or an extra id field\nin the commit text).\n\nI find this workflow pretty difficult to implement since the StGIT\npatches are pretty volatile. It might be better to use topic branches\ninstead.\n\n-- \nCatalin\n"},{"id":"68685","messageId":"20080213235204.GA10335@diana.vm.bytemark.co.uk","threadId":"12059","inReplyTo":"b0943d9e0802131429p76f0981cm6e54a6a07042f229@mail.gmail.com","subject":"Re: new stacked git feature","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-02-13T23:52:04Z","receivedAt":"2008-02-13T23:52:04Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-02-13 22:29:34 +0000, Catalin Marinas wrote:\n\n> On 13/02/2008, Karl Hasselström <kha@treskal.com> wrote:\n>\n> >   * Every time the patch stack is modified (that is, any time an\n> >     StGit command modifies anything at all), a new commit is made\n> >     to a log branch. Each StGit branch has one such log branch.\n>\n> We already have another commit for the patch history. If we add\n> this, we end up with 3 commit for each patch command. People already\n> complained that StGIT is slow, I wouldn't go this route.\n\nI intend to get rid of the current per-patch log. It doesn't save\nenough information to be useful anyway.\n\nAs for the speed: we'll have to write one blob and one tree per\nmodified patch, plus one top-level tree and a small constant number of\nblobs. (Caveat: my current implementation is too stupid to realize\nthat not all patches were modified all the time.) These simple\ncreate-an-object-from-data-on-stdin commands should be fast enough\nthat this won't be a problem (and if a dozen extra calls to git is too\nexpensive, we'll just have to build a git command that can take them\nall in one go).\n\n> For undo, can we not keep the HEAD of the old stacks in a simple\n> text file?\n\nWe could. (We'd have to keep the sha1s of all the patches there,\nthough, and not just HEAD. And the applied/unapplied files.)\n\n> Or maybe use reflogs and only allow as many undos as information\n> available in reflog.\n\nYes, complemented by some extra files (see above). That's certainly a\nreasonable choice.\n\nI'd like to try my scheme out first, however. It's potentially more\npowerful, since it can be pulled between repositories and maybe even\nmerged.\n\n> >   2. The merged stack base is created with a normal recursive\n> >      merge.\n>\n> A recursive merge with the HEAD of another stack containing similar\n> patches? If yes, when pushing it is likely that the patches already\n> in the base will be emptied during a three-way merge.\n\nNo, a merge of the stack _bases_, with all patches popped off. And\nthis would be a regular git merge, so no emptying of patches.\n\n> >   3. When a conflicting patch is pushed, we do the following:\n> >\n> >        1. For each of .ours, .theirs, .base0, ..., create a new\n> >           \"b\" tree just like we do when we normally push a patch.\n> >           If there are conflicts, autoresolve them like\n> >           merge-recursive does internally.\n> >\n> >        2. Create the single new \"b\" tree by making a recursive\n> >           merge of all these updated \"b\" trees. Represent any\n> >           conflicts like we usually do when pushing patches.\n>\n> My idea is to merge each patch with the corresponding commit in the\n> other branch and leave the base unchanged (like \"stg sync\"). The\n> difficulty is in identifying which commit from the other branch has\n> to be used. We could try guessing by the number of changes or just\n> using the subject line, assuming that it won't change (or an extra\n> id field in the commit text).\n\nI was thinking about the same thing: just match up the patches with\nthe same name. If the user has renamed a patch, she can coalesce the\ntwo manually.\n\n> I find this workflow pretty difficult to implement since the StGIT\n> patches are pretty volatile. It might be better to use topic\n> branches instead.\n\nI agree that it's far from certain that this will be a very useful\nworkflow. But I'm willing to bet a couple of day's work that it is, so\nI'll build a prototype and see.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"69421","messageId":"b0943d9e0802201506w353b5c05vece9f99730d7663c@mail.gmail.com","threadId":"12059","inReplyTo":"20080213235204.GA10335@diana.vm.bytemark.co.uk","subject":"Re: new stacked git feature","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2008-02-20T23:06:07Z","receivedAt":"2008-02-20T23:06:07Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 13/02/2008, Karl Hasselström <kha@treskal.com> wrote:\n> On 2008-02-13 22:29:34 +0000, Catalin Marinas wrote:\n>\n>  > On 13/02/2008, Karl Hasselström <kha@treskal.com> wrote:\n>  >\n>\n> > >   * Every time the patch stack is modified (that is, any time an\n>  > >     StGit command modifies anything at all), a new commit is made\n>  > >     to a log branch. Each StGit branch has one such log branch.\n>  >\n>  > We already have another commit for the patch history. If we add\n>  > this, we end up with 3 commit for each patch command. People already\n>  > complained that StGIT is slow, I wouldn't go this route.\n>\n>\n> I intend to get rid of the current per-patch log. It doesn't save\n>  enough information to be useful anyway.\n\nI use it from time to time. The commit message gives you the commit id\nof the patch at that time and the commit diff gives you the changes\nmade by a refresh. It's mainly useful if you ran refresh and don't\nremember what changes you've added.\n\n>  As for the speed: we'll have to write one blob and one tree per\n>  modified patch, plus one top-level tree and a small constant number of\n>  blobs. (Caveat: my current implementation is too stupid to realize\n>  that not all patches were modified all the time.) These simple\n>  create-an-object-from-data-on-stdin commands should be fast enough\n>  that this won't be a problem (and if a dozen extra calls to git is too\n>  expensive, we'll just have to build a git command that can take them\n>  all in one go).\n\nAs I said in the other e-mail, it needs a run through stg-prof to see\nwhat the impact is with large number of patches.\n\n>  I'd like to try my scheme out first, however. It's potentially more\n>  powerful, since it can be pulled between repositories and maybe even\n>  merged.\n\nThat's interesting indeed (though I don't fully understand all of this).\n\n>  > >   2. The merged stack base is created with a normal recursive\n>  > >      merge.\n>  >\n>  > A recursive merge with the HEAD of another stack containing similar\n>  > patches? If yes, when pushing it is likely that the patches already\n>  > in the base will be emptied during a three-way merge.\n>\n>\n> No, a merge of the stack _bases_, with all patches popped off. And\n>  this would be a regular git merge, so no emptying of patches.\n\nOK, but we would need the StGIT information about stack bases to be\npassed between repositories. And, after this merge, how do you merge\ncommon patches (but maybe slightly modified)?\n\n>  > >   3. When a conflicting patch is pushed, we do the following:\n>  > >\n>  > >        1. For each of .ours, .theirs, .base0, ..., create a new\n>  > >           \"b\" tree just like we do when we normally push a patch.\n>  > >           If there are conflicts, autoresolve them like\n>  > >           merge-recursive does internally.\n>  > >\n>  > >        2. Create the single new \"b\" tree by making a recursive\n>  > >           merge of all these updated \"b\" trees. Represent any\n>  > >           conflicts like we usually do when pushing patches.\n>  >\n>  > My idea is to merge each patch with the corresponding commit in the\n>  > other branch and leave the base unchanged (like \"stg sync\"). The\n>  > difficulty is in identifying which commit from the other branch has\n>  > to be used. We could try guessing by the number of changes or just\n>  > using the subject line, assuming that it won't change (or an extra\n>  > id field in the commit text).\n>\n>\n> I was thinking about the same thing: just match up the patches with\n>  the same name. If the user has renamed a patch, she can coalesce the\n>  two manually.\n\nAh, OK. But how do we pass the patch name information? I think the\ncommit log wouldn't be enough as it can be easily modified. There is\nalso a situation when patches on the remote stack were reordered and\nwith some conflicts fixed. In this case, merging gets even more\ncomplicated (I think darcs solves this by making all the patches\nimmutable but the base feature of StGIT is that patches are easily\nmodifiable).\n\n>  > I find this workflow pretty difficult to implement since the StGIT\n>  > patches are pretty volatile. It might be better to use topic\n>  > branches instead.\n>\n>\n> I agree that it's far from certain that this will be a very useful\n>  workflow. But I'm willing to bet a couple of day's work that it is, so\n>  I'll build a prototype and see.\n\nIt would be nice to allow an easy workflow for people trying to share\nthe same repository and benefit from StGIT. There was a recent thread\non the Linux kernel lists about a new branch, linux-next, which\nincluded some discussions on GIT, patch management, rebasing etc. Some\npeople mentioned that they ended up using classic patch management\n(quilt) and storing the patches in a repository which can be shared\nbetween developers.\n\n-- \nCatalin\n"},{"id":"69463","messageId":"20080221074543.GB8250@diana.vm.bytemark.co.uk","threadId":"12059","inReplyTo":"b0943d9e0802201506w353b5c05vece9f99730d7663c@mail.gmail.com","subject":"Re: new stacked git feature","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-02-21T07:45:43Z","receivedAt":"2008-02-21T07:45:43Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-02-20 23:06:07 +0000, Catalin Marinas wrote:\n\n> On 13/02/2008, Karl Hasselström <kha@treskal.com> wrote:\n>\n> > On 2008-02-13 22:29:34 +0000, Catalin Marinas wrote:\n> >\n> > > On 13/02/2008, Karl Hasselström <kha@treskal.com> wrote:\n> >\n> > I intend to get rid of the current per-patch log. It doesn't save\n> > enough information to be useful anyway.\n>\n> I use it from time to time. The commit message gives you the commit\n> id of the patch at that time and the commit diff gives you the\n> changes made by a refresh. It's mainly useful if you ran refresh and\n> don't remember what changes you've added.\n\nAh, OK. Well, the per-branch log will be able to give you all of that.\n\n> > These simple create-an-object-from-data-on-stdin commands should\n> > be fast enough that this won't be a problem (and if a dozen extra\n> > calls to git is too expensive, we'll just have to build a git\n> > command that can take them all in one go).\n>\n> As I said in the other e-mail, it needs a run through stg-prof to\n> see what the impact is with large number of patches.\n\nAgreed.\n\n> > > A recursive merge with the HEAD of another stack containing\n> > > similar patches? If yes, when pushing it is likely that the\n> > > patches already in the base will be emptied during a three-way\n> > > merge.\n> >\n> > No, a merge of the stack _bases_, with all patches popped off. And\n> > this would be a regular git merge, so no emptying of patches.\n>\n> OK, but we would need the StGIT information about stack bases to be\n> passed between repositories.\n\nYes.\n\n> > > My idea is to merge each patch with the corresponding commit in\n> > > the other branch and leave the base unchanged (like \"stg sync\").\n> > > The difficulty is in identifying which commit from the other\n> > > branch has to be used. We could try guessing by the number of\n> > > changes or just using the subject line, assuming that it won't\n> > > change (or an extra id field in the commit text).\n> >\n> > I was thinking about the same thing: just match up the patches\n> > with the same name. If the user has renamed a patch, she can\n> > coalesce the two manually.\n>\n> Ah, OK. But how do we pass the patch name information? I think the\n> commit log wouldn't be enough as it can be easily modified.\n\nThe per-branch log will contain this information.\n\n> There is also a situation when patches on the remote stack were\n> reordered and with some conflicts fixed. In this case, merging gets\n> even more complicated (I think darcs solves this by making all the\n> patches immutable but the base feature of StGIT is that patches are\n> easily modifiable).\n\nThe scheme I described should be able to handle this. When a patch is\npushed, its base is set, and we can just make a normal 3-way merge.\n\nConsider a stack with two patches, a:A->B and b:B->C (A, B, and C are\ncommits). In one branch, this is modified to a:A->B1 and b:B1->C1; and\nin the other, the patch order is changed so we get b:A->X and a:X->C.\n\nWhen we merge these, the base is unchanged (so still A), and the patch\norder is b, a (since it was changed in one branch but not the other).\n\n  1. First we push b. The A->X variant applies trivially, but the\n     B1->C1 variant needs the standard 3-way merge. The merge is\n     force-resolved (that is, any conflicts are ignored, and just\n     stored in the result tree); call the result Y. Then we make a\n     3-way merge with C as ancestor and X and Y as ours and theirs;\n     the result (possibly fixed up manually by the user) is stored as\n     the new patch top -- call it Z. So now we have pushed b:A->Z.\n\n  2. Then we push a. Both the A->B1 and the X->C variants need 3-way\n     merging, since we apply the patch on top of Z; call the resulting\n     (possibly force-resolved) trees P and Q. Then we make a 3-way\n     merge with B as ancestor and P and Q as ours and theirs; the\n     result (possibly fixed up manually by the user) is stored as the\n     new patch top -- call it R. So now we have pushed a:Z->R.\n\n> It would be nice to allow an easy workflow for people trying to\n> share the same repository and benefit from StGIT. There was a recent\n> thread on the Linux kernel lists about a new branch, linux-next,\n> which included some discussions on GIT, patch management, rebasing\n> etc. Some people mentioned that they ended up using classic patch\n> management (quilt) and storing the patches in a repository which can\n> be shared between developers.\n\nYes, absolutely. And this is precisely what we'll get out of this if\nit pans out. But if it doesn't, the _same_ per-branch log format can\nbe used with a different conflict resolution scheme -- for example, we\ncould compute the diff text for each of the patches and just merge\nthose, which gives the same result as if the user had stored patches\nin the repository.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"69580","messageId":"b0943d9e0802220554x4c0a6c98q39e8b253bb108f1e@mail.gmail.com","threadId":"12059","inReplyTo":"20080221074543.GB8250@diana.vm.bytemark.co.uk","subject":"Re: new stacked git feature","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2008-02-22T13:54:12Z","receivedAt":"2008-02-22T13:54:12Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 21/02/2008, Karl Hasselström <kha@treskal.com> wrote:\n> On 2008-02-20 23:06:07 +0000, Catalin Marinas wrote:\n>  > There is also a situation when patches on the remote stack were\n>  > reordered and with some conflicts fixed. In this case, merging gets\n>  > even more complicated (I think darcs solves this by making all the\n>  > patches immutable but the base feature of StGIT is that patches are\n>  > easily modifiable).\n>\n>\n> The scheme I described should be able to handle this. When a patch is\n>  pushed, its base is set, and we can just make a normal 3-way merge.\n>\n>  Consider a stack with two patches, a:A->B and b:B->C (A, B, and C are\n>  commits). In one branch, this is modified to a:A->B1 and b:B1->C1; and\n>  in the other, the patch order is changed so we get b:A->X and a:X->C.\n>\n>  When we merge these, the base is unchanged (so still A), and the patch\n>  order is b, a (since it was changed in one branch but not the other).\n\n\"stg sync\" does pretty much the same now but in a more manual way. I\ndon't really like the way the conflicts are presented - i.e. you don't\nknow which patch was modified afterwards because the patches lose this\ninformation (they are not topic branches).\n\n>   1. First we push b. The A->X variant applies trivially, but the\n>      B1->C1 variant needs the standard 3-way merge.\n\n3-way merge with X and B1 as base? This leads to the current \"sync\"\nissue, you can't tell which patch was original and which was modified.\n\nJust a thought (not that I'd like this feature in StGIT). Someone\ntried a project some time ago, similar to StGIT, but using topic\nbranches rather than individual commits per patch. The GIT history\nlooked very ugly, especially after re-ordering, but the advantage was\nthat you can avoid rebasing patches and simply merging changes from\nbottom patches into top ones. This would make synchronisation of\npatches between branches much easier.\n\n-- \nCatalin\n"},{"id":"69584","messageId":"20080222151914.GB19172@diana.vm.bytemark.co.uk","threadId":"12059","inReplyTo":"b0943d9e0802220554x4c0a6c98q39e8b253bb108f1e@mail.gmail.com","subject":"Re: new stacked git feature","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2008-02-22T15:19:14Z","receivedAt":"2008-02-22T15:19:14Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2008-02-22 13:54:12 +0000, Catalin Marinas wrote:\n\n> \"stg sync\" does pretty much the same now but in a more manual way. I\n> don't really like the way the conflicts are presented - i.e. you\n> don't know which patch was modified afterwards because the patches\n> lose this information (they are not topic branches).\n\nThis shouldn't be a problem with a per-branch log -- it would have the\nstate of both ancestors before the merge, and the merged state\nafterwards, so nothing should be lost.\n\n> On 21/02/2008, Karl Hasselström <kha@treskal.com> wrote:\n>\n> >   1. First we push b. The A->X variant applies trivially, but the\n> >      B1->C1 variant needs the standard 3-way merge.\n>\n> 3-way merge with X and B1 as base? This leads to the current \"sync\"\n> issue, you can't tell which patch was original and which was\n> modified.\n\nNo. First a 3-way merge (A (base), A, X) with result X, and then a\n3-way merge (A (base), B1, C1) with a result that has to be computed\nby the merge algorithm. Just as if you were pushing both versions of\nthe patch separately.\n\nThe basic algorithm is:\n\n  1. You want to merge patches A->B and C->D. Their closest common\n     ancestors are X0->Y0, X1->Y1, ...\n\n  2. Select the base tree K you want to push the patch on. This is\n     either another patch, or the bottom of the stack.\n\n  3. For each of A->B, C->D, X0->Y0, X1->Y1, ..., push them separately\n     onto K (in parallel, not on top of each other). If there are\n     conflicts, just commit the conflict markers. The patches are now\n     K->B', K->D', K->Y0', K->Y1', ...\n\n  4. Merge B' and D' with Y0', Y1', ... as bases. In case of\n     conflicts, ask the user to resolve them.\n\nObviously, K may be the same as one or more of A, C, X0, X1, ..., so\nthat some or all of the pushes are trivial.\n\n> Just a thought (not that I'd like this feature in StGIT). Someone\n> tried a project some time ago, similar to StGIT, but using topic\n> branches rather than individual commits per patch. The GIT history\n> looked very ugly, especially after re-ordering, but the advantage\n> was that you can avoid rebasing patches and simply merging changes\n> from bottom patches into top ones. This would make synchronisation\n> of patches between branches much easier.\n\nI never really liked that approach; it kind of treats patches as\ntrees, when they are in fact the diff between two trees. It only works\nbecause the boundary between two applied patches is a tree. But the\nuser thinks she's manipulating patches and not patch boundaries, which\nis why the history looks strange.\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"}]}