[PATCH] git-merge: add option --no-ff

[PATCH] git-merge: add option --no-ff

[Lars Hjemli]

This new option forces all merges to create a "true" merge commit, i.e. a
commit with multiple parents.

Although a fast-forward would normally be The Right Thing, it isn't when the
branches to be merged originated in subversion and the merge commit will
be pushed back by means of 'git svn dcommit'. In these cases, a fast-
forward merge simply will not work.

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---
 Documentation/merge-options.txt |    4 ++++
 git-merge.sh                    |   13 +++++++++++--
 t/t6028-merge-up-to-date.sh     |   25 +++++++++++++++++++++++++
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index d64c259..ed28017 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -25,3 +25,7 @@
 	If there is no `-s` option, a built-in list of strategies
 	is used instead (`git-merge-recursive` when merging a single
 	head, `git-merge-octopus` otherwise).
+
+--no-ff::
+	Force the creation of a merge commit even when the merge would
+	have resolved as a fast-forward operation.
diff --git a/git-merge.sh b/git-merge.sh
index 3a01db0..13b98e6 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,7 +3,7 @@
 # Copyright (c) 2005 Junio C Hamano
 #
 
-USAGE='[-n] [--summary] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
+USAGE='[-n] [--summary] [--no-commit] [--no-ff] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
 
 SUBDIRECTORY_OK=Yes
 . git-sh-setup
@@ -165,6 +165,10 @@ do
 		merge_msg="$1"
 		have_message=t
 		;;
+	--no-ff)
+		no_ff=t
+		no_fast_forward_strategies=$all_strategies
+		;;
 	-*)	usage ;;
 	*)	break ;;
 	esac
@@ -444,7 +448,12 @@ done
 # auto resolved the merge cleanly.
 if test '' != "$result_tree"
 then
-    parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+    if test $no_ff = 't'
+    then
+        parents=$(git rev-parse "$head" "$@" | sed -e 's/^/-p /')
+    else
+        parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+    fi
     result_commit=$(printf '%s\n' "$merge_msg" | git commit-tree $result_tree $parents) || exit
     finish "$result_commit" "Merge made by $wt_strategy."
     dropsave
diff --git a/t/t6028-merge-up-to-date.sh b/t/t6028-merge-up-to-date.sh
index f8f3e3f..afd74e2 100755
--- a/t/t6028-merge-up-to-date.sh
+++ b/t/t6028-merge-up-to-date.sh
@@ -10,12 +10,14 @@ test_expect_success setup '
 	test_tick &&
 	git commit -m initial &&
 	git tag c0 &&
+	c0=$(git rev-parse c0)
 
 	echo second >file &&
 	git add file &&
 	test_tick &&
 	git commit -m second &&
 	git tag c1 &&
+	c1=$(git rev-parse c1)
 	git branch test
 '
 
@@ -41,6 +43,16 @@ test_expect_success 'merge -s recursive fast-forward' '
 
 '
 
+test_expect_success 'merge -s recursive --no-ff' '
+
+	git reset --hard c0 &&
+	test_tick &&
+	git merge -s recursive --no-ff c1 &&
+	test $c0 = $(git rev-parse HEAD^1) &&
+	test $c1 = $(git rev-parse HEAD^2)
+
+'
+
 test_expect_success 'merge -s ours up-to-date' '
 
 	git reset --hard c1 &&
@@ -63,6 +75,19 @@ test_expect_success 'merge -s ours fast-forward' '
 
 '
 
+test_expect_success 'merge -s ours --no-ff' '
+
+	git reset --hard c0 &&
+	test_tick &&
+	git merge -s ours --no-ff c1 &&
+	expect=$(git rev-parse c0^{tree}) &&
+	current=$(git rev-parse HEAD^{tree}) &&
+	test "$expect" = "$current" &&
+	test $c0 = $(git rev-parse HEAD^1) &&
+	test $c1 = $(git rev-parse HEAD^2)
+
+'
+
 test_expect_success 'merge -s subtree up-to-date' '
 
 	git reset --hard c1 &&
-- 
1.5.3.1.92.g2f5e

Re: [PATCH] git-merge: add option --no-ff

[Andreas Ericsson]

Lars Hjemli wrote:
> This new option forces all merges to create a "true" merge commit, i.e. a
> commit with multiple parents.
> 
> Although a fast-forward would normally be The Right Thing, it isn't when the
> branches to be merged originated in subversion and the merge commit will
> be pushed back by means of 'git svn dcommit'. In these cases, a fast-
> forward merge simply will not work.
> 
>  	If there is no `-s` option, a built-in list of strategies
>  	is used instead (`git-merge-recursive` when merging a single
>  	head, `git-merge-octopus` otherwise).
> +
> +--no-ff::
> +	Force the creation of a merge commit even when the merge would
> +	have resolved as a fast-forward operation.

+ Although a fast-forward would normally be The Right Thing, it isn't when the
+ branches to be merged originated in subversion and the merge commit will
+ be pushed back by means of 'git svn dcommit'. In these cases, a fast-
+ forward merge simply will not work.

Otherwise someone will sit down and try to figure out why this is necessary.

I'm having trouble understanding why this is needed, but I'll take your word
for it ;-)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

On 9/17/07, Andreas Ericsson <ae@op5.se> wrote:
> Lars Hjemli wrote:
> > This new option forces all merges to create a "true" merge commit, i.e. a
> > commit with multiple parents.
> >
> > Although a fast-forward would normally be The Right Thing, it isn't when the
> > branches to be merged originated in subversion and the merge commit will
> > be pushed back by means of 'git svn dcommit'. In these cases, a fast-
> > forward merge simply will not work.
> >
> >       If there is no `-s` option, a built-in list of strategies
> >       is used instead (`git-merge-recursive` when merging a single
> >       head, `git-merge-octopus` otherwise).
> > +
> > +--no-ff::
> > +     Force the creation of a merge commit even when the merge would
> > +     have resolved as a fast-forward operation.
>
> + Although a fast-forward would normally be The Right Thing, it isn't when the
> + branches to be merged originated in subversion and the merge commit will
> + be pushed back by means of 'git svn dcommit'. In these cases, a fast-
> + forward merge simply will not work.
>
> Otherwise someone will sit down and try to figure out why this is necessary.

True.

> I'm having trouble understanding why this is needed, but I'll take your word
> for it ;-)

I'll try to explain:

When 'git-svn dcommit' decides which commits it should push back
subversion, it scans the output from 'git-log --first-parent HEAD'
looking for embedded 'git-svn-id' lines. These lines contain the url
of the upstream subversion repository + the subversion revision
number. So the problem with fast-forward merges of subversion branches
is that the output from 'git-log --first-parent HEAD' will show
commits from the wrong subversion branch (the fast-forwarded commits).

This could maybe be fixed in git-svn if it learned a different way of
discovering the upstream subversion branch, but then it would make
git-svn commit n revisions to subversion (again, the fast-forwarded
commits) instead of a single merge-commit. This would look (in
subversion) like a series of n cherry-picks from the merged branch.

Btw: maybe the --no-ff section in merge-options.txt could just link to
git-svn.txt, which in turn could have some lengthy explanation about
merge --no-ff/dcommit behaviour?

--
larsh

Re: [PATCH] git-merge: add option --no-ff

[Johannes Schindelin]

Hi,

On Mon, 17 Sep 2007, Lars Hjemli wrote:

> When 'git-svn dcommit' decides which commits it should push back
> subversion, it scans the output from 'git-log --first-parent HEAD'
> looking for embedded 'git-svn-id' lines. These lines contain the url
> of the upstream subversion repository + the subversion revision
> number.

> So the problem with fast-forward merges of subversion branches is that 
> the output from 'git-log --first-parent HEAD' will show commits from the 
> wrong subversion branch (the fast-forwarded commits).

Ah, I think I know what you're trying to get at.  But "git svn fetch && 
git rebase git-svn" might be a better approach than "git svn fetch && git 
merge --no-ff git-svn", no?

Ciao,
Dscho

Re: [PATCH] git-merge: add option --no-ff

[Chris Shoemaker]

On Mon, Sep 17, 2007 at 02:23:38PM +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Mon, 17 Sep 2007, Lars Hjemli wrote:
> 
> > When 'git-svn dcommit' decides which commits it should push back
> > subversion, it scans the output from 'git-log --first-parent HEAD'
> > looking for embedded 'git-svn-id' lines. These lines contain the url
> > of the upstream subversion repository + the subversion revision
> > number.
> 
> > So the problem with fast-forward merges of subversion branches is that 
> > the output from 'git-log --first-parent HEAD' will show commits from the 
> > wrong subversion branch (the fast-forwarded commits).
> 
> Ah, I think I know what you're trying to get at.  But "git svn fetch && 
> git rebase git-svn" might be a better approach [...]

BTW, this is spelled "git svn rebase" these days.

-chris

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

On 9/17/07, Chris Shoemaker <c.shoemaker@cox.net> wrote:
> On Mon, Sep 17, 2007 at 02:23:38PM +0100, Johannes Schindelin wrote:
> > Ah, I think I know what you're trying to get at.  But "git svn fetch &&
> > git rebase git-svn" might be a better approach [...]
>
> BTW, this is spelled "git svn rebase" these days.

Not in this case, since 'git-svn rebase' would fall in the same trap
as 'git-svn dcommit'.

-- 
larsh

Re: [PATCH] git-merge: add option --no-ff

[Johannes Schindelin]

Hi,

On Mon, 17 Sep 2007, Chris Shoemaker wrote:

> On Mon, Sep 17, 2007 at 02:23:38PM +0100, Johannes Schindelin wrote:
>
> > "git svn fetch && git rebase git-svn" might be a better approach [...]
> 
> BTW, this is spelled "git svn rebase" these days.

Heh.  Missed that.

Thanks,
Dscho

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

[Cc'd Eric since he's the expert on git-svn]

On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 17 Sep 2007, Lars Hjemli wrote:
>
> > When 'git-svn dcommit' decides which commits it should push back
> > subversion, it scans the output from 'git-log --first-parent HEAD'
> > looking for embedded 'git-svn-id' lines. These lines contain the url
> > of the upstream subversion repository + the subversion revision
> > number.
>
> > So the problem with fast-forward merges of subversion branches is that
> > the output from 'git-log --first-parent HEAD' will show commits from the
> > wrong subversion branch (the fast-forwarded commits).
>
> Ah, I think I know what you're trying to get at.  But "git svn fetch &&
> git rebase git-svn" might be a better approach than "git svn fetch && git
> merge --no-ff git-svn", no?

If I'm understanding you right: no. After  a rebase, the commits would
be ignored by git-svn when looking for the subversion upstream branch
(since the commit SHA1's would no longer match the ones stored in
git-svn's rev_db), but the subversion history would look like
'cherry-picked n commits from merged branch' after dcommit.

-- 
larsh

Re: [PATCH] git-merge: add option --no-ff

[Johannes Schindelin]

Hi,

On Mon, 17 Sep 2007, Lars Hjemli wrote:

> [Cc'd Eric since he's the expert on git-svn]
> 
> On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > Ah, I think I know what you're trying to get at.  But "git svn fetch 
> > && git rebase git-svn" might be a better approach than "git svn fetch 
> > && git merge --no-ff git-svn", no?
> 
> If I'm understanding you right: no. After a rebase, the commits would be 
> ignored by git-svn when looking for the subversion upstream branch 
> (since the commit SHA1's would no longer match the ones stored in 
> git-svn's rev_db), but the subversion history would look like 
> 'cherry-picked n commits from merged branch' after dcommit.

I feel that I am not really qualified here, since I am a strict git-svn 
_user_, but AFAICT it worked here all the time, _especially_ with fast 
forwards.  The trick is that all commits that were added after the branch 
point do _not_ contain any svn lines.

But then, I do not use svn branches here, and that might be the problem?

Ciao,
Dscho

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> But then, I do not use svn branches here, and that might be the problem?

Probably. The case I'm trying to solve is:
  -git-svn branch A is merged into git-svn branch B
  -A is a fast-forward of B

This might look unrealistic, but it happened to me today when I wanted
to merge a feature-branch into a relase-branch. The release-branch had
previously been merged into the feature-branch (to get a few
bugfixes), but the release-branch had not changed since this merge. So
when merging the feature-branch into the release-branch it just
fast-forwarded, leaving me with an 'un-dcomittable' release-branch. I
obviously could have done the merge in subversion (haha!), but doing
it in git preserves the correct history.

Btw: I have redone the merge with --no-ff, and dcommit then worked
like a charm ;-)

-- 
larsh

Re: [PATCH] git-merge: add option --no-ff

[Johannes Schindelin]

Hi,

On Mon, 17 Sep 2007, Lars Hjemli wrote:

> On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > But then, I do not use svn branches here, and that might be the problem?
> 
> Probably. The case I'm trying to solve is:
>   -git-svn branch A is merged into git-svn branch B
>   -A is a fast-forward of B
> 
> This might look unrealistic, but it happened to me today when I wanted
> to merge a feature-branch into a relase-branch. The release-branch had
> previously been merged into the feature-branch (to get a few
> bugfixes), but the release-branch had not changed since this merge. So
> when merging the feature-branch into the release-branch it just
> fast-forwarded, leaving me with an 'un-dcomittable' release-branch. I
> obviously could have done the merge in subversion (haha!), but doing
> it in git preserves the correct history.
> 
> Btw: I have redone the merge with --no-ff, and dcommit then worked
> like a charm ;-)

Yep, I can see that now.

But maybe there is a better method to detect the latest svn id, by not 
only looking up the svn ids, but making sure that they come from the 
current branch?

(I'm happily unaware of git-svn's internals, so that might not be 
feasible... But I think that it might be worth fixing that for the git-svn 
idiot like me, since I would never guess that I have to specify --no-ff 
when working on branches that come from git-svn...)

Ciao,
Dscho

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 17 Sep 2007, Lars Hjemli wrote:
>
> > On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > But then, I do not use svn branches here, and that might be the problem?
> >
> > Probably. The case I'm trying to solve is:
> >   -git-svn branch A is merged into git-svn branch B
> >   -A is a fast-forward of B
> >
> > This might look unrealistic, but it happened to me today when I wanted
> > to merge a feature-branch into a relase-branch. The release-branch had
> > previously been merged into the feature-branch (to get a few
> > bugfixes), but the release-branch had not changed since this merge. So
> > when merging the feature-branch into the release-branch it just
> > fast-forwarded, leaving me with an 'un-dcomittable' release-branch. I
> > obviously could have done the merge in subversion (haha!), but doing
> > it in git preserves the correct history.
> >
> > Btw: I have redone the merge with --no-ff, and dcommit then worked
> > like a charm ;-)
>
> Yep, I can see that now.
>
> But maybe there is a better method to detect the latest svn id, by not
> only looking up the svn ids, but making sure that they come from the
> current branch?

Actually, I looked into this last week (my --upstream rants), and I
guess git-svn could use the --track information in .git/config (if
present) as a sanity check when resolving the upstream. But this would
still make the subversion history look like crap after a fast-forward
merge of the kind I was messing with today. It was logically a merge,
but if dcommit had worked 'correctly' it would have created ~150 new
revisions in the release-branch instead of the single merge commit.

> (I'm happily unaware of git-svn's internals, so that might not be
> feasible... But I think that it might be worth fixing that for the git-svn
> idiot like me, since I would never guess that I have to specify --no-ff
> when working on branches that come from git-svn...)

In the normal cases there is no need for --no-ff, only in degenerated
cases like the one I stumbled upon today ;-)

I'll resend the patch with a link from merge-options.txt to
git-svn.txt and try to describe (in git-svn.txt) when to use --no-ff.

-- 
larsh

[PATCH] git-merge: add option --no-ff

[Lars Hjemli]

This option forces fast-forward merges to create a "true" merge commit,
i.e. a commit with multiple parents.

Although a fast-forward merge would normally be the right thing to do with
git branches, it is suboptimal when operating on git-svn branches since it
makes 'git-svn dcommit' fail to recognize the correct upstream subversion
branch. But performing such a merge with --no-ff specified will both make
git-svn dcommit recognize the correct upstream and create the logically
correct history in subversion (the merge performed in git will be recorded
as a single revision in subversion, not as a series of revisions seemingly
cherry-picked from the merged branch).

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
---

When updating git-svn.txt, I noticed that we might want to update the 
section "DESIGN PHILOSOPHY". Eric?


 Documentation/git-svn.txt       |   13 +++++++++++++
 Documentation/merge-options.txt |    5 +++++
 git-merge.sh                    |   13 +++++++++++--
 t/t6028-merge-up-to-date.sh     |   25 +++++++++++++++++++++++++
 4 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
index be2e34e..c510c21 100644
--- a/Documentation/git-svn.txt
+++ b/Documentation/git-svn.txt
@@ -475,6 +475,19 @@ use 'git-svn rebase' to update your work branch instead of 'git pull' or
 when committing into SVN, which can lead to merge commits reversing
 previous commits in SVN.
 
+If you use 'git-svn dcommit' to commit your local work to the upstream
+subversion branch, merge commits are usually handled correctly, i.e.
+git-svn will only follow the first parent of each merge commit and create
+a single subversion revision for each of them. An exception is when two
+subversion branches has been merged locally and the merge ended up as a
+fast-forward operation. This will make git-svn belive that there are no
+local changes to dcommit. To work around this issue, one can redo the
+merge using the --no-ff option:
+
+       $ git reset --hard HEAD@{1}   ## undo the fast-forward merge
+       $ git merge --no-ff <branch>
+
+
 DESIGN PHILOSOPHY
 -----------------
 Merge tracking in Subversion is lacking and doing branched development
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index d64c259..b34b888 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -25,3 +25,8 @@
 	If there is no `-s` option, a built-in list of strategies
 	is used instead (`git-merge-recursive` when merging a single
 	head, `git-merge-octopus` otherwise).
+
+--no-ff::
+	Force the creation of a merge commit even when the merge would
+	have resolved as a fast-forward operation. See gitlink:git-svn[1]
+	for a use-case for this option.
diff --git a/git-merge.sh b/git-merge.sh
index 3a01db0..13b98e6 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -3,7 +3,7 @@
 # Copyright (c) 2005 Junio C Hamano
 #
 
-USAGE='[-n] [--summary] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
+USAGE='[-n] [--summary] [--no-commit] [--no-ff] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
 
 SUBDIRECTORY_OK=Yes
 . git-sh-setup
@@ -165,6 +165,10 @@ do
 		merge_msg="$1"
 		have_message=t
 		;;
+	--no-ff)
+		no_ff=t
+		no_fast_forward_strategies=$all_strategies
+		;;
 	-*)	usage ;;
 	*)	break ;;
 	esac
@@ -444,7 +448,12 @@ done
 # auto resolved the merge cleanly.
 if test '' != "$result_tree"
 then
-    parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+    if test $no_ff = 't'
+    then
+        parents=$(git rev-parse "$head" "$@" | sed -e 's/^/-p /')
+    else
+        parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
+    fi
     result_commit=$(printf '%s\n' "$merge_msg" | git commit-tree $result_tree $parents) || exit
     finish "$result_commit" "Merge made by $wt_strategy."
     dropsave
diff --git a/t/t6028-merge-up-to-date.sh b/t/t6028-merge-up-to-date.sh
index f8f3e3f..afd74e2 100755
--- a/t/t6028-merge-up-to-date.sh
+++ b/t/t6028-merge-up-to-date.sh
@@ -10,12 +10,14 @@ test_expect_success setup '
 	test_tick &&
 	git commit -m initial &&
 	git tag c0 &&
+	c0=$(git rev-parse c0)
 
 	echo second >file &&
 	git add file &&
 	test_tick &&
 	git commit -m second &&
 	git tag c1 &&
+	c1=$(git rev-parse c1)
 	git branch test
 '
 
@@ -41,6 +43,16 @@ test_expect_success 'merge -s recursive fast-forward' '
 
 '
 
+test_expect_success 'merge -s recursive --no-ff' '
+
+	git reset --hard c0 &&
+	test_tick &&
+	git merge -s recursive --no-ff c1 &&
+	test $c0 = $(git rev-parse HEAD^1) &&
+	test $c1 = $(git rev-parse HEAD^2)
+
+'
+
 test_expect_success 'merge -s ours up-to-date' '
 
 	git reset --hard c1 &&
@@ -63,6 +75,19 @@ test_expect_success 'merge -s ours fast-forward' '
 
 '
 
+test_expect_success 'merge -s ours --no-ff' '
+
+	git reset --hard c0 &&
+	test_tick &&
+	git merge -s ours --no-ff c1 &&
+	expect=$(git rev-parse c0^{tree}) &&
+	current=$(git rev-parse HEAD^{tree}) &&
+	test "$expect" = "$current" &&
+	test $c0 = $(git rev-parse HEAD^1) &&
+	test $c1 = $(git rev-parse HEAD^2)
+
+'
+
 test_expect_success 'merge -s subtree up-to-date' '
 
 	git reset --hard c1 &&
-- 
1.5.3.1.92.g2f5e

Re: [PATCH] git-merge: add option --no-ff

[Eric Wong]

Lars Hjemli <hjemli@gmail.com> wrote:
> This option forces fast-forward merges to create a "true" merge commit,
> i.e. a commit with multiple parents.
> 
> Although a fast-forward merge would normally be the right thing to do with
> git branches, it is suboptimal when operating on git-svn branches since it
> makes 'git-svn dcommit' fail to recognize the correct upstream subversion
> branch. But performing such a merge with --no-ff specified will both make
> git-svn dcommit recognize the correct upstream and create the logically
> correct history in subversion (the merge performed in git will be recorded
> as a single revision in subversion, not as a series of revisions seemingly
> cherry-picked from the merged branch).
> 
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>

Would automatically enabling --no-ff when it detects merging of two (or
more) SVN branches be a good thing?  We can add scripting support to
git-svn for detecting if any given commit is really from SVN or not.
Then we could do something like this in git-merge

---------------------------- 8< --------------------------------
if git-svn test-svn-commits "$@"
then
	no_ff=t
	no_fast_forward_strategies=$all_strategies
fi
---------------------------- 8< --------------------------------

It'd probably prevent a lot of users from shooting themselves in the
foot if they forget to read or learn about the --no-ff option.

> ---
> 
> When updating git-svn.txt, I noticed that we might want to update the 
> section "DESIGN PHILOSOPHY". Eric?

Yeah.  That's very much out of date.  I'll update it in a bit.

-- 
Eric Wong

Re: [PATCH] git-merge: add option --no-ff

[Junio C Hamano]

Eric Wong <normalperson@yhbt.net> writes:

> Would automatically enabling --no-ff when it detects merging of two (or
> more) SVN branches be a good thing?  We can add scripting support to
> git-svn for detecting if any given commit is really from SVN or not.
> Then we could do something like this in git-merge
>
> ---------------------------- 8< --------------------------------
> if git-svn test-svn-commits "$@"
> then
> 	no_ff=t
> 	no_fast_forward_strategies=$all_strategies
> fi
> ---------------------------- 8< --------------------------------

Yuck, do I understand you correctly?  Are you talking about
adding dependency on git-svn to git-merge?

Re: [PATCH] git-merge: add option --no-ff

[Eric Wong]

Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
> 
> > Would automatically enabling --no-ff when it detects merging of two (or
> > more) SVN branches be a good thing?  We can add scripting support to
> > git-svn for detecting if any given commit is really from SVN or not.
> > Then we could do something like this in git-merge
> >
> > ---------------------------- 8< --------------------------------
> > if git-svn test-svn-commits "$@"
> > then
> > 	no_ff=t
> > 	no_fast_forward_strategies=$all_strategies
> > fi
> > ---------------------------- 8< --------------------------------
> 
> Yuck, do I understand you correctly?  Are you talking about
> adding dependency on git-svn to git-merge?

It could be another simple independent script, then.  git-svn isn't
installed on most distros when git is, so it won't always work...

-- 
Eric Wong

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

On 9/18/07, Eric Wong <normalperson@yhbt.net> wrote:
> Would automatically enabling --no-ff when it detects merging of two (or
> more) SVN branches be a good thing?

I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.

--
larsh

Re: [PATCH] git-merge: add option --no-ff

[Eric Wong]

Lars Hjemli <hjemli@gmail.com> wrote:
> On 9/18/07, Eric Wong <normalperson@yhbt.net> wrote:
> > Would automatically enabling --no-ff when it detects merging of two (or
> > more) SVN branches be a good thing?
> 
> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.

That still involves having to get the user to use something new to avoid
shooting themselves in the foot.  Perhaps putting a
"test -d $GIT_DIR/svn" condition in front of the git-svn call I proposed
in git-merge would be alright.

If anybody else is thinking about 'git-svn rebase', this is completely
different.  Using git-rebase alone doesn't allow git-svn users to shoot
themselves in the foot like git-merge does.  'git-svn rebase' only
serves to minimize typing and brain power needed to operate git-svn.

-- 
Eric Wong

Re: [PATCH] git-merge: add option --no-ff

[Junio C Hamano]

"Lars Hjemli" <hjemli@gmail.com> writes:

> On 9/18/07, Eric Wong <normalperson@yhbt.net> wrote:
>> Would automatically enabling --no-ff when it detects merging of two (or
>> more) SVN branches be a good thing?
>
> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.

That unfortunately does not solve the problem.

Re: [PATCH] git-merge: add option --no-ff

[Sam Vilain]

Junio C Hamano wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
> 
>> On 9/18/07, Eric Wong <normalperson@yhbt.net> wrote:
>>> Would automatically enabling --no-ff when it detects merging of two (or
>>> more) SVN branches be a good thing?
>> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.
> 
> That unfortunately does not solve the problem.

I think we 'just' need to fix pushing merges back to SVN - so that they
properly set Subversion 1.5+ (and possibly SVK) merge attributes - and
if it is ambiguous which branch to push to, force the user to decide.

Sam.

Re: [PATCH] git-merge: add option --no-ff

[Sam Vilain]

Sam Vilain wrote:
>>> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.
>>>       
>> That unfortunately does not solve the problem.
>>     
>
> I think we 'just' need to fix pushing merges back to SVN - so that they
> properly set Subversion 1.5+ (and possibly SVK) merge attributes - and
> if it is ambiguous which branch to push to, force the user to decide.
>   

Whoops, I missed the thrust of the current issue; it won't be ambiguous,
it'll be unambiguously wrong, so this doesn't apply.

In which case I'd guess the moral equivalent of --track would have to go
forward, or a per-branch basis.

I think that writing a real fast-forward merge should only happen on
dcommit, not git merge, because that is what is required for SVN. 
Ideally, it should also have the property that it doesn't cycle; null
merges between two branches should not carry on indefinitely.

Sam.

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> I think that writing a real fast-forward merge should only happen on
> dcommit, not git merge, because that is what is required for SVN.

I don't think git-svn has any way of knowing that the user wanted a
merge, unless a merge commit is present. So the user would have to
specify the set of commits which should be considered a merge during
dcommit (this would actually resemble how merges are performed in
subversion).

Sidenote: this might be slightly controversial, but I've sometimes
missed a --no-ff option to 'git merge' when working on plain git
repositories; IMHO preserving the 'logical' merge history when the
merge of a topic branch results in a fast-forward can be interesting.

-- 
larsh

Re: [PATCH] git-merge: add option --no-ff

[Sam Vilain]

Lars Hjemli wrote:
> On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
>   
>> I think that writing a real fast-forward merge should only happen on
>> dcommit, not git merge, because that is what is required for SVN.
>>     
>
> I don't think git-svn has any way of knowing that the user wanted a
> merge, unless a merge commit is present. So the user would have to
> specify the set of commits which should be considered a merge during
> dcommit (this would actually resemble how merges are performed in
> subversion).
>   

Sure it can.  If you're committing to branch X, and the current tree has
a whole lot of commits above that, then it should do the only thing you
can do with SVN.

Which is write a squash commit, and set the "svn:merge" and/or
"svk:merge" properties to represent what happened.

> Sidenote: this might be slightly controversial, but I've sometimes
> missed a --no-ff option to 'git merge' when working on plain git
> repositories; IMHO preserving the 'logical' merge history when the
> merge of a topic branch results in a fast-forward can be interesting.

If you really want one, use git commit-tree directly.

Sam.

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

[...sorry for making this such a long thread...]

On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> Lars Hjemli wrote:
> > On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> >
> >> I think that writing a real fast-forward merge should only happen on
> >> dcommit, not git merge, because that is what is required for SVN.
> >>
> >
> > I don't think git-svn has any way of knowing that the user wanted a
> > merge, unless a merge commit is present. So the user would have to
> > specify the set of commits which should be considered a merge during
> > dcommit (this would actually resemble how merges are performed in
> > subversion).
> >
>
> Sure it can.  If you're committing to branch X, and the current tree has
> a whole lot of commits above that, then it should do the only thing you
> can do with SVN.
>
> Which is write a squash commit, and set the "svn:merge" and/or
> "svk:merge" properties to represent what happened.

I often have prepared a series of local commits which I _want_ to
preserve as different subversion revisions.

Also, doing a --squash means that I loose the merge history in git
(and then I need to edit the grafts file again)

>
> > Sidenote: this might be slightly controversial, but I've sometimes
> > missed a --no-ff option to 'git merge' when working on plain git
> > repositories; IMHO preserving the 'logical' merge history when the
> > merge of a topic branch results in a fast-forward can be interesting.
>
> If you really want one, use git commit-tree directly.

Yeah, that's an option, but --no-ff is somewhat less work ;-)

--
larsh

Re: [PATCH] git-merge: add option --no-ff

[Sam Vilain]

Lars Hjemli wrote:
> [...sorry for making this such a long thread...]
>
> On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
>   
>> Lars Hjemli wrote:
>>     
>>> On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
>>>
>>>       
>>>> I think that writing a real fast-forward merge should only happen on
>>>> dcommit, not git merge, because that is what is required for SVN.
>>>>
>>>>         
>>> I don't think git-svn has any way of knowing that the user wanted a
>>> merge, unless a merge commit is present. So the user would have to
>>> specify the set of commits which should be considered a merge during
>>> dcommit (this would actually resemble how merges are performed in
>>> subversion).
>>>
>>>       
>> Sure it can.  If you're committing to branch X, and the current tree has
>> a whole lot of commits above that, then it should do the only thing you
>> can do with SVN.
>>
>> Which is write a squash commit, and set the "svn:merge" and/or
>> "svk:merge" properties to represent what happened.
>>     
>
> I often have prepared a series of local commits which I _want_ to
> preserve as different subversion revisions.
>   

But for the scenario we are discussing the revisions already exist
upstream otherwise there would be no fast forward merge.  So, if you
want that behaviour you can use cherry-pick on the git side and the
correct behaviour for git-svn is to write svn merge properties.

> Also, doing a --squash means that I loose the merge history in git
> (and then I need to edit the grafts file again)
>   

There is no merge history in git, it was a fast forward.

>>> Sidenote: this might be slightly controversial, but I've sometimes
>>> missed a --no-ff option to 'git merge' when working on plain git
>>> repositories; IMHO preserving the 'logical' merge history when the
>>> merge of a topic branch results in a fast-forward can be interesting.
>>>       
>> If you really want one, use git commit-tree directly.
>>     
> Yeah, that's an option, but --no-ff is somewhat less work ;-)
>   

Sure.  I just don't see a good use case for it from this yet.

Sam.

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> Lars Hjemli wrote:
> > On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
> >> If you really want one, use git commit-tree directly.
> >>
> > Yeah, that's an option, but --no-ff is somewhat less work ;-)
> >
>
> Sure.  I just don't see a good use case for it from this yet.

Ok. I'll try to explain why I needed --no-ff in the first place:

I have two git-svn brances, lets call them FEATURE and RELEASE. At one
point, I did
  $ git checkout FEATURE
  $ git merge RELEASE
  $ git svn dcommit

Now, my coworkers can continue testing/developing on top of the
subversion branch FEATURE (I'm currently the only git user), knowing
that every bugfix from RELEASE have been merged.

A few days later, FEATURE is completed and tested and should be
integrated in RELEASE. I did

  $ git checkout RELEASE
  $ git merge FEATURE
  $ git svn dcommit -n

and noticed that git-svn wanted to commit the result to FEATURE, since
the merge actually was a fast-forward. If this was a a pure git
environment it would be no problem, but as I needed to get a merge
revision on top of the subversion RELEASE branch, I was in trouble.

My options:
* rebase FEATURE onto RELEASE: this would have duplicated ~150
revisions from FEATURE onto RELEASE in subversion
* merge --squash: this would have created the wanted history in
subversion, but my git history would have lacked the info that
everything in FEATURE had been integrated into RELEASE (this could
have been fixed by editing the grafts file)
* merge --no-ff: this made both the subversion history and my local
git history reflect what actually happened.

So I went for the --no-ff option.

If this use-case isn't good enough, oh well. I can always carry the
patch forward in my git repo ;-)

--
larsh

Re: [PATCH] git-merge: add option --no-ff

[Sam Vilain]

Lars Hjemli wrote:
> Ok. I'll try to explain why I needed --no-ff in the first place:
>
> I have two git-svn brances, lets call them FEATURE and RELEASE. At one
> point, I did
>   $ git checkout FEATURE
>   $ git merge RELEASE
>   $ git svn dcommit
>
> Now, my coworkers can continue testing/developing on top of the
> subversion branch FEATURE (I'm currently the only git user), knowing
> that every bugfix from RELEASE have been merged.
>
> A few days later, FEATURE is completed and tested and should be
> integrated in RELEASE. I did
>
>   $ git checkout RELEASE
>   $ git merge FEATURE
>   $ git svn dcommit -n
>
> and noticed that git-svn wanted to commit the result to FEATURE, since
> the merge actually was a fast-forward. If this was a a pure git
> environment it would be no problem, but as I needed to get a merge
> revision on top of the subversion RELEASE branch, I was in trouble.
>   

I understand.  But if you could specify a target branch of "RELEASE" to
dcommit (which git-svn might know based on which svn tracking branch it
was branched from), then it should be able to do the same thing that
'svn merge' would do on svn 1.5+, or 'svk sm' does.  Which is to write
to the SVN repository a squash merge, and write svn properties to let
merge-aware svn tools know which SVN revisions are being squashed.

> My options:
> * rebase FEATURE onto RELEASE: this would have duplicated ~150
> revisions from FEATURE onto RELEASE in subversion
>   

Yes, not desirable.

> * merge --squash: this would have created the wanted history in
> subversion, but my git history would have lacked the info that
> everything in FEATURE had been integrated into RELEASE (this could
> have been fixed by editing the grafts file)
>   

This is a current deficiency in git-svn; bidirectional merge tracking is
not there yet.

> * merge --no-ff: this made both the subversion history and my local
> git history reflect what actually happened.
>
> So I went for the --no-ff option.
>
> If this use-case isn't good enough, oh well. I can always carry the
> patch forward in my git repo ;-)
>   

And you'll probably need to keep it around until bidirectional merge
handling is in.

Sam.

Re: [PATCH] git-merge: add option --no-ff

[Johannes Schindelin]

Hi,

On Tue, 18 Sep 2007, Lars Hjemli wrote:

> Sidenote: this might be slightly controversial, but I've sometimes 
> missed a --no-ff option to 'git merge' when working on plain git 
> repositories; IMHO preserving the 'logical' merge history when the merge 
> of a topic branch results in a fast-forward can be interesting.

Linus explained a lot of times why this is wrong.  It encourages 
upstream-downstream thinking.  We should really turn this into a FAQ.

Ciao,
Dscho

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

[...stripped the Cc, as we're slightly changing topic...]

On 9/18/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Tue, 18 Sep 2007, Lars Hjemli wrote:
> > Sidenote: this might be slightly controversial, but I've sometimes
> > missed a --no-ff option to 'git merge' when working on plain git
> > repositories; IMHO preserving the 'logical' merge history when the merge
> > of a topic branch results in a fast-forward can be interesting.
>
> Linus explained a lot of times why this is wrong.  It encourages
> upstream-downstream thinking.  We should really turn this into a FAQ.

Well, the cases where I've wanted to do this is when I've developed
some new feature in cgit as a topic branch. I've then merged the topic
branch into my master branch which had been idle since the creation of
the topic branch (cgit doesn't get as many patches as git...). So I
get a fast-forward and my precious topic-branch is no longer visible
(at least for anyone cloning my repo). Not very important, but I'd
like to preserve the fact that this was a topic branch. How would this
encourage 'upstream-downstream thinking'?

-- 
larsh

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

On 9/18/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Lars Hjemli" <hjemli@gmail.com> writes:
>
> > On 9/18/07, Eric Wong <normalperson@yhbt.net> wrote:
> >> Would automatically enabling --no-ff when it detects merging of two (or
> >> more) SVN branches be a good thing?
> >
> > I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.
>
> That unfortunately does not solve the problem.
>

The problem we're trying to solve is to somehow avoid fast-forward
merges between git-svn branches, right?

I don't think it's a big issue in itself. If a fast-forward occurs,
what will happen is basically that git-svn will guess the wrong
upstream branch and then proceed to do nothing [1]. The user can
always recover from this state with 'git-reset' and 'git-merge
--no-ff'. So I think the result of a fast-forward merge between
git-svn branches is annoying, but not fatal [2].

But a closely related issue is that git-svn shouldn't dcommit to the
wrong upstream (even in the case of a fast-forward merge). We need a
way to explicitly show the link between the local and remote svn
branch (something like .git/config perhaps).

-- 
larsh

[1] If the merged-in branch had local commits they will be 'dcommited'
to the correct upstream of the merged-in branch, which isn't to bad

[2] if git-svn could be fixed to handle even the ff case, someone
could actually prefer to get the 'cherry-picked' history in
subversion. I don't, hence my --no-ff patch, but I'm not at all
certain this should be _forced_ on git-svn branches.

Re: [PATCH] git-merge: add option --no-ff

[Peter Baumann]

On Mon, Sep 17, 2007 at 06:23:04PM +0200, Lars Hjemli wrote:
> This option forces fast-forward merges to create a "true" merge commit,
> i.e. a commit with multiple parents.
> 
> Although a fast-forward merge would normally be the right thing to do with
> git branches, it is suboptimal when operating on git-svn branches since it
> makes 'git-svn dcommit' fail to recognize the correct upstream subversion
> branch. But performing such a merge with --no-ff specified will both make
> git-svn dcommit recognize the correct upstream and create the logically
> correct history in subversion (the merge performed in git will be recorded
> as a single revision in subversion, not as a series of revisions seemingly
> cherry-picked from the merged branch).
> 
> Signed-off-by: Lars Hjemli <hjemli@gmail.com>
> ---
> 
> When updating git-svn.txt, I noticed that we might want to update the 
> section "DESIGN PHILOSOPHY". Eric?
> 
> 
>  Documentation/git-svn.txt       |   13 +++++++++++++
>  Documentation/merge-options.txt |    5 +++++
>  git-merge.sh                    |   13 +++++++++++--
>  t/t6028-merge-up-to-date.sh     |   25 +++++++++++++++++++++++++
>  4 files changed, 54 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt
> index be2e34e..c510c21 100644
> --- a/Documentation/git-svn.txt
> +++ b/Documentation/git-svn.txt
> @@ -475,6 +475,19 @@ use 'git-svn rebase' to update your work branch instead of 'git pull' or
>  when committing into SVN, which can lead to merge commits reversing
>  previous commits in SVN.
>  
> +If you use 'git-svn dcommit' to commit your local work to the upstream
> +subversion branch, merge commits are usually handled correctly, i.e.
> +git-svn will only follow the first parent of each merge commit and create
> +a single subversion revision for each of them. An exception is when two
> +subversion branches has been merged locally and the merge ended up as a
> +fast-forward operation. This will make git-svn belive that there are no
> +local changes to dcommit. To work around this issue, one can redo the
> +merge using the --no-ff option:
> +
> +       $ git reset --hard HEAD@{1}   ## undo the fast-forward merge
> +       $ git merge --no-ff <branch>
> +
> +
>  DESIGN PHILOSOPHY
>  -----------------
>  Merge tracking in Subversion is lacking and doing branched development
> diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
> index d64c259..b34b888 100644
> --- a/Documentation/merge-options.txt
> +++ b/Documentation/merge-options.txt
> @@ -25,3 +25,8 @@
>  	If there is no `-s` option, a built-in list of strategies
>  	is used instead (`git-merge-recursive` when merging a single
>  	head, `git-merge-octopus` otherwise).
> +
> +--no-ff::
> +	Force the creation of a merge commit even when the merge would
> +	have resolved as a fast-forward operation. See gitlink:git-svn[1]
> +	for a use-case for this option.
> diff --git a/git-merge.sh b/git-merge.sh
> index 3a01db0..13b98e6 100755
> --- a/git-merge.sh
> +++ b/git-merge.sh
> @@ -3,7 +3,7 @@
>  # Copyright (c) 2005 Junio C Hamano
>  #
>  
> -USAGE='[-n] [--summary] [--no-commit] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
> +USAGE='[-n] [--summary] [--no-commit] [--no-ff] [--squash] [-s <strategy>] [-m=<merge-message>] <commit>+'
>  
>  SUBDIRECTORY_OK=Yes
>  . git-sh-setup
> @@ -165,6 +165,10 @@ do
>  		merge_msg="$1"
>  		have_message=t
>  		;;
> +	--no-ff)
> +		no_ff=t
> +		no_fast_forward_strategies=$all_strategies
> +		;;
>  	-*)	usage ;;
>  	*)	break ;;
>  	esac
> @@ -444,7 +448,12 @@ done
>  # auto resolved the merge cleanly.
>  if test '' != "$result_tree"
>  then
> -    parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
> +    if test $no_ff = 't'
This should be quoted, e.g.
  +    if test "$no_ff" = 't'

Otherwise I get an error like the following:

  xp:/tmp/va (a)$ git merge b
  Renamed msg.cc->common/msg.cc
  Auto-merged common/msg.cc
  Renamed msg.h->common/msg.h
  Auto-merged common/msg.h
  Renamed sampler/ConcurrentQueue.h->common/ConcurrentQueue.h
  Auto-merged common/ConcurrentQueue.h
  Renamed sampler/TimeoutSemaphore.h->common/TimeoutSemaphore.h
  Auto-merged common/TimeoutSemaphore.h
  /home/peter/usr/bin/git-merge: line 451: test: =: unary operator expected
  Merge made by recursive.


> +    then
> +        parents=$(git rev-parse "$head" "$@" | sed -e 's/^/-p /')
> +    else
> +        parents=$(git show-branch --independent "$head" "$@" | sed -e 's/^/-p /')
> +    fi
>      result_commit=$(printf '%s\n' "$merge_msg" | git commit-tree $result_tree $parents) || exit
>      finish "$result_commit" "Merge made by $wt_strategy."
>      dropsave

-Peter

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

On 9/19/07, Peter Baumann <waste.manager@gmx.de> wrote:
> This should be quoted, e.g.
>   +    if test "$no_ff" = 't'
>

Ouch, sorry about that. I can send an updated patch late tonight (it's
now early morning here), but I'm not sure Junio wants/needs it. Junio?

--
larsh

Re: [PATCH] git-merge: add option --no-ff

[Chris Shoemaker]

On Mon, Sep 17, 2007 at 04:12:56PM +0200, Lars Hjemli wrote:
> On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > But then, I do not use svn branches here, and that might be the problem?
> 
> Probably. The case I'm trying to solve is:
>   -git-svn branch A is merged into git-svn branch B
>   -A is a fast-forward of B

Ah, now I see what you mean.  But, IIUC, if you want to dcommit your
merge, you should treat it the way svn treats it, with git-merge
--squash.  Then, dcommit won't be confused about the branch you're
committing to.

-chris

> 
> This might look unrealistic, but it happened to me today when I wanted
> to merge a feature-branch into a relase-branch. The release-branch had
> previously been merged into the feature-branch (to get a few
> bugfixes), but the release-branch had not changed since this merge. So
> when merging the feature-branch into the release-branch it just
> fast-forwarded, leaving me with an 'un-dcomittable' release-branch. I
> obviously could have done the merge in subversion (haha!), but doing
> it in git preserves the correct history.
> 
> Btw: I have redone the merge with --no-ff, and dcommit then worked
> like a charm ;-)
> 
> -- 
> larsh
> -
> 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

Re: [PATCH] git-merge: add option --no-ff

[Lars Hjemli]

On 9/17/07, Chris Shoemaker <c.shoemaker@cox.net> wrote:
> On Mon, Sep 17, 2007 at 04:12:56PM +0200, Lars Hjemli wrote:
> > On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > But then, I do not use svn branches here, and that might be the problem?
> >
> > Probably. The case I'm trying to solve is:
> >   -git-svn branch A is merged into git-svn branch B
> >   -A is a fast-forward of B
>
> Ah, now I see what you mean.  But, IIUC, if you want to dcommit your
> merge, you should treat it the way svn treats it, with git-merge
> --squash.  Then, dcommit won't be confused about the branch you're
> committing to.

Yeah, --squash is a viable option (I _almost_ used it ;-) but I wanted
to keep the merge-history on the git side (without modifying the
grafts-file).

-- 
larsh