Idea: "live branches"?

Idea: "live branches"?

[Jan Rychter]

I've been trying out a number of DVCS tools recently and finally found
that git is the best fit for me. There is one thing I found missing,
though.

The problem is that there are usually two distinct concepts:

-- topic branches, representing longer-term ongoing development in a
   certain direction, large-scale features, etc,
-- patches that represent complete functionality, to be committed
   upstream, but continuously improved.

My local repositories are usually a combination of both. I will often
have a number of feature patches that I don't want to push upstream just
yet. These patches change often. My topic branches will all want to use
them, in their latest form/revision. This is not a workflow that you can
easily represent with any of today's DVCS tools. One can do this with
careful cherry-picking and merging, but it is a lot of manual work and
clutters up history with lots of merge commits.

StGIT is *almost* there. It lets you manage a pile of patches, modify
them, apply them selectively, as well as update the mainstream
repository and reapply local patches. It fails in two ways: 1) when you
want to reuse the same patches on multiple branches. One-way migration
is doable (not pleasant, but doable), but if you modify a patch in one
of your branches, your other branches which use the same patch will not
see the change. And 2) StGIT patches are simple by design, and you can't
have internal commit history within a patch, which is a problem for
larger features.

Which brings me to my point. I think we need a system that can maintain
"live branches". We already have impressive systems for dealing with
patches and we have made the patch into a first-class citizen of our
software development world. Now, instead of statically tracking commits
and following a one-way development history, let's have live branches --
branches that can change, causing code that depends on them to change.

The way this would work is I would have one or two long-term development
branches, and each of those would depend on a list of "live branches",
managed by a tool similar to StGIT. I should be able to commit to either
the main development branch, or to one of the "live branches", in which
case I should be able to easily "resync" the main development branch (do
a merge or a rebase, but I would prefer the tool to first remove old
merge commits, so as not to clutter history). 

The tool should also let me pick a commit I've made and move it to one
of the live branches easily (similar to stgit).

Does this make sense, or am I missing something very obvious?

--J.

PS: I am obviously aware that this is something which is suitable for
local development work only.

Re: Idea: "live branches"?

[Avery Pennarun]

On 7/9/08, Jan Rychter <jan@rychter.com> wrote:
>  The way this would work is I would have one or two long-term development
>  branches, and each of those would depend on a list of "live branches",
>  managed by a tool similar to StGIT. I should be able to commit to either
>  the main development branch, or to one of the "live branches", in which
>  case I should be able to easily "resync" the main development branch (do
>  a merge or a rebase, but I would prefer the tool to first remove old
>  merge commits, so as not to clutter history).

Hmm, git rebase already removes old merge commits.  In my own
workflow, I tend to do repeated merges of the "live branch" into my
feature branches during development, then do a rebase occasionally to
clean up the patch set, especially right before merging it into
master.  This seems pretty painless to me.  What specific problem are
you having that prevents this from working?

Have fun,

Avery

Re: Idea: "live branches"?

[Johannes Schindelin]

Hi,

On Wed, 9 Jul 2008, Jan Rychter wrote:

> Which brings me to my point. I think we need a system that can maintain 
> "live branches". We already have impressive systems for dealing with 
> patches and we have made the patch into a first-class citizen of our 
> software development world. Now, instead of statically tracking commits 
> and following a one-way development history, let's have live branches -- 
> branches that can change, causing code that depends on them to change.
> 
> The way this would work is I would have one or two long-term development 
> branches, and each of those would depend on a list of "live branches", 
> managed by a tool similar to StGIT. I should be able to commit to either 
> the main development branch, or to one of the "live branches", in which 
> case I should be able to easily "resync" the main development branch (do 
> a merge or a rebase, but I would prefer the tool to first remove old 
> merge commits, so as not to clutter history).

It should be very easy to write a small shell script which expects some 
config variable

	branch.<currentBranchName>.liveBranches

which contains a list of (local) branches.  It would then just look which 
of those branches contains newer commits, finds the merges that pulled 
those branches in, and redoes those merges (and the commits).  It would 
rely heavily on "git reset" and on an untampered-with merge message.

The main loop would look a little bit like this:

	git rev-list --parents <first-merge-to-be-replaced>^ |
	while read commit parent otherparents
	do
		case "$otherparents" in
		'')
			git cherry-pick $commit
		;;
		*)
			case " $commit " in
			" $mergestoberedone ")
			;;
			*)
				message="$(git cat-file commit $commit |
					sed '/^$/q')"
				git merge -m "$message" $otherparents
			;;
		esac
	done
	# merge changes branches

No wizardry required.

> The tool should also let me pick a commit I've made and move it to one 
> of the live branches easily (similar to stgit).

That is relatively simple, using "git checkout <branch> && git cherry-pick 
<commit> && git checkout <formerBranch> && git resync-live-branches".

I strongly suggest writing that script, and seeing if it is useful for 
you.  If it is, just submit it and earn all the glory.

Hth,
Dscho