{"thread":{"id":"34580","subject":"How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)","startedAt":"2013-07-31T22:25:32Z","lastAt":"2013-08-02T19:18:11Z","messageCount":5,"participants":["Jens Müller","Fredrik Gustafsson","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"224403","messageId":"ktc2sl$d4f$1@ger.gmane.org","threadId":"34580","inReplyTo":null,"subject":"How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)","fromName":"Jens Müller","fromEmail":"blog@tessarakt.de","sentAt":"2013-07-31T22:25:32Z","receivedAt":"2013-07-31T22:25:32Z","isPatch":false,"sender":{"key":"blog@tessarakt.de","avatar":null},"body":"Hi all!\n\nI mainly use Git for version control, but have also tried out Mercurial.\nWhile I don't really like Mercurial in general, the idea of maintaining\nclearly separated patches with Mercurial Queues (MQ) is quite appealing.\nTherefore, I am looking for something similar (but easier to use, more\n\"gitty\" and maybe even more powerful) in Git.\n\nSo I will first explain what I have in mind:\n\nAs an example, let's say I am doing test-driven development. My master\nbranch follows the main repository of the software. Branched out from\nthat, I have a branch called \"feature-test\", and branched out from that,\n\"feature-implementation\":\n\n    master\n    |_ feature-test\n       |_ feature-implementation\n\nFor each branch, I remember the parent branch.\n\nImplementation would then work like this: I checkout feature-test and\nwrite some test. Then I checkout feature-implementation, rebase it to\nthe current status of feature-test and write the implemenation. And so on.\n\nAt some point, I update master, and then rebase both feature-test and\nfeature-implementation.\n\nAs a side note: Instead of rebasing the branches, an alternative would\nbe to merge the changes from the parent branch. This makes conflict\nresolution easier. The cascading merge through the chain of branches is\nlike a rebase, anyway.\n\nOf course, the process described above contains a lot of tedious manual\nwork. So I am looking for tooling for tasks like the following:\n\n * While on a branch, pull master from a remote branch it tracks and\nmerge the changes down the chain of branches. When a conflict is\nencountered, switch to the branch where it occured, allow the user to\nresolve the conflict, and then continue the cascading merge (similar to\nwhat git rebase does when it encounters a conflict).\n * When checking out a branch, cascadingly merge from the ancestor\nbranches automatically. Conflict handling should work as in the previous\npoint.\n\nThe cascading merge should not check out master and the branches below\nit (unless necessary to resolve conflicts), in order to avoid rebuilds\ndue to touched but unchanged files.\n\nDo these requirements make sense? Is there some existing tool with a\nsimilar workflow?\n\nBR - Jens\n"},{"id":"224406","messageId":"20130731225051.GI19369@paksenarrion.iveqy.com","threadId":"34580","inReplyTo":"ktc2sl$d4f$1@ger.gmane.org","subject":"Re: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2013-07-31T22:50:51Z","receivedAt":"2013-07-31T22:50:51Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Thu, Aug 01, 2013 at 12:25:32AM +0200, Jens Müller wrote:\n> Hi all!\n> \n> I mainly use Git for version control, but have also tried out Mercurial.\n> While I don't really like Mercurial in general, the idea of maintaining\n> clearly separated patches with Mercurial Queues (MQ) is quite appealing.\n> Therefore, I am looking for something similar (but easier to use, more\n> \"gitty\" and maybe even more powerful) in Git.\n> \n> So I will first explain what I have in mind:\n> \n> As an example, let's say I am doing test-driven development. My master\n> branch follows the main repository of the software. Branched out from\n> that, I have a branch called \"feature-test\", and branched out from that,\n> \"feature-implementation\":\n> \n>     master\n>     |_ feature-test\n>        |_ feature-implementation\n> \n> For each branch, I remember the parent branch.\n> \n> Implementation would then work like this: I checkout feature-test and\n> write some test. Then I checkout feature-implementation, rebase it to\n> the current status of feature-test and write the implemenation. And so on.\n> \n> At some point, I update master, and then rebase both feature-test and\n> feature-implementation.\n> \n> As a side note: Instead of rebasing the branches, an alternative would\n> be to merge the changes from the parent branch. This makes conflict\n> resolution easier. The cascading merge through the chain of branches is\n> like a rebase, anyway.\n> \n> Of course, the process described above contains a lot of tedious manual\n> work. So I am looking for tooling for tasks like the following:\n> \n>  * While on a branch, pull master from a remote branch it tracks and\n> merge the changes down the chain of branches. When a conflict is\n> encountered, switch to the branch where it occured, allow the user to\n> resolve the conflict, and then continue the cascading merge (similar to\n> what git rebase does when it encounters a conflict).\n>  * When checking out a branch, cascadingly merge from the ancestor\n> branches automatically. Conflict handling should work as in the previous\n> point.\n> \n> The cascading merge should not check out master and the branches below\n> it (unless necessary to resolve conflicts), in order to avoid rebuilds\n> due to touched but unchanged files.\n> \n> Do these requirements make sense? Is there some existing tool with a\n> similar workflow?\n> \n> BR - Jens\n> \n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n\nSince all commits in feature-test is in feature-implementation,\nhow about rebase feature-implementation on master and then move the\nbranch pointer for feature-test to the new commit (git reset)?\n\nIf it's still not trivial enough, a script for this would be fairly easy\nto implement (if I don't miss anything big here).\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"224416","messageId":"loom.20130801T092209-291@post.gmane.org","threadId":"34580","inReplyTo":"ktc2sl$d4f$1@ger.gmane.org","subject":"Re: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2013-08-01T07:28:08Z","receivedAt":"2013-08-01T07:28:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jens Müller <blog <at> tessarakt.de> writes:\n\n> \n> Hi all!\n> \n> I mainly use Git for version control, but have also tried out Mercurial.\n> While I don't really like Mercurial in general, the idea of maintaining\n> clearly separated patches with Mercurial Queues (MQ) is quite appealing.\n> Therefore, I am looking for something similar (but easier to use, more\n> \"gitty\" and maybe even more powerful) in Git.\n\nOn Git Homepage and on Git Wiki you can find a (partial) list of Git\ntools.  Among those there are patch-management interface tools, such\nas Guilt (formerly Git Queues (GQ), inspired by Mercurial Queues (MQ))\nand StGit.\n\nThere is also TopGit, which is feature-branch management tools (which\nseems like what you want, from what you written below).\n\n\nUnfortunately I don't know which of those projects are actively\nmaintained...\n\n> So I will first explain what I have in mind:\n> \n> As an example, let's say I am doing test-driven development. My master\n> branch follows the main repository of the software. Branched out from\n> that, I have a branch called \"feature-test\", and branched out from that,\n> \"feature-implementation\":\n> \n>     master\n>     |_ feature-test\n>        |_ feature-implementation\n> \n> For each branch, I remember the parent branch.\n> \n> Implementation would then work like this: I checkout feature-test and\n> write some test. Then I checkout feature-implementation, rebase it to\n> the current status of feature-test and write the implemenation. And so on.\n[...]\n"},{"id":"224441","messageId":"ktfcq1$v8a$1@ger.gmane.org","threadId":"34580","inReplyTo":"loom.20130801T092209-291@post.gmane.org","subject":"Re: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)","fromName":"Jens Müller","fromEmail":"blog@tessarakt.de","sentAt":"2013-08-02T04:33:12Z","receivedAt":"2013-08-02T04:33:12Z","isPatch":false,"sender":{"key":"blog@tessarakt.de","avatar":null},"body":"Am 01.08.2013 09:28, schrieb Jakub Narebski:\n> There is also TopGit, which is feature-branch management tools (which\n> seems like what you want, from what you written below).\n\nIndeed, thank you very much for pointing me to it. I have not read the\nwhole documentation, but it sounds promising enough that I will try it\nout with some real patches I have flying around and need to combine and\ndo further development on.\n\nJens\n"},{"id":"224462","messageId":"kth0lc$48q$1@ger.gmane.org","threadId":"34580","inReplyTo":"ktfcq1$v8a$1@ger.gmane.org","subject":"Re: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)","fromName":"Jens Müller","fromEmail":"blog@tessarakt.de","sentAt":"2013-08-02T19:18:11Z","receivedAt":"2013-08-02T19:18:11Z","isPatch":false,"sender":{"key":"blog@tessarakt.de","avatar":null},"body":"Am 02.08.2013 06:33, schrieb Jens Müller:\n> Am 01.08.2013 09:28, schrieb Jakub Narebski:\n>> > There is also TopGit, which is feature-branch management tools (which\n>> > seems like what you want, from what you written below).\n> Indeed, thank you very much for pointing me to it. I have not read the\n> whole documentation, but it sounds promising enough that I will try it\n> out with some real patches I have flying around and need to combine and\n> do further development on.\n\nSeems nice until now, but lacks some essential functionality ... For\nexample, you can add a dependency to a parent branch, but not remove it ...\n"}]}