On Thu, Aug 01, 2013 at 12:25:32AM +0200, Jens Müller wrote: > Hi all! > > I mainly use Git for version control, but have also tried out Mercurial. > While I don't really like Mercurial in general, the idea of maintaining > clearly separated patches with Mercurial Queues (MQ) is quite appealing. > Therefore, I am looking for something similar (but easier to use, more > "gitty" and maybe even more powerful) in Git. > > So I will first explain what I have in mind: > > As an example, let's say I am doing test-driven development. My master > branch follows the main repository of the software. Branched out from > that, I have a branch called "feature-test", and branched out from that, > "feature-implementation": > > master > |_ feature-test > |_ feature-implementation > > For each branch, I remember the parent branch. > > Implementation would then work like this: I checkout feature-test and > write some test. Then I checkout feature-implementation, rebase it to > the current status of feature-test and write the implemenation. And so on. > > At some point, I update master, and then rebase both feature-test and > feature-implementation. > > As a side note: Instead of rebasing the branches, an alternative would > be to merge the changes from the parent branch. This makes conflict > resolution easier. The cascading merge through the chain of branches is > like a rebase, anyway. > > Of course, the process described above contains a lot of tedious manual > work. So I am looking for tooling for tasks like the following: > > * While on a branch, pull master from a remote branch it tracks and > merge the changes down the chain of branches. When a conflict is > encountered, switch to the branch where it occured, allow the user to > resolve the conflict, and then continue the cascading merge (similar to > what git rebase does when it encounters a conflict). > * When checking out a branch, cascadingly merge from the ancestor > branches automatically. Conflict handling should work as in the previous > point. > > The cascading merge should not check out master and the branches below > it (unless necessary to resolve conflicts), in order to avoid rebuilds > due to touched but unchanged files. > > Do these requirements make sense? Is there some existing tool with a > similar workflow? > > BR - Jens > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html Since all commits in feature-test is in feature-implementation, how about rebase feature-implementation on master and then move the branch pointer for feature-test to the new commit (git reset)? If it's still not trivial enough, a script for this would be fairly easy to implement (if I don't miss anything big here). -- Med vänliga hälsningar Fredrik Gustafsson tel: 0733-608274 e-post: iveqy@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html