At Sat, 28 Nov 2009 21:15:05 -0800, Junio C Hamano <gitster@xxxxxxxxx> 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 <woods@xxxxxxxxxxx> Planix, Inc. <woods@xxxxxxxxxx> Secrets of the Weird <woods@xxxxxxxxx>
Attachment:
pgp9LlPRloUDr.pgp
Description: PGP signature