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

2013-08-02 Thread Jens Müller
Am 02.08.2013 06:33, schrieb Jens Müller:
 Am 01.08.2013 09:28, schrieb Jakub Narebski:
  There is also TopGit, which is feature-branch management tools (which
  seems like what you want, from what you written below).
 Indeed, thank you very much for pointing me to it. I have not read the
 whole documentation, but it sounds promising enough that I will try it
 out with some real patches I have flying around and need to combine and
 do further development on.

Seems nice until now, but lacks some essential functionality ... For
example, you can add a dependency to a parent branch, but not remove it ...

--
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


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

2013-08-01 Thread Jakub Narebski
Jens Müller blog at tessarakt.de writes:

 
 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.

On Git Homepage and on Git Wiki you can find a (partial) list of Git
tools.  Among those there are patch-management interface tools, such
as Guilt (formerly Git Queues (GQ), inspired by Mercurial Queues (MQ))
and StGit.

There is also TopGit, which is feature-branch management tools (which
seems like what you want, from what you written below).


Unfortunately I don't know which of those projects are actively
maintained...

 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.
[...]

--
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


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

2013-08-01 Thread Jens Müller
Am 01.08.2013 09:28, schrieb Jakub Narebski:
 There is also TopGit, which is feature-branch management tools (which
 seems like what you want, from what you written below).

Indeed, thank you very much for pointing me to it. I have not read the
whole documentation, but it sounds promising enough that I will try it
out with some real patches I have flying around and need to combine and
do further development on.

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


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

2013-07-31 Thread Fredrik Gustafsson
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 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
Fredrik Gustafsson

tel: 0733-608274
e-post: iv...@iveqy.com
--
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