{"thread":{"id":"9893","subject":"[PATCH] git-merge: add option --no-ff","startedAt":"2007-09-17T12:17:12Z","lastAt":"2007-09-19T07:09:46Z","messageCount":34,"participants":["Lars Hjemli","Andreas Ericsson","Johannes Schindelin","Chris Shoemaker","Eric Wong","Junio C Hamano","Sam Vilain","Peter Baumann"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"53300","messageId":"11900314321506-git-send-email-hjemli@gmail.com","threadId":"9893","inReplyTo":null,"subject":"[PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-17T12:17:12Z","receivedAt":"2007-09-17T12:17:12Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"This new option forces all merges to create a \"true\" merge commit, i.e. a\ncommit with multiple parents.\n\nAlthough a fast-forward would normally be The Right Thing, it isn't when the\nbranches to be merged originated in subversion and the merge commit will\nbe pushed back by means of 'git svn dcommit'. In these cases, a fast-\nforward merge simply will not work.\n\nSigned-off-by: Lars Hjemli \n---\n Documentation/merge-options.txt | 4 ++++\n git-merge.sh | 13 +++++++++++--\n t/t6028-merge-up-to-date.sh | 25 +++++++++++++++++++++++++\n 3 files changed, 40 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt\nindex d64c259..ed28017 100644\n--- a/Documentation/merge-options.txt\n+++ b/Documentation/merge-options.txt\n@@ -25,3 +25,7 @@\n \tIf there is no `-s` option, a built-in list of strategies\n \tis used instead (`git-merge-recursive` when merging a single\n \thead, `git-merge-octopus` otherwise).\n+\n+--no-ff::\n+\tForce the creation of a merge commit even when the merge would\n+\thave resolved as a fast-forward operation.\ndiff --git a/git-merge.sh b/git-merge.sh\nindex 3a01db0..13b98e6 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -3,7 +3,7 @@\n # Copyright (c) 2005 Junio C Hamano\n #\n \n-USAGE='[-n] [--summary] [--no-commit] [--squash] [-s ] [-m=] +'\n+USAGE='[-n] [--summary] [--no-commit] [--no-ff] [--squash] [-s ] [-m=] +'\n \n SUBDIRECTORY_OK=Yes\n . git-sh-setup\n@@ -165,6 +165,10 @@ do\n \t\tmerge_msg=\"$1\"\n \t\thave_message=t\n \t\t;;\n+\t--no-ff)\n+\t\tno_ff=t\n+\t\tno_fast_forward_strategies=$all_strategies\n+\t\t;;\n \t-*)\tusage ;;\n \t*)\tbreak ;;\n \tesac\n@@ -444,7 +448,12 @@ done\n # auto resolved the merge cleanly.\n if test '' != \"$result_tree\"\n then\n- parents=$(git show-branch --independent \"$head\" \"$@\" | sed -e 's/^/-p /')\n+ if test $no_ff = 't'\n+ then\n+ parents=$(git rev-parse \"$head\" \"$@\" | sed -e 's/^/-p /')\n+ else\n+ parents=$(git show-branch --independent \"$head\" \"$@\" | sed -e 's/^/-p /')\n+ fi\n result_commit=$(printf '%s\\n' \"$merge_msg\" | git commit-tree $result_tree $parents) || exit\n finish \"$result_commit\" \"Merge made by $wt_strategy.\"\n dropsave\ndiff --git a/t/t6028-merge-up-to-date.sh b/t/t6028-merge-up-to-date.sh\nindex f8f3e3f..afd74e2 100755\n--- a/t/t6028-merge-up-to-date.sh\n+++ b/t/t6028-merge-up-to-date.sh\n@@ -10,12 +10,14 @@ test_expect_success setup '\n \ttest_tick &&\n \tgit commit -m initial &&\n \tgit tag c0 &&\n+\tc0=$(git rev-parse c0)\n \n \techo second >file &&\n \tgit add file &&\n \ttest_tick &&\n \tgit commit -m second &&\n \tgit tag c1 &&\n+\tc1=$(git rev-parse c1)\n \tgit branch test\n '\n \n@@ -41,6 +43,16 @@ test_expect_success 'merge -s recursive fast-forward' '\n \n '\n \n+test_expect_success 'merge -s recursive --no-ff' '\n+\n+\tgit reset --hard c0 &&\n+\ttest_tick &&\n+\tgit merge -s recursive --no-ff c1 &&\n+\ttest $c0 = $(git rev-parse HEAD^1) &&\n+\ttest $c1 = $(git rev-parse HEAD^2)\n+\n+'\n+\n test_expect_success 'merge -s ours up-to-date' '\n \n \tgit reset --hard c1 &&\n@@ -63,6 +75,19 @@ test_expect_success 'merge -s ours fast-forward' '\n \n '\n \n+test_expect_success 'merge -s ours --no-ff' '\n+\n+\tgit reset --hard c0 &&\n+\ttest_tick &&\n+\tgit merge -s ours --no-ff c1 &&\n+\texpect=$(git rev-parse c0^{tree}) &&\n+\tcurrent=$(git rev-parse HEAD^{tree}) &&\n+\ttest \"$expect\" = \"$current\" &&\n+\ttest $c0 = $(git rev-parse HEAD^1) &&\n+\ttest $c1 = $(git rev-parse HEAD^2)\n+\n+'\n+\n test_expect_success 'merge -s subtree up-to-date' '\n \n \tgit reset --hard c1 &&\n-- \n1.5.3.1.92.g2f5e\n"},{"id":"53301","messageId":"46EE7584.8010202@op5.se","threadId":"9893","inReplyTo":"11900314321506-git-send-email-hjemli@gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2007-09-17T12:39:32Z","receivedAt":"2007-09-17T12:39:32Z","isPatch":true,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Lars Hjemli wrote:\n> This new option forces all merges to create a \"true\" merge commit, i.e. a\n> commit with multiple parents.\n> \n> Although a fast-forward would normally be The Right Thing, it isn't when the\n> branches to be merged originated in subversion and the merge commit will\n> be pushed back by means of 'git svn dcommit'. In these cases, a fast-\n> forward merge simply will not work.\n> \n> \tIf there is no `-s` option, a built-in list of strategies\n> \tis used instead (`git-merge-recursive` when merging a single\n> \thead, `git-merge-octopus` otherwise).\n> +\n> +--no-ff::\n> +\tForce the creation of a merge commit even when the merge would\n> +\thave resolved as a fast-forward operation.\n\n+ Although a fast-forward would normally be The Right Thing, it isn't when the\n+ branches to be merged originated in subversion and the merge commit will\n+ be pushed back by means of 'git svn dcommit'. In these cases, a fast-\n+ forward merge simply will not work.\n\nOtherwise someone will sit down and try to figure out why this is necessary.\n\nI'm having trouble understanding why this is needed, but I'll take your word\nfor it ;-)\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"53308","messageId":"8c5c35580709170616i49a8836hb60423c5eebf601d@mail.gmail.com","threadId":"9893","inReplyTo":"46EE7584.8010202@op5.se","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-17T13:16:54Z","receivedAt":"2007-09-17T13:16:54Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/17/07, Andreas Ericsson wrote:\n> Lars Hjemli wrote:\n> > This new option forces all merges to create a \"true\" merge commit, i.e. a\n> > commit with multiple parents.\n> >\n> > Although a fast-forward would normally be The Right Thing, it isn't when the\n> > branches to be merged originated in subversion and the merge commit will\n> > be pushed back by means of 'git svn dcommit'. In these cases, a fast-\n> > forward merge simply will not work.\n> >\n> > If there is no `-s` option, a built-in list of strategies\n> > is used instead (`git-merge-recursive` when merging a single\n> > head, `git-merge-octopus` otherwise).\n> > +\n> > +--no-ff::\n> > + Force the creation of a merge commit even when the merge would\n> > + have resolved as a fast-forward operation.\n>\n> + Although a fast-forward would normally be The Right Thing, it isn't when the\n> + branches to be merged originated in subversion and the merge commit will\n> + be pushed back by means of 'git svn dcommit'. In these cases, a fast-\n> + forward merge simply will not work.\n>\n> Otherwise someone will sit down and try to figure out why this is necessary.\n\nTrue.\n\n> I'm having trouble understanding why this is needed, but I'll take your word\n> for it ;-)\n\nI'll try to explain:\n\nWhen 'git-svn dcommit' decides which commits it should push back\nsubversion, it scans the output from 'git-log --first-parent HEAD'\nlooking for embedded 'git-svn-id' lines. These lines contain the url\nof the upstream subversion repository + the subversion revision\nnumber. So the problem with fast-forward merges of subversion branches\nis that the output from 'git-log --first-parent HEAD' will show\ncommits from the wrong subversion branch (the fast-forwarded commits).\n\nThis could maybe be fixed in git-svn if it learned a different way of\ndiscovering the upstream subversion branch, but then it would make\ngit-svn commit n revisions to subversion (again, the fast-forwarded\ncommits) instead of a single merge-commit. This would look (in\nsubversion) like a series of n cherry-picks from the merged branch.\n\nBtw: maybe the --no-ff section in merge-options.txt could just link to\ngit-svn.txt, which in turn could have some lengthy explanation about\nmerge --no-ff/dcommit behaviour?\n\n--\nlarsh\n"},{"id":"53309","messageId":"Pine.LNX.4.64.0709171422340.28586@racer.site","threadId":"9893","inReplyTo":"8c5c35580709170616i49a8836hb60423c5eebf601d@mail.gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-17T13:23:38Z","receivedAt":"2007-09-17T13:23:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 17 Sep 2007, Lars Hjemli wrote:\n\n> When 'git-svn dcommit' decides which commits it should push back\n> subversion, it scans the output from 'git-log --first-parent HEAD'\n> looking for embedded 'git-svn-id' lines. These lines contain the url\n> of the upstream subversion repository + the subversion revision\n> number.\n\n> So the problem with fast-forward merges of subversion branches is that \n> the output from 'git-log --first-parent HEAD' will show commits from the \n> wrong subversion branch (the fast-forwarded commits).\n\nAh, I think I know what you're trying to get at. But \"git svn fetch && \ngit rebase git-svn\" might be a better approach than \"git svn fetch && git \nmerge --no-ff git-svn\", no?\n\nCiao,\nDscho\n"},{"id":"53311","messageId":"20070917133742.GA10923@pe.Belkin","threadId":"9893","inReplyTo":"Pine.LNX.4.64.0709171422340.28586@racer.site","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2007-09-17T13:37:42Z","receivedAt":"2007-09-17T13:37:42Z","isPatch":true,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Mon, Sep 17, 2007 at 02:23:38PM +0100, Johannes Schindelin wrote:\n> Hi,\n> \n> On Mon, 17 Sep 2007, Lars Hjemli wrote:\n> \n> > When 'git-svn dcommit' decides which commits it should push back\n> > subversion, it scans the output from 'git-log --first-parent HEAD'\n> > looking for embedded 'git-svn-id' lines. These lines contain the url\n> > of the upstream subversion repository + the subversion revision\n> > number.\n> \n> > So the problem with fast-forward merges of subversion branches is that \n> > the output from 'git-log --first-parent HEAD' will show commits from the \n> > wrong subversion branch (the fast-forwarded commits).\n> \n> Ah, I think I know what you're trying to get at. But \"git svn fetch && \n> git rebase git-svn\" might be a better approach [...]\n\nBTW, this is spelled \"git svn rebase\" these days.\n\n-chris\n"},{"id":"53312","messageId":"8c5c35580709170638mc0c8279pa86d71bd79fd3084@mail.gmail.com","threadId":"9893","inReplyTo":"Pine.LNX.4.64.0709171422340.28586@racer.site","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-17T13:38:01Z","receivedAt":"2007-09-17T13:38:01Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"[Cc'd Eric since he's the expert on git-svn]\n\nOn 9/17/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Mon, 17 Sep 2007, Lars Hjemli wrote:\n>\n> > When 'git-svn dcommit' decides which commits it should push back\n> > subversion, it scans the output from 'git-log --first-parent HEAD'\n> > looking for embedded 'git-svn-id' lines. These lines contain the url\n> > of the upstream subversion repository + the subversion revision\n> > number.\n>\n> > So the problem with fast-forward merges of subversion branches is that\n> > the output from 'git-log --first-parent HEAD' will show commits from the\n> > wrong subversion branch (the fast-forwarded commits).\n>\n> Ah, I think I know what you're trying to get at. But \"git svn fetch &&\n> git rebase git-svn\" might be a better approach than \"git svn fetch && git\n> merge --no-ff git-svn\", no?\n\nIf I'm understanding you right: no. After a rebase, the commits would\nbe ignored by git-svn when looking for the subversion upstream branch\n(since the commit SHA1's would no longer match the ones stored in\ngit-svn's rev_db), but the subversion history would look like\n'cherry-picked n commits from merged branch' after dcommit.\n\n-- \nlarsh\n"},{"id":"53313","messageId":"8c5c35580709170640w3b55079bt8702e75802a81e@mail.gmail.com","threadId":"9893","inReplyTo":"20070917133742.GA10923@pe.Belkin","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-17T13:40:49Z","receivedAt":"2007-09-17T13:40:49Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/17/07, Chris Shoemaker wrote:\n> On Mon, Sep 17, 2007 at 02:23:38PM +0100, Johannes Schindelin wrote:\n> > Ah, I think I know what you're trying to get at. But \"git svn fetch &&\n> > git rebase git-svn\" might be a better approach [...]\n>\n> BTW, this is spelled \"git svn rebase\" these days.\n\nNot in this case, since 'git-svn rebase' would fall in the same trap\nas 'git-svn dcommit'.\n\n-- \nlarsh\n"},{"id":"53314","messageId":"Pine.LNX.4.64.0709171452030.28586@racer.site","threadId":"9893","inReplyTo":"20070917133742.GA10923@pe.Belkin","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-17T13:52:37Z","receivedAt":"2007-09-17T13:52:37Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 17 Sep 2007, Chris Shoemaker wrote:\n\n> On Mon, Sep 17, 2007 at 02:23:38PM +0100, Johannes Schindelin wrote:\n>\n> > \"git svn fetch && git rebase git-svn\" might be a better approach [...]\n> \n> BTW, this is spelled \"git svn rebase\" these days.\n\nHeh. Missed that.\n\nThanks,\nDscho\n"},{"id":"53316","messageId":"Pine.LNX.4.64.0709171454031.28586@racer.site","threadId":"9893","inReplyTo":"8c5c35580709170638mc0c8279pa86d71bd79fd3084@mail.gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-17T13:57:29Z","receivedAt":"2007-09-17T13:57:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 17 Sep 2007, Lars Hjemli wrote:\n\n> [Cc'd Eric since he's the expert on git-svn]\n> \n> On 9/17/07, Johannes Schindelin wrote:\n>\n> > Ah, I think I know what you're trying to get at. But \"git svn fetch \n> > && git rebase git-svn\" might be a better approach than \"git svn fetch \n> > && git merge --no-ff git-svn\", no?\n> \n> If I'm understanding you right: no. After a rebase, the commits would be \n> ignored by git-svn when looking for the subversion upstream branch \n> (since the commit SHA1's would no longer match the ones stored in \n> git-svn's rev_db), but the subversion history would look like \n> 'cherry-picked n commits from merged branch' after dcommit.\n\nI feel that I am not really qualified here, since I am a strict git-svn \n_user_, but AFAICT it worked here all the time, _especially_ with fast \nforwards. The trick is that all commits that were added after the branch \npoint do _not_ contain any svn lines.\n\nBut then, I do not use svn branches here, and that might be the problem?\n\nCiao,\nDscho\n"},{"id":"53317","messageId":"8c5c35580709170712v2f5df7b1w8fa0377b69f24988@mail.gmail.com","threadId":"9893","inReplyTo":"Pine.LNX.4.64.0709171454031.28586@racer.site","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-17T14:12:56Z","receivedAt":"2007-09-17T14:12:56Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/17/07, Johannes Schindelin wrote:\n> But then, I do not use svn branches here, and that might be the problem?\n\nProbably. The case I'm trying to solve is:\n -git-svn branch A is merged into git-svn branch B\n -A is a fast-forward of B\n\nThis might look unrealistic, but it happened to me today when I wanted\nto merge a feature-branch into a relase-branch. The release-branch had\npreviously been merged into the feature-branch (to get a few\nbugfixes), but the release-branch had not changed since this merge. So\nwhen merging the feature-branch into the release-branch it just\nfast-forwarded, leaving me with an 'un-dcomittable' release-branch. I\nobviously could have done the merge in subversion (haha!), but doing\nit in git preserves the correct history.\n\nBtw: I have redone the merge with --no-ff, and dcommit then worked\nlike a charm ;-)\n\n-- \nlarsh\n"},{"id":"53320","messageId":"Pine.LNX.4.64.0709171603090.28586@racer.site","threadId":"9893","inReplyTo":"8c5c35580709170712v2f5df7b1w8fa0377b69f24988@mail.gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-17T15:05:44Z","receivedAt":"2007-09-17T15:05:44Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 17 Sep 2007, Lars Hjemli wrote:\n\n> On 9/17/07, Johannes Schindelin wrote:\n> > But then, I do not use svn branches here, and that might be the problem?\n> \n> Probably. The case I'm trying to solve is:\n> -git-svn branch A is merged into git-svn branch B\n> -A is a fast-forward of B\n> \n> This might look unrealistic, but it happened to me today when I wanted\n> to merge a feature-branch into a relase-branch. The release-branch had\n> previously been merged into the feature-branch (to get a few\n> bugfixes), but the release-branch had not changed since this merge. So\n> when merging the feature-branch into the release-branch it just\n> fast-forwarded, leaving me with an 'un-dcomittable' release-branch. I\n> obviously could have done the merge in subversion (haha!), but doing\n> it in git preserves the correct history.\n> \n> Btw: I have redone the merge with --no-ff, and dcommit then worked\n> like a charm ;-)\n\nYep, I can see that now.\n\nBut maybe there is a better method to detect the latest svn id, by not \nonly looking up the svn ids, but making sure that they come from the \ncurrent branch?\n\n(I'm happily unaware of git-svn's internals, so that might not be \nfeasible... But I think that it might be worth fixing that for the git-svn \nidiot like me, since I would never guess that I have to specify --no-ff \nwhen working on branches that come from git-svn...)\n\nCiao,\nDscho\n"},{"id":"53321","messageId":"8c5c35580709170817s467fa7dv375952f872bba0e3@mail.gmail.com","threadId":"9893","inReplyTo":"Pine.LNX.4.64.0709171603090.28586@racer.site","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-17T15:17:57Z","receivedAt":"2007-09-17T15:17:57Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/17/07, Johannes Schindelin wrote:\n> Hi,\n>\n> On Mon, 17 Sep 2007, Lars Hjemli wrote:\n>\n> > On 9/17/07, Johannes Schindelin wrote:\n> > > But then, I do not use svn branches here, and that might be the problem?\n> >\n> > Probably. The case I'm trying to solve is:\n> > -git-svn branch A is merged into git-svn branch B\n> > -A is a fast-forward of B\n> >\n> > This might look unrealistic, but it happened to me today when I wanted\n> > to merge a feature-branch into a relase-branch. The release-branch had\n> > previously been merged into the feature-branch (to get a few\n> > bugfixes), but the release-branch had not changed since this merge. So\n> > when merging the feature-branch into the release-branch it just\n> > fast-forwarded, leaving me with an 'un-dcomittable' release-branch. I\n> > obviously could have done the merge in subversion (haha!), but doing\n> > it in git preserves the correct history.\n> >\n> > Btw: I have redone the merge with --no-ff, and dcommit then worked\n> > like a charm ;-)\n>\n> Yep, I can see that now.\n>\n> But maybe there is a better method to detect the latest svn id, by not\n> only looking up the svn ids, but making sure that they come from the\n> current branch?\n\nActually, I looked into this last week (my --upstream rants), and I\nguess git-svn could use the --track information in .git/config (if\npresent) as a sanity check when resolving the upstream. But this would\nstill make the subversion history look like crap after a fast-forward\nmerge of the kind I was messing with today. It was logically a merge,\nbut if dcommit had worked 'correctly' it would have created ~150 new\nrevisions in the release-branch instead of the single merge commit.\n\n> (I'm happily unaware of git-svn's internals, so that might not be\n> feasible... But I think that it might be worth fixing that for the git-svn\n> idiot like me, since I would never guess that I have to specify --no-ff\n> when working on branches that come from git-svn...)\n\nIn the normal cases there is no need for --no-ff, only in degenerated\ncases like the one I stumbled upon today ;-)\n\nI'll resend the patch with a link from merge-options.txt to\ngit-svn.txt and try to describe (in git-svn.txt) when to use --no-ff.\n\n-- \nlarsh\n"},{"id":"53324","messageId":"20070917160755.GA11287@pe.Belkin","threadId":"9893","inReplyTo":"8c5c35580709170712v2f5df7b1w8fa0377b69f24988@mail.gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2007-09-17T16:07:55Z","receivedAt":"2007-09-17T16:07:55Z","isPatch":true,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Mon, Sep 17, 2007 at 04:12:56PM +0200, Lars Hjemli wrote:\n> On 9/17/07, Johannes Schindelin wrote:\n> > But then, I do not use svn branches here, and that might be the problem?\n> \n> Probably. The case I'm trying to solve is:\n> -git-svn branch A is merged into git-svn branch B\n> -A is a fast-forward of B\n\nAh, now I see what you mean. But, IIUC, if you want to dcommit your\nmerge, you should treat it the way svn treats it, with git-merge\n--squash. Then, dcommit won't be confused about the branch you're\ncommitting to.\n\n-chris\n\n> \n> This might look unrealistic, but it happened to me today when I wanted\n> to merge a feature-branch into a relase-branch. The release-branch had\n> previously been merged into the feature-branch (to get a few\n> bugfixes), but the release-branch had not changed since this merge. So\n> when merging the feature-branch into the release-branch it just\n> fast-forwarded, leaving me with an 'un-dcomittable' release-branch. I\n> obviously could have done the merge in subversion (haha!), but doing\n> it in git preserves the correct history.\n> \n> Btw: I have redone the merge with --no-ff, and dcommit then worked\n> like a charm ;-)\n> \n> -- \n> larsh\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"53329","messageId":"8c5c35580709170914n60bf3580r963567fcaac1d2e9@mail.gmail.com","threadId":"9893","inReplyTo":"20070917160755.GA11287@pe.Belkin","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-17T16:14:56Z","receivedAt":"2007-09-17T16:14:56Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/17/07, Chris Shoemaker wrote:\n> On Mon, Sep 17, 2007 at 04:12:56PM +0200, Lars Hjemli wrote:\n> > On 9/17/07, Johannes Schindelin wrote:\n> > > But then, I do not use svn branches here, and that might be the problem?\n> >\n> > Probably. The case I'm trying to solve is:\n> > -git-svn branch A is merged into git-svn branch B\n> > -A is a fast-forward of B\n>\n> Ah, now I see what you mean. But, IIUC, if you want to dcommit your\n> merge, you should treat it the way svn treats it, with git-merge\n> --squash. Then, dcommit won't be confused about the branch you're\n> committing to.\n\nYeah, --squash is a viable option (I _almost_ used it ;-) but I wanted\nto keep the merge-history on the git side (without modifying the\ngrafts-file).\n\n-- \nlarsh\n"},{"id":"53330","messageId":"11900461843997-git-send-email-hjemli@gmail.com","threadId":"9893","inReplyTo":"8c5c35580709170817s467fa7dv375952f872bba0e3@mail.gmail.com","subject":"[PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-17T16:23:04Z","receivedAt":"2007-09-17T16:23:04Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"This option forces fast-forward merges to create a \"true\" merge commit,\ni.e. a commit with multiple parents.\n\nAlthough a fast-forward merge would normally be the right thing to do with\ngit branches, it is suboptimal when operating on git-svn branches since it\nmakes 'git-svn dcommit' fail to recognize the correct upstream subversion\nbranch. But performing such a merge with --no-ff specified will both make\ngit-svn dcommit recognize the correct upstream and create the logically\ncorrect history in subversion (the merge performed in git will be recorded\nas a single revision in subversion, not as a series of revisions seemingly\ncherry-picked from the merged branch).\n\nSigned-off-by: Lars Hjemli \n---\n\nWhen updating git-svn.txt, I noticed that we might want to update the \nsection \"DESIGN PHILOSOPHY\". Eric?\n\n\n Documentation/git-svn.txt | 13 +++++++++++++\n Documentation/merge-options.txt | 5 +++++\n git-merge.sh | 13 +++++++++++--\n t/t6028-merge-up-to-date.sh | 25 +++++++++++++++++++++++++\n 4 files changed, 54 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\nindex be2e34e..c510c21 100644\n--- a/Documentation/git-svn.txt\n+++ b/Documentation/git-svn.txt\n@@ -475,6 +475,19 @@ use 'git-svn rebase' to update your work branch instead of 'git pull' or\n when committing into SVN, which can lead to merge commits reversing\n previous commits in SVN.\n \n+If you use 'git-svn dcommit' to commit your local work to the upstream\n+subversion branch, merge commits are usually handled correctly, i.e.\n+git-svn will only follow the first parent of each merge commit and create\n+a single subversion revision for each of them. An exception is when two\n+subversion branches has been merged locally and the merge ended up as a\n+fast-forward operation. This will make git-svn belive that there are no\n+local changes to dcommit. To work around this issue, one can redo the\n+merge using the --no-ff option:\n+\n+ $ git reset --hard HEAD@{1} ## undo the fast-forward merge\n+ $ git merge --no-ff \n+\n+\n DESIGN PHILOSOPHY\n -----------------\n Merge tracking in Subversion is lacking and doing branched development\ndiff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt\nindex d64c259..b34b888 100644\n--- a/Documentation/merge-options.txt\n+++ b/Documentation/merge-options.txt\n@@ -25,3 +25,8 @@\n \tIf there is no `-s` option, a built-in list of strategies\n \tis used instead (`git-merge-recursive` when merging a single\n \thead, `git-merge-octopus` otherwise).\n+\n+--no-ff::\n+\tForce the creation of a merge commit even when the merge would\n+\thave resolved as a fast-forward operation. See gitlink:git-svn[1]\n+\tfor a use-case for this option.\ndiff --git a/git-merge.sh b/git-merge.sh\nindex 3a01db0..13b98e6 100755\n--- a/git-merge.sh\n+++ b/git-merge.sh\n@@ -3,7 +3,7 @@\n # Copyright (c) 2005 Junio C Hamano\n #\n \n-USAGE='[-n] [--summary] [--no-commit] [--squash] [-s ] [-m=] +'\n+USAGE='[-n] [--summary] [--no-commit] [--no-ff] [--squash] [-s ] [-m=] +'\n \n SUBDIRECTORY_OK=Yes\n . git-sh-setup\n@@ -165,6 +165,10 @@ do\n \t\tmerge_msg=\"$1\"\n \t\thave_message=t\n \t\t;;\n+\t--no-ff)\n+\t\tno_ff=t\n+\t\tno_fast_forward_strategies=$all_strategies\n+\t\t;;\n \t-*)\tusage ;;\n \t*)\tbreak ;;\n \tesac\n@@ -444,7 +448,12 @@ done\n # auto resolved the merge cleanly.\n if test '' != \"$result_tree\"\n then\n- parents=$(git show-branch --independent \"$head\" \"$@\" | sed -e 's/^/-p /')\n+ if test $no_ff = 't'\n+ then\n+ parents=$(git rev-parse \"$head\" \"$@\" | sed -e 's/^/-p /')\n+ else\n+ parents=$(git show-branch --independent \"$head\" \"$@\" | sed -e 's/^/-p /')\n+ fi\n result_commit=$(printf '%s\\n' \"$merge_msg\" | git commit-tree $result_tree $parents) || exit\n finish \"$result_commit\" \"Merge made by $wt_strategy.\"\n dropsave\ndiff --git a/t/t6028-merge-up-to-date.sh b/t/t6028-merge-up-to-date.sh\nindex f8f3e3f..afd74e2 100755\n--- a/t/t6028-merge-up-to-date.sh\n+++ b/t/t6028-merge-up-to-date.sh\n@@ -10,12 +10,14 @@ test_expect_success setup '\n \ttest_tick &&\n \tgit commit -m initial &&\n \tgit tag c0 &&\n+\tc0=$(git rev-parse c0)\n \n \techo second >file &&\n \tgit add file &&\n \ttest_tick &&\n \tgit commit -m second &&\n \tgit tag c1 &&\n+\tc1=$(git rev-parse c1)\n \tgit branch test\n '\n \n@@ -41,6 +43,16 @@ test_expect_success 'merge -s recursive fast-forward' '\n \n '\n \n+test_expect_success 'merge -s recursive --no-ff' '\n+\n+\tgit reset --hard c0 &&\n+\ttest_tick &&\n+\tgit merge -s recursive --no-ff c1 &&\n+\ttest $c0 = $(git rev-parse HEAD^1) &&\n+\ttest $c1 = $(git rev-parse HEAD^2)\n+\n+'\n+\n test_expect_success 'merge -s ours up-to-date' '\n \n \tgit reset --hard c1 &&\n@@ -63,6 +75,19 @@ test_expect_success 'merge -s ours fast-forward' '\n \n '\n \n+test_expect_success 'merge -s ours --no-ff' '\n+\n+\tgit reset --hard c0 &&\n+\ttest_tick &&\n+\tgit merge -s ours --no-ff c1 &&\n+\texpect=$(git rev-parse c0^{tree}) &&\n+\tcurrent=$(git rev-parse HEAD^{tree}) &&\n+\ttest \"$expect\" = \"$current\" &&\n+\ttest $c0 = $(git rev-parse HEAD^1) &&\n+\ttest $c1 = $(git rev-parse HEAD^2)\n+\n+'\n+\n test_expect_success 'merge -s subtree up-to-date' '\n \n \tgit reset --hard c1 &&\n-- \n1.5.3.1.92.g2f5e\n"},{"id":"53384","messageId":"20070918005013.GA6368@muzzle","threadId":"9893","inReplyTo":"11900461843997-git-send-email-hjemli@gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-18T00:50:13Z","receivedAt":"2007-09-18T00:50:13Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Lars Hjemli wrote:\n> This option forces fast-forward merges to create a \"true\" merge commit,\n> i.e. a commit with multiple parents.\n> \n> Although a fast-forward merge would normally be the right thing to do with\n> git branches, it is suboptimal when operating on git-svn branches since it\n> makes 'git-svn dcommit' fail to recognize the correct upstream subversion\n> branch. But performing such a merge with --no-ff specified will both make\n> git-svn dcommit recognize the correct upstream and create the logically\n> correct history in subversion (the merge performed in git will be recorded\n> as a single revision in subversion, not as a series of revisions seemingly\n> cherry-picked from the merged branch).\n> \n> Signed-off-by: Lars Hjemli \n\nWould automatically enabling --no-ff when it detects merging of two (or\nmore) SVN branches be a good thing? We can add scripting support to\ngit-svn for detecting if any given commit is really from SVN or not.\nThen we could do something like this in git-merge\n\n---------------------------- 8< --------------------------------\nif git-svn test-svn-commits \"$@\"\nthen\n\tno_ff=t\n\tno_fast_forward_strategies=$all_strategies\nfi\n---------------------------- 8< --------------------------------\n\nIt'd probably prevent a lot of users from shooting themselves in the\nfoot if they forget to read or learn about the --no-ff option.\n\n> ---\n> \n> When updating git-svn.txt, I noticed that we might want to update the \n> section \"DESIGN PHILOSOPHY\". Eric?\n\nYeah. That's very much out of date. I'll update it in a bit.\n\n-- \nEric Wong\n"},{"id":"53390","messageId":"7vk5qoye2t.fsf@gitster.siamese.dyndns.org","threadId":"9893","inReplyTo":"20070918005013.GA6368@muzzle","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-18T01:09:14Z","receivedAt":"2007-09-18T01:09:14Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Wong writes:\n\n> Would automatically enabling --no-ff when it detects merging of two (or\n> more) SVN branches be a good thing? We can add scripting support to\n> git-svn for detecting if any given commit is really from SVN or not.\n> Then we could do something like this in git-merge\n>\n> ---------------------------- 8< --------------------------------\n> if git-svn test-svn-commits \"$@\"\n> then\n> \tno_ff=t\n> \tno_fast_forward_strategies=$all_strategies\n> fi\n> ---------------------------- 8< --------------------------------\n\nYuck, do I understand you correctly? Are you talking about\nadding dependency on git-svn to git-merge?\n"},{"id":"53392","messageId":"20070918013915.GC13571@hand.yhbt.net","threadId":"9893","inReplyTo":"7vk5qoye2t.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-18T01:39:15Z","receivedAt":"2007-09-18T01:39:15Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano wrote:\n> Eric Wong writes:\n> \n> > Would automatically enabling --no-ff when it detects merging of two (or\n> > more) SVN branches be a good thing? We can add scripting support to\n> > git-svn for detecting if any given commit is really from SVN or not.\n> > Then we could do something like this in git-merge\n> >\n> > ---------------------------- 8< --------------------------------\n> > if git-svn test-svn-commits \"$@\"\n> > then\n> > \tno_ff=t\n> > \tno_fast_forward_strategies=$all_strategies\n> > fi\n> > ---------------------------- 8< --------------------------------\n> \n> Yuck, do I understand you correctly? Are you talking about\n> adding dependency on git-svn to git-merge?\n\nIt could be another simple independent script, then. git-svn isn't\ninstalled on most distros when git is, so it won't always work...\n\n-- \nEric Wong\n"},{"id":"53397","messageId":"8c5c35580709172312w55613a1bw8cc58b200c526fab@mail.gmail.com","threadId":"9893","inReplyTo":"20070918005013.GA6368@muzzle","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-18T06:12:42Z","receivedAt":"2007-09-18T06:12:42Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/18/07, Eric Wong wrote:\n> Would automatically enabling --no-ff when it detects merging of two (or\n> more) SVN branches be a good thing?\n\nI'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.\n\n--\nlarsh\n"},{"id":"53398","messageId":"20070918062341.GD13571@hand.yhbt.net","threadId":"9893","inReplyTo":"8c5c35580709172312w55613a1bw8cc58b200c526fab@mail.gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2007-09-18T06:23:41Z","receivedAt":"2007-09-18T06:23:41Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Lars Hjemli wrote:\n> On 9/18/07, Eric Wong wrote:\n> > Would automatically enabling --no-ff when it detects merging of two (or\n> > more) SVN branches be a good thing?\n> \n> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.\n\nThat still involves having to get the user to use something new to avoid\nshooting themselves in the foot. Perhaps putting a\n\"test -d $GIT_DIR/svn\" condition in front of the git-svn call I proposed\nin git-merge would be alright.\n\nIf anybody else is thinking about 'git-svn rebase', this is completely\ndifferent. Using git-rebase alone doesn't allow git-svn users to shoot\nthemselves in the foot like git-merge does. 'git-svn rebase' only\nserves to minimize typing and brain power needed to operate git-svn.\n\n-- \nEric Wong\n"},{"id":"53399","messageId":"7v4phsxy55.fsf@gitster.siamese.dyndns.org","threadId":"9893","inReplyTo":"8c5c35580709172312w55613a1bw8cc58b200c526fab@mail.gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-09-18T06:53:26Z","receivedAt":"2007-09-18T06:53:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Lars Hjemli\" writes:\n\n> On 9/18/07, Eric Wong wrote:\n>> Would automatically enabling --no-ff when it detects merging of two (or\n>> more) SVN branches be a good thing?\n>\n> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.\n\nThat unfortunately does not solve the problem.\n"},{"id":"53407","messageId":"46EF7EA1.6020402@vilain.net","threadId":"9893","inReplyTo":"7v4phsxy55.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-09-18T07:30:41Z","receivedAt":"2007-09-18T07:30:41Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \"Lars Hjemli\" writes:\n> \n>> On 9/18/07, Eric Wong wrote:\n>>> Would automatically enabling --no-ff when it detects merging of two (or\n>>> more) SVN branches be a good thing?\n>> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.\n> \n> That unfortunately does not solve the problem.\n\nI think we 'just' need to fix pushing merges back to SVN - so that they\nproperly set Subversion 1.5+ (and possibly SVK) merge attributes - and\nif it is ambiguous which branch to push to, force the user to decide.\n\nSam.\n"},{"id":"53411","messageId":"8c5c35580709180102l10e89094tab801cd5742c6415@mail.gmail.com","threadId":"9893","inReplyTo":"7v4phsxy55.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-18T08:02:44Z","receivedAt":"2007-09-18T08:02:44Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/18/07, Junio C Hamano wrote:\n> \"Lars Hjemli\" writes:\n>\n> > On 9/18/07, Eric Wong wrote:\n> >> Would automatically enabling --no-ff when it detects merging of two (or\n> >> more) SVN branches be a good thing?\n> >\n> > I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.\n>\n> That unfortunately does not solve the problem.\n>\n\nThe problem we're trying to solve is to somehow avoid fast-forward\nmerges between git-svn branches, right?\n\nI don't think it's a big issue in itself. If a fast-forward occurs,\nwhat will happen is basically that git-svn will guess the wrong\nupstream branch and then proceed to do nothing [1]. The user can\nalways recover from this state with 'git-reset' and 'git-merge\n--no-ff'. So I think the result of a fast-forward merge between\ngit-svn branches is annoying, but not fatal [2].\n\nBut a closely related issue is that git-svn shouldn't dcommit to the\nwrong upstream (even in the case of a fast-forward merge). We need a\nway to explicitly show the link between the local and remote svn\nbranch (something like .git/config perhaps).\n\n-- \nlarsh\n\n[1] If the merged-in branch had local commits they will be 'dcommited'\nto the correct upstream of the merged-in branch, which isn't to bad\n\n[2] if git-svn could be fixed to handle even the ff case, someone\ncould actually prefer to get the 'cherry-picked' history in\nsubversion. I don't, hence my --no-ff patch, but I'm not at all\ncertain this should be _forced_ on git-svn branches.\n"},{"id":"53428","messageId":"46EF9687.6070304@vilain.net","threadId":"9893","inReplyTo":"46EF7EA1.6020402@vilain.net","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-09-18T09:12:39Z","receivedAt":"2007-09-18T09:12:39Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Sam Vilain wrote:\n>>> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner.\n>>> \n>> That unfortunately does not solve the problem.\n>> \n>\n> I think we 'just' need to fix pushing merges back to SVN - so that they\n> properly set Subversion 1.5+ (and possibly SVK) merge attributes - and\n> if it is ambiguous which branch to push to, force the user to decide.\n> \n\nWhoops, I missed the thrust of the current issue; it won't be ambiguous,\nit'll be unambiguously wrong, so this doesn't apply.\n\nIn which case I'd guess the moral equivalent of --track would have to go\nforward, or a per-branch basis.\n\nI think that writing a real fast-forward merge should only happen on\ndcommit, not git merge, because that is what is required for SVN. \nIdeally, it should also have the property that it doesn't cycle; null\nmerges between two branches should not carry on indefinitely.\n\nSam.\n"},{"id":"53449","messageId":"8c5c35580709180419i4500a2d4s8a997d45dd31944e@mail.gmail.com","threadId":"9893","inReplyTo":"46EF9687.6070304@vilain.net","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-18T11:19:08Z","receivedAt":"2007-09-18T11:19:08Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/18/07, Sam Vilain wrote:\n> I think that writing a real fast-forward merge should only happen on\n> dcommit, not git merge, because that is what is required for SVN.\n\nI don't think git-svn has any way of knowing that the user wanted a\nmerge, unless a merge commit is present. So the user would have to\nspecify the set of commits which should be considered a merge during\ndcommit (this would actually resemble how merges are performed in\nsubversion).\n\nSidenote: this might be slightly controversial, but I've sometimes\nmissed a --no-ff option to 'git merge' when working on plain git\nrepositories; IMHO preserving the 'logical' merge history when the\nmerge of a topic branch results in a fast-forward can be interesting.\n\n-- \nlarsh\n"},{"id":"53455","messageId":"46EFBB9A.5070404@vilain.net","threadId":"9893","inReplyTo":"8c5c35580709180419i4500a2d4s8a997d45dd31944e@mail.gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-09-18T11:50:50Z","receivedAt":"2007-09-18T11:50:50Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Lars Hjemli wrote:\n> On 9/18/07, Sam Vilain wrote:\n> \n>> I think that writing a real fast-forward merge should only happen on\n>> dcommit, not git merge, because that is what is required for SVN.\n>> \n>\n> I don't think git-svn has any way of knowing that the user wanted a\n> merge, unless a merge commit is present. So the user would have to\n> specify the set of commits which should be considered a merge during\n> dcommit (this would actually resemble how merges are performed in\n> subversion).\n> \n\nSure it can. If you're committing to branch X, and the current tree has\na whole lot of commits above that, then it should do the only thing you\ncan do with SVN.\n\nWhich is write a squash commit, and set the \"svn:merge\" and/or\n\"svk:merge\" properties to represent what happened.\n\n> Sidenote: this might be slightly controversial, but I've sometimes\n> missed a --no-ff option to 'git merge' when working on plain git\n> repositories; IMHO preserving the 'logical' merge history when the\n> merge of a topic branch results in a fast-forward can be interesting.\n\nIf you really want one, use git commit-tree directly.\n\nSam.\n"},{"id":"53459","messageId":"8c5c35580709180503g24ef6c5hda2877e2215ba58d@mail.gmail.com","threadId":"9893","inReplyTo":"46EFBB9A.5070404@vilain.net","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-18T12:03:39Z","receivedAt":"2007-09-18T12:03:39Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"[...sorry for making this such a long thread...]\n\nOn 9/18/07, Sam Vilain wrote:\n> Lars Hjemli wrote:\n> > On 9/18/07, Sam Vilain wrote:\n> >\n> >> I think that writing a real fast-forward merge should only happen on\n> >> dcommit, not git merge, because that is what is required for SVN.\n> >>\n> >\n> > I don't think git-svn has any way of knowing that the user wanted a\n> > merge, unless a merge commit is present. So the user would have to\n> > specify the set of commits which should be considered a merge during\n> > dcommit (this would actually resemble how merges are performed in\n> > subversion).\n> >\n>\n> Sure it can. If you're committing to branch X, and the current tree has\n> a whole lot of commits above that, then it should do the only thing you\n> can do with SVN.\n>\n> Which is write a squash commit, and set the \"svn:merge\" and/or\n> \"svk:merge\" properties to represent what happened.\n\nI often have prepared a series of local commits which I _want_ to\npreserve as different subversion revisions.\n\nAlso, doing a --squash means that I loose the merge history in git\n(and then I need to edit the grafts file again)\n\n>\n> > Sidenote: this might be slightly controversial, but I've sometimes\n> > missed a --no-ff option to 'git merge' when working on plain git\n> > repositories; IMHO preserving the 'logical' merge history when the\n> > merge of a topic branch results in a fast-forward can be interesting.\n>\n> If you really want one, use git commit-tree directly.\n\nYeah, that's an option, but --no-ff is somewhat less work ;-)\n\n--\nlarsh\n"},{"id":"53464","messageId":"Pine.LNX.4.64.0709181319050.28586@racer.site","threadId":"9893","inReplyTo":"8c5c35580709180419i4500a2d4s8a997d45dd31944e@mail.gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-09-18T12:29:25Z","receivedAt":"2007-09-18T12:29:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 18 Sep 2007, Lars Hjemli wrote:\n\n> Sidenote: this might be slightly controversial, but I've sometimes \n> missed a --no-ff option to 'git merge' when working on plain git \n> repositories; IMHO preserving the 'logical' merge history when the merge \n> of a topic branch results in a fast-forward can be interesting.\n\nLinus explained a lot of times why this is wrong. It encourages \nupstream-downstream thinking. We should really turn this into a FAQ.\n\nCiao,\nDscho\n"},{"id":"53467","messageId":"8c5c35580709180538o15619c14uf3125bea2360f88b@mail.gmail.com","threadId":"9893","inReplyTo":"Pine.LNX.4.64.0709181319050.28586@racer.site","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-18T12:38:52Z","receivedAt":"2007-09-18T12:38:52Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"[...stripped the Cc, as we're slightly changing topic...]\n\nOn 9/18/07, Johannes Schindelin wrote:\n> On Tue, 18 Sep 2007, Lars Hjemli wrote:\n> > Sidenote: this might be slightly controversial, but I've sometimes\n> > missed a --no-ff option to 'git merge' when working on plain git\n> > repositories; IMHO preserving the 'logical' merge history when the merge\n> > of a topic branch results in a fast-forward can be interesting.\n>\n> Linus explained a lot of times why this is wrong. It encourages\n> upstream-downstream thinking. We should really turn this into a FAQ.\n\nWell, the cases where I've wanted to do this is when I've developed\nsome new feature in cgit as a topic branch. I've then merged the topic\nbranch into my master branch which had been idle since the creation of\nthe topic branch (cgit doesn't get as many patches as git...). So I\nget a fast-forward and my precious topic-branch is no longer visible\n(at least for anyone cloning my repo). Not very important, but I'd\nlike to preserve the fact that this was a topic branch. How would this\nencourage 'upstream-downstream thinking'?\n\n-- \nlarsh\n"},{"id":"53474","messageId":"46EFD0F8.5050603@vilain.net","threadId":"9893","inReplyTo":"8c5c35580709180503g24ef6c5hda2877e2215ba58d@mail.gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-09-18T13:22:00Z","receivedAt":"2007-09-18T13:22:00Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Lars Hjemli wrote:\n> [...sorry for making this such a long thread...]\n>\n> On 9/18/07, Sam Vilain wrote:\n> \n>> Lars Hjemli wrote:\n>> \n>>> On 9/18/07, Sam Vilain wrote:\n>>>\n>>> \n>>>> I think that writing a real fast-forward merge should only happen on\n>>>> dcommit, not git merge, because that is what is required for SVN.\n>>>>\n>>>> \n>>> I don't think git-svn has any way of knowing that the user wanted a\n>>> merge, unless a merge commit is present. So the user would have to\n>>> specify the set of commits which should be considered a merge during\n>>> dcommit (this would actually resemble how merges are performed in\n>>> subversion).\n>>>\n>>> \n>> Sure it can. If you're committing to branch X, and the current tree has\n>> a whole lot of commits above that, then it should do the only thing you\n>> can do with SVN.\n>>\n>> Which is write a squash commit, and set the \"svn:merge\" and/or\n>> \"svk:merge\" properties to represent what happened.\n>> \n>\n> I often have prepared a series of local commits which I _want_ to\n> preserve as different subversion revisions.\n> \n\nBut for the scenario we are discussing the revisions already exist\nupstream otherwise there would be no fast forward merge. So, if you\nwant that behaviour you can use cherry-pick on the git side and the\ncorrect behaviour for git-svn is to write svn merge properties.\n\n> Also, doing a --squash means that I loose the merge history in git\n> (and then I need to edit the grafts file again)\n> \n\nThere is no merge history in git, it was a fast forward.\n\n>>> Sidenote: this might be slightly controversial, but I've sometimes\n>>> missed a --no-ff option to 'git merge' when working on plain git\n>>> repositories; IMHO preserving the 'logical' merge history when the\n>>> merge of a topic branch results in a fast-forward can be interesting.\n>>> \n>> If you really want one, use git commit-tree directly.\n>> \n> Yeah, that's an option, but --no-ff is somewhat less work ;-)\n> \n\nSure. I just don't see a good use case for it from this yet.\n\nSam.\n"},{"id":"53481","messageId":"8c5c35580709180701m54810d80nefa4704abb8797dd@mail.gmail.com","threadId":"9893","inReplyTo":"46EFD0F8.5050603@vilain.net","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-18T14:01:46Z","receivedAt":"2007-09-18T14:01:46Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/18/07, Sam Vilain wrote:\n> Lars Hjemli wrote:\n> > On 9/18/07, Sam Vilain wrote:\n> >> If you really want one, use git commit-tree directly.\n> >>\n> > Yeah, that's an option, but --no-ff is somewhat less work ;-)\n> >\n>\n> Sure. I just don't see a good use case for it from this yet.\n\nOk. I'll try to explain why I needed --no-ff in the first place:\n\nI have two git-svn brances, lets call them FEATURE and RELEASE. At one\npoint, I did\n $ git checkout FEATURE\n $ git merge RELEASE\n $ git svn dcommit\n\nNow, my coworkers can continue testing/developing on top of the\nsubversion branch FEATURE (I'm currently the only git user), knowing\nthat every bugfix from RELEASE have been merged.\n\nA few days later, FEATURE is completed and tested and should be\nintegrated in RELEASE. I did\n\n $ git checkout RELEASE\n $ git merge FEATURE\n $ git svn dcommit -n\n\nand noticed that git-svn wanted to commit the result to FEATURE, since\nthe merge actually was a fast-forward. If this was a a pure git\nenvironment it would be no problem, but as I needed to get a merge\nrevision on top of the subversion RELEASE branch, I was in trouble.\n\nMy options:\n* rebase FEATURE onto RELEASE: this would have duplicated ~150\nrevisions from FEATURE onto RELEASE in subversion\n* merge --squash: this would have created the wanted history in\nsubversion, but my git history would have lacked the info that\neverything in FEATURE had been integrated into RELEASE (this could\nhave been fixed by editing the grafts file)\n* merge --no-ff: this made both the subversion history and my local\ngit history reflect what actually happened.\n\nSo I went for the --no-ff option.\n\nIf this use-case isn't good enough, oh well. I can always carry the\npatch forward in my git repo ;-)\n\n--\nlarsh\n"},{"id":"53483","messageId":"46EFE20C.6010904@vilain.net","threadId":"9893","inReplyTo":"8c5c35580709180701m54810d80nefa4704abb8797dd@mail.gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2007-09-18T14:34:52Z","receivedAt":"2007-09-18T14:34:52Z","isPatch":true,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"Lars Hjemli wrote:\n> Ok. I'll try to explain why I needed --no-ff in the first place:\n>\n> I have two git-svn brances, lets call them FEATURE and RELEASE. At one\n> point, I did\n> $ git checkout FEATURE\n> $ git merge RELEASE\n> $ git svn dcommit\n>\n> Now, my coworkers can continue testing/developing on top of the\n> subversion branch FEATURE (I'm currently the only git user), knowing\n> that every bugfix from RELEASE have been merged.\n>\n> A few days later, FEATURE is completed and tested and should be\n> integrated in RELEASE. I did\n>\n> $ git checkout RELEASE\n> $ git merge FEATURE\n> $ git svn dcommit -n\n>\n> and noticed that git-svn wanted to commit the result to FEATURE, since\n> the merge actually was a fast-forward. If this was a a pure git\n> environment it would be no problem, but as I needed to get a merge\n> revision on top of the subversion RELEASE branch, I was in trouble.\n> \n\nI understand. But if you could specify a target branch of \"RELEASE\" to\ndcommit (which git-svn might know based on which svn tracking branch it\nwas branched from), then it should be able to do the same thing that\n'svn merge' would do on svn 1.5+, or 'svk sm' does. Which is to write\nto the SVN repository a squash merge, and write svn properties to let\nmerge-aware svn tools know which SVN revisions are being squashed.\n\n> My options:\n> * rebase FEATURE onto RELEASE: this would have duplicated ~150\n> revisions from FEATURE onto RELEASE in subversion\n> \n\nYes, not desirable.\n\n> * merge --squash: this would have created the wanted history in\n> subversion, but my git history would have lacked the info that\n> everything in FEATURE had been integrated into RELEASE (this could\n> have been fixed by editing the grafts file)\n> \n\nThis is a current deficiency in git-svn; bidirectional merge tracking is\nnot there yet.\n\n> * merge --no-ff: this made both the subversion history and my local\n> git history reflect what actually happened.\n>\n> So I went for the --no-ff option.\n>\n> If this use-case isn't good enough, oh well. I can always carry the\n> patch forward in my git repo ;-)\n> \n\nAnd you'll probably need to keep it around until bidirectional merge\nhandling is in.\n\nSam.\n"},{"id":"53524","messageId":"20070918225134.GA5906@xp.machine.xx","threadId":"9893","inReplyTo":"11900461843997-git-send-email-hjemli@gmail.com","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Peter Baumann","fromEmail":"waste.manager@gmx.de","sentAt":"2007-09-18T22:51:34Z","receivedAt":"2007-09-18T22:51:34Z","isPatch":true,"sender":{"key":"waste.manager@gmx.de","avatar":null},"body":"On Mon, Sep 17, 2007 at 06:23:04PM +0200, Lars Hjemli wrote:\n> This option forces fast-forward merges to create a \"true\" merge commit,\n> i.e. a commit with multiple parents.\n> \n> Although a fast-forward merge would normally be the right thing to do with\n> git branches, it is suboptimal when operating on git-svn branches since it\n> makes 'git-svn dcommit' fail to recognize the correct upstream subversion\n> branch. But performing such a merge with --no-ff specified will both make\n> git-svn dcommit recognize the correct upstream and create the logically\n> correct history in subversion (the merge performed in git will be recorded\n> as a single revision in subversion, not as a series of revisions seemingly\n> cherry-picked from the merged branch).\n> \n> Signed-off-by: Lars Hjemli \n> ---\n> \n> When updating git-svn.txt, I noticed that we might want to update the \n> section \"DESIGN PHILOSOPHY\". Eric?\n> \n> \n> Documentation/git-svn.txt | 13 +++++++++++++\n> Documentation/merge-options.txt | 5 +++++\n> git-merge.sh | 13 +++++++++++--\n> t/t6028-merge-up-to-date.sh | 25 +++++++++++++++++++++++++\n> 4 files changed, 54 insertions(+), 2 deletions(-)\n> \n> diff --git a/Documentation/git-svn.txt b/Documentation/git-svn.txt\n> index be2e34e..c510c21 100644\n> --- a/Documentation/git-svn.txt\n> +++ b/Documentation/git-svn.txt\n> @@ -475,6 +475,19 @@ use 'git-svn rebase' to update your work branch instead of 'git pull' or\n> when committing into SVN, which can lead to merge commits reversing\n> previous commits in SVN.\n> \n> +If you use 'git-svn dcommit' to commit your local work to the upstream\n> +subversion branch, merge commits are usually handled correctly, i.e.\n> +git-svn will only follow the first parent of each merge commit and create\n> +a single subversion revision for each of them. An exception is when two\n> +subversion branches has been merged locally and the merge ended up as a\n> +fast-forward operation. This will make git-svn belive that there are no\n> +local changes to dcommit. To work around this issue, one can redo the\n> +merge using the --no-ff option:\n> +\n> + $ git reset --hard HEAD@{1} ## undo the fast-forward merge\n> + $ git merge --no-ff \n> +\n> +\n> DESIGN PHILOSOPHY\n> -----------------\n> Merge tracking in Subversion is lacking and doing branched development\n> diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt\n> index d64c259..b34b888 100644\n> --- a/Documentation/merge-options.txt\n> +++ b/Documentation/merge-options.txt\n> @@ -25,3 +25,8 @@\n> \tIf there is no `-s` option, a built-in list of strategies\n> \tis used instead (`git-merge-recursive` when merging a single\n> \thead, `git-merge-octopus` otherwise).\n> +\n> +--no-ff::\n> +\tForce the creation of a merge commit even when the merge would\n> +\thave resolved as a fast-forward operation. See gitlink:git-svn[1]\n> +\tfor a use-case for this option.\n> diff --git a/git-merge.sh b/git-merge.sh\n> index 3a01db0..13b98e6 100755\n> --- a/git-merge.sh\n> +++ b/git-merge.sh\n> @@ -3,7 +3,7 @@\n> # Copyright (c) 2005 Junio C Hamano\n> #\n> \n> -USAGE='[-n] [--summary] [--no-commit] [--squash] [-s ] [-m=] +'\n> +USAGE='[-n] [--summary] [--no-commit] [--no-ff] [--squash] [-s ] [-m=] +'\n> \n> SUBDIRECTORY_OK=Yes\n> . git-sh-setup\n> @@ -165,6 +165,10 @@ do\n> \t\tmerge_msg=\"$1\"\n> \t\thave_message=t\n> \t\t;;\n> +\t--no-ff)\n> +\t\tno_ff=t\n> +\t\tno_fast_forward_strategies=$all_strategies\n> +\t\t;;\n> \t-*)\tusage ;;\n> \t*)\tbreak ;;\n> \tesac\n> @@ -444,7 +448,12 @@ done\n> # auto resolved the merge cleanly.\n> if test '' != \"$result_tree\"\n> then\n> - parents=$(git show-branch --independent \"$head\" \"$@\" | sed -e 's/^/-p /')\n> + if test $no_ff = 't'\nThis should be quoted, e.g.\n + if test \"$no_ff\" = 't'\n\nOtherwise I get an error like the following:\n\n xp:/tmp/va (a)$ git merge b\n Renamed msg.cc->common/msg.cc\n Auto-merged common/msg.cc\n Renamed msg.h->common/msg.h\n Auto-merged common/msg.h\n Renamed sampler/ConcurrentQueue.h->common/ConcurrentQueue.h\n Auto-merged common/ConcurrentQueue.h\n Renamed sampler/TimeoutSemaphore.h->common/TimeoutSemaphore.h\n Auto-merged common/TimeoutSemaphore.h\n /home/peter/usr/bin/git-merge: line 451: test: =: unary operator expected\n Merge made by recursive.\n\n\n> + then\n> + parents=$(git rev-parse \"$head\" \"$@\" | sed -e 's/^/-p /')\n> + else\n> + parents=$(git show-branch --independent \"$head\" \"$@\" | sed -e 's/^/-p /')\n> + fi\n> result_commit=$(printf '%s\\n' \"$merge_msg\" | git commit-tree $result_tree $parents) || exit\n> finish \"$result_commit\" \"Merge made by $wt_strategy.\"\n> dropsave\n\n-Peter\n"},{"id":"53553","messageId":"8c5c35580709190009u48e52acbq3c4113114de8cf1@mail.gmail.com","threadId":"9893","inReplyTo":"20070918225134.GA5906@xp.machine.xx","subject":"Re: [PATCH] git-merge: add option --no-ff","fromName":"Lars Hjemli","fromEmail":"hjemli@gmail.com","sentAt":"2007-09-19T07:09:46Z","receivedAt":"2007-09-19T07:09:46Z","isPatch":true,"sender":{"key":"hjemli@gmail.com","avatar":null},"body":"On 9/19/07, Peter Baumann wrote:\n> This should be quoted, e.g.\n> + if test \"$no_ff\" = 't'\n>\n\nOuch, sorry about that. I can send an updated patch late tonight (it's\nnow early morning here), but I'm not sure Junio wants/needs it. Junio?\n\n--\nlarsh\n"}]}