git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Jens Müller" <blog@tessarakt.de>
To: git@vger.kernel.org
Subject: How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management)
Date: Thu, 01 Aug 2013 00:25:32 +0200	[thread overview]
Message-ID: <ktc2sl$d4f$1@ger.gmane.org> (raw)

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

             reply	other threads:[~2013-07-31 22:30 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-31 22:25 Jens Müller [this message]
2013-07-31 22:50 ` How to hierarchically merge from the root to the leaf of a branch tree? (Patch stack management) Fredrik Gustafsson
2013-08-01  7:28 ` Jakub Narebski
2013-08-02  4:33   ` Jens Müller
2013-08-02 19:18     ` Jens Müller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='ktc2sl$d4f$1@ger.gmane.org' \
    --to=blog@tessarakt.de \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).