Re: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)

[Fredrik Gustafsson <iveqy@iveqy.com>]

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@vger.kernel.org
> 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@iveqy.com