Re: git-svn merge helper

> 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.

> 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.