From: Andreas Ericsson Date: Wed, 03 Oct 2007 11:40:05 GMT Subject: Re: git-svn merge helper Message-ID: <47037F95.2040605@op5.se> In-Reply-To: <20071003010233.GA8610@atjola.homenet> Björn Steinbrink wrote: > On 2007.10.02 20:42:52 -0400, Steven Walter wrote: >> On Wed, Oct 03, 2007 at 12:38:13AM +0200, Björn Steinbrink wrote: >>>> The other option is to have a "build" branch. By example: >>>> >>>> git checkout build >>>> git reset --hard master >>>> git merge mybranch >>>> make >>>> >>>> In that way, I have branch with the latest changes from head and the >>>> changes from mybranch together. The downside to this method is that you >>>> may have to repeated resolve merges. Despite the downsides, I find >>>> these two methods to work quite well. >>> Thanks, but it makes no difference here, it stil results in a fast >>> forward. This is a small test case which exhibits the behaviour and >>> matches my current workflow with git-svn (except for the dcommits): >>> >>> git init >>> echo Hi > file1; git add file1; git commit -m file1 >>> git checkout -b branch >>> echo Hi > file2; git add file2; git commit -m file2 >>> git checkout master >>> echo Hi > file3; git add file3; git commit -m file3 >>> git checkout branch >>> git merge master >>> >>> # Then I'd normally do the following which causes a fast forward >>> #git checkout master >>> #git merge branch >>> >>> # Now I tried this, which also results in a fast-forward: >>> git checkout -b merge >>> git reset --hard master >>> git merge branch >> I believe you misunderstood my suggestion. In using a "build" branch, >> you would not merge master into branch, as you did above. Instead, you >> would create a third, unpublished branch to hold the merge. > > Almost though so. > >> At the same time, I have a slightly better understanding of what it is >> you're trying to do. If you are trying to keep up an SVN-like workflow >> (namely pulling changes from trunk into a branch from time to time), >> then my solution probably isn't suitable for you. However, you might >> consider why you actually /need/ to do that, outside of SVN convention. > > Due to the same reason for which the branch needs to be public at all, > there are other people who want to follow it and test it, while there > are external dependencies that currently change quite often. So I need > to get the relevant changes from trunk into my branch anyway, even with > svn conventions put aside (well, unless I force everyone else to merge > over and over again). And as sometimes others commit to that branch, too > (you just have to love that), keeping a separate branch for the final > merge isn't so nice either, as I'd need to constantly cherry-pick those > changes then and probably get even more conflicts along the way. > > That said, Google finally liked some of the search terms that I threw at > it and revealed a thread [1] from march, where Linus was torn on whether > or not a --no-fast-forward option should be introduced. That sounds like > it would help here, any chance of getting such a thing? > Is this what you're looking for? It's in the 'next' branch in git.git. commit d66424c4ac661c69640765260235452499d80378 Author: Lars Hjemli Date: Mon Sep 24 00:51:45 2007 +0200 git-merge: add --ff and --no-ff options These new options can be used to control the policy for fast-forward merges: --ff allows it (this is the default) while --no-ff will create a merge commit. Signed-off-by: Lars Hjemli Signed-off-by: Junio C Hamano -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231