threads / patch / 9893

patchgit-merge: add option --no-ff

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

## tl;dr

34 messages between Sep 17, 2007 and Sep 19, 2007. Diffs are folded; open one to read it.

replies: 33people: 8as markdown or json

Lars Hjemli· Sep 17, 2007, 12:17 UTC · lore

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(-)
Show changes to 3 files +40 −2

Documentation/merge-options.txt, git-merge.sh, t/t6028-merge-up-to-date.sh

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
Andreas Ericsson· Sep 17, 2007, 12:39 UTC · re: Lars Hjemli · lore

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

Lars Hjemli wrote:
Show 15 quoted lines
> 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
Lars Hjemli· Sep 17, 2007, 13:16 UTC · re: Andreas Ericsson · lore

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

On 9/17/07, Andreas Ericsson <ae@op5.se> wrote:
Show 23 quoted lines
> 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

Johannes Schindelin· Sep 17, 2007, 13:23 UTC · re: Lars Hjemli · lore

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

Hi,
On Mon, 17 Sep 2007, Lars Hjemli wrote:
Show 5 quoted lines
> 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

Chris Shoemaker· Sep 17, 2007, 13:37 UTC · re: Johannes Schindelin · lore

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

On Mon, Sep 17, 2007 at 02:23:38PM +0100, Johannes Schindelin wrote:
Show 16 quoted lines
> 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
Lars Hjemli· Sep 17, 2007, 13:40 UTC · re: Chris Shoemaker · lore

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

On 9/17/07, Chris Shoemaker <c.shoemaker@cox.net> wrote:
Show 5 quoted lines
> 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
Johannes Schindelin· Sep 17, 2007, 13:52 UTC · re: Chris Shoemaker · lore

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

Hi,
On Mon, 17 Sep 2007, Chris Shoemaker wrote:
Show 5 quoted lines
> 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

Lars Hjemli· Sep 17, 2007, 13:38 UTC · re: Johannes Schindelin · lore

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

[Cc'd Eric since he's the expert on git-svn]
On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 17 quoted lines
> 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
Johannes Schindelin· Sep 17, 2007, 13:57 UTC · re: Lars Hjemli · lore

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

Hi,
On Mon, 17 Sep 2007, Lars Hjemli wrote:
Show 13 quoted lines
> [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

Lars Hjemli· Sep 17, 2007, 14:12 UTC · re: Johannes Schindelin · lore

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

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
Johannes Schindelin· Sep 17, 2007, 15:05 UTC · re: Lars Hjemli · lore

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

Hi,
On Mon, 17 Sep 2007, Lars Hjemli wrote:
Show 18 quoted lines
> 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

Lars Hjemli· Sep 17, 2007, 15:17 UTC · re: Johannes Schindelin · lore

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

On 9/17/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 28 quoted lines
> 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
Lars Hjemli· Sep 17, 2007, 16:23 UTC · re: Lars Hjemli · lore

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(-)
Show changes to 4 files +54 −2

Documentation/git-svn.txt, Documentation/merge-options.txt, git-merge.sh, t/t6028-merge-up-to-date.sh

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
Eric Wong· Sep 18, 2007, 00:50 UTC · re: Lars Hjemli · lore

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

Lars Hjemli <hjemli@gmail.com> wrote:
Show 13 quoted lines
> 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
Junio C Hamano· Sep 18, 2007, 01:09 UTC · re: Eric Wong · lore

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

Eric Wong <normalperson@yhbt.net> writes:
Show 12 quoted lines
> 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?

Eric Wong· Sep 18, 2007, 01:39 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> wrote:
Show 17 quoted lines
> 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
Lars Hjemli· Sep 18, 2007, 06:12 UTC · re: Eric Wong · lore

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

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

Eric Wong· Sep 18, 2007, 06:23 UTC · re: Lars Hjemli · lore

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

Lars Hjemli <hjemli@gmail.com> wrote:
Show 5 quoted lines
> 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
Junio C Hamano· Sep 18, 2007, 06:53 UTC · re: Lars Hjemli · lore

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

"Lars Hjemli" <hjemli@gmail.com> writes:
Show 5 quoted lines
> 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.
Sam Vilain· Sep 18, 2007, 07:30 UTC · re: Junio C Hamano · lore

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

Junio C Hamano wrote:
Show 8 quoted lines
> "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.
Sam Vilain· Sep 18, 2007, 09:12 UTC · re: Sam Vilain · lore

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

Sam Vilain wrote:
Show 9 quoted lines
>>> 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.
Lars Hjemli· Sep 18, 2007, 11:19 UTC · re: Sam Vilain · lore

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

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
Sam Vilain· Sep 18, 2007, 11:50 UTC · re: Lars Hjemli · lore

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

Lars Hjemli wrote:
Show 12 quoted lines
> 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.
Lars Hjemli· Sep 18, 2007, 12:03 UTC · re: Sam Vilain · lore

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

[...sorry for making this such a long thread...]
On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
Show 20 quoted lines
> 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)

Show 7 quoted lines
>
> > 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

Sam Vilain· Sep 18, 2007, 13:22 UTC · re: Lars Hjemli · lore

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

Lars Hjemli wrote:
Show 31 quoted lines
> [...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.
Show 9 quoted lines
>>> 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.
Lars Hjemli· Sep 18, 2007, 14:01 UTC · re: Sam Vilain · lore

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

On 9/18/07, Sam Vilain <sam@vilain.net> wrote:
Show 8 quoted lines
> 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

Sam Vilain· Sep 18, 2007, 14:34 UTC · re: Lars Hjemli · lore

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

Lars Hjemli wrote:
Show 24 quoted lines
> 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.
Show 5 quoted lines
> * 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.

Show 8 quoted lines
> * 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.
Johannes Schindelin· Sep 18, 2007, 12:29 UTC · re: Lars Hjemli · lore

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

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

Lars Hjemli· Sep 18, 2007, 12:38 UTC · re: Johannes Schindelin · lore

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

[...stripped the Cc, as we're slightly changing topic...]
On 9/18/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 8 quoted lines
> 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
Lars Hjemli· Sep 18, 2007, 08:02 UTC · re: Junio C Hamano · lore

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

On 9/18/07, Junio C Hamano <gitster@pobox.com> wrote:
Show 10 quoted lines
> "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.
Peter Baumann· Sep 18, 2007, 22:51 UTC · re: Lars Hjemli · lore

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

On Mon, Sep 17, 2007 at 06:23:04PM +0200, Lars Hjemli wrote:
Show 92 quoted lines
> 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.
Show 8 quoted lines
> +    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
Lars Hjemli· Sep 19, 2007, 07:09 UTC · re: Peter Baumann · lore

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

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

Chris Shoemaker· Sep 17, 2007, 16:07 UTC · re: Lars Hjemli · lore

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

On Mon, Sep 17, 2007 at 04:12:56PM +0200, Lars Hjemli wrote:
Show 6 quoted lines
> 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
Show 19 quoted lines
> 
> 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
Lars Hjemli· Sep 17, 2007, 16:14 UTC · re: Chris Shoemaker · lore

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

On 9/17/07, Chris Shoemaker <c.shoemaker@cox.net> wrote:
Show 12 quoted lines
> 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

← back to recent threads