Björn Steinbrink wrote:
quoted text
> 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 <hjemli@gmail.com>
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 <hjemli@gmail.com>
    Signed-off-by: Junio C Hamano <gitster@pobox.com>

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html