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-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
> 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
> 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 majord...@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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html