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 <hjemli@xxxxxxxxx>
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@xxxxxxxxx>
Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>
--
Andreas Ericsson andreas.ericsson@xxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
