On 2007.10.02 20:42:52 -0400, Steven Walter wrote:
quoted text
> 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.

quoted text
> 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?

Thanks,
Björn

[1]
http://lists-archives.org/git/419374-git-merge-and-merge-message.html
-
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