Subject: Re: "git merge" merges too much!

From: "Greg A. Woods" <[email-masked]>
Date: Mon, 30 Nov 2009 13:40:38 -0500

At Sat, 28 Nov 2009 21:15:05 -0800, Junio C Hamano <[email-masked]> wrote:
Subject: Re: "git merge" merges too much!
> 
> In order to make things smoother and easier in the future, you may want to
> learn "topic branch" workflows (found in many git tutorial material).

I was thinking hard about topic branches too, but I'm still having a
hard time figuring out how they might work best for my purposes.

One hard problem is how to create "clean" topic branches and use them
effectively when the local working environment requires all or many of
the whole set of local changes.  Bootstrapping these local changes as
topic branches may be one thing; but going further with topic branches
to create local features or fixes, some of which are to be submitted
upstream for eventual inclusion in the origin/master branch, and others
of which will only ever be ported forward to future official releases,
is quite another thing all together.

These new-feature topic branches will have to be worked on from the
main (most well supported) local branch, which will be forked from the
main release branch (or based on the trunk at the main release tag), but
yet care will have to be taken to make sure the merge doesn't include
dependencies on local-only changes (i.e. so that it can be safely
submitted upstream).

Some projects also only wish to receive patches that work against their
trunk branch, so a given local topic branch will have to be merged onto
yet another branch forking from the trunk where it may likely encounter
conflicts (since the topic branch is based on older code from an
existing release).  This isn't really a Git problem I suppose, except
for the fact that it means the lack of easy support for multiple working
directories that track different branches makes this kind of development
somewhat more difficult to do with Git than with, say, CVS.

While it may be quite convenient in small projects to quickly move a
single working directory from one branch to another and do various
builds and tests from the result, large projects (say where a compile
takes the better part of a working day or more and where testing
requires multi-day processes) demand that working directories remain
"stable", and multiple lines of development therefore demand multiple
working directories.  Developing procedures around Git to manage this
with "push" and "pull" into multiple local copies of the repository,
each with their own working directory, is of course possible (though not
necessarily easy), but once again if the repositories are similarly huge
then it may not be possible to support multiple repo copies for each
developer in a given working environment.

So, ideally it seems from my understanding at this point that I want to
be able to repeatedly merge topic branch changes (as they are worked on)
into multiple local configuration branches (each of which perhaps
includes multiple local topics and other changes), each of which pushes
its changes out into possibly multiple working directories.

> But it is too late for the history you already created; "cherry-pick" is
> your friend to recover from the shape of your existing history.

The problem is that it's not _my_ existing history -- it's from the
remote project I'm trying to work with.

I think you'll agree there nothing wrong with a project using tags alone
to manage its releases.

However this means I've got to work out how to do merges of my local
changes onto multiple locally created branches which fork off from these
tags.  Perhaps using this cherry-pick tool is truly the best I can do in
this situation.

(it makes me worry though about how I might manage a super-project which
pulls from many remote sub-projects (and which includes large amounts of
its own code) where some of those remote projects use release branches,
and some just use tags, etc.)

-- 
						Greg A. Woods

+1 416 218-0098                VE3TCP          RoboHack <[email-masked]>
Planix, Inc. <[email-masked]>      Secrets of the Weird <[email-masked]>