Re: "git merge" merges too much!

From: Greg A. Woods <woods@planix.com>
Date: Dec 1, 2009, 18:52 UTC
Message-ID: <m1NFXpl-000knKC@most.weird.com>
In-Reply-To: <20091130192212.GA23181@dpotapov.dyndns.org>

At Mon, 30 Nov 2009 22:22:12 +0300, Dmitry Potapov <dpotapov@gmail.com> wrote:
Subject: Re: "git merge" merges too much!

Show 5 quoted lines

> 
> The key difference comparing to what you may got used is that branches
> are normally based on the oldest branch in what this feature may be
> included. Thus normally changes are not backported to old branches,
> because you can merge them directly.

Hmmm... the idea of creating topic branches based on the oldest branch where the feature might be used is indeed neither intuitive, nor is it mentioned anywhere I've so far read about using topic branches in Git.

To use topic branches effectively this way, especially in managing local and custom changes to a large remote project where separate working directories are needed for long-running builds, I think some additional software configuration management tool must be used to create "configuration" branches where all the desired change sets (topic branches) are merged.

I spent half my dreaming time early this morning running through scenarios of how to use topic branches, with true merging (not re-basing), in a usable work-flow.

At the moment I'm leaning towards a process where the configuration branch is re-created for every build -- i.e. the merges are redone from every topic branch to a freshly configured branch forked from the locally supported release branch, hopefully making use of git-rerere to solve most conflicts in as automated a fashion as is possible.

This may not be a sane thing to do though -- it may be too much work to do for every fix. It somewhat goes against the current natural trend in many of the projects I work on to develop changes on the trunk and then back-port (some of) them to release branches.

Perhaps Stacked-Git really is the best answer. I will have to investigate more.

Show 8 quoted lines

> > > Yes, you must cherry-pick or use rebase (which is a more featureful
> > > version of the pipeline you mentioned).
> > 
> > "git rebase" will not work for me unless it grows a "copy" option ,
> > i.e. one which does not delete the original branch (i.e. avoids the
> > "reset" phase of its operation).
> 
> There is no reset phase...

By "reset phase" I meant this part, from git-rebase(1):

       The current branch is reset to <upstream>, or <newbase> if the --onto
       option was supplied. This has the exact same effect as git reset --hard
       <upstream> (or <newbase>).

Show 9 quoted lines

> It is just reassigning the head of branch to
> point to a different commit-id. If you want to copy a branch instead of
> rebasing the old one, you create a new branch (a new name) that points
> to the same commit as the branch that you want to copy, after that you
> rebase this new branch. You can do that like this:
> 
> $ git branch new-foo foo
> 
> $ git rebase --onto newbase oldbase new-foo

Hmmm.... I'll have to think about that. It makes some sense, but I don't intuitively read the command-line parameters well enough to predict the outcome in all of the scenarios I'm interested in.

what is "oldbase" there? I'm guessing it means "base of foo" (and for the moment, "new-foo" too)?

It's confusing because the manual page uses the word "upstream" to describe this parameter.

From my experiments it looks like what I might want to do to copy a local branch to port its changes from one release branch to another is something like this (where local-v2.0 is a branch with local changes forked from release branch REL-v2.0, and I want to back-port these changes to a new local branch forked from the release branch REL-v1.0):

	$ git branch local-base-v1.0 REL-v1.0	# mark base of new branch
	$ git branch local-v1.0 local-v2.0	# dup head of src branch
	$ git rebase --onto local-base-v1.0 REL-v2.0 local-v1.0
	$ git branch -d local-base-v1.0

The first and last steps may not be necessary if REL-v1.0 really is a branch, but in my play project it is just a tag on the trunk. In the case that it were really already a branch then hopefully this would do:

	$ git branch local-v1.0 local-v2.0	# dup head of src branch
	$ git rebase --onto REL-v1.0 REL-v2.0 local-v1.0

The trick here seems to be to invent the name of the new branch based on where it's going to be rebased to.

I think this does suffice very nicely as a "git copy" operation!

Show 5 quoted lines

> The "copy" does not have the problem of rebase, but it has a different
> problem: You have two series of commits instead of one. If you found
> a bug in one of those commits, you will have to patch each series
> separately. Also, git merge may produce additional conflicts... So,
> copying commits is not something that I would recommend to do often.

Indeed.

-- 
						Greg A. Woods

+1 416 218-0098                VE3TCP          RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>      Secrets of the Weird <woods@weird.com>