{"thread":{"id":"21454","subject":"git pull --rebase and losing commits","startedAt":"2009-11-02T12:26:37Z","lastAt":"2009-11-16T23:04:05Z","messageCount":38,"participants":["Peter Krefting","Thomas Rast","Björn Steinbrink","Nanako Shiraishi","Randal L. Schwartz","Johannes Schindelin","Baz","Junio C Hamano","Nicolas Sebrecht","Sverre Rabbelier","A Large Angry SCM"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"126581","messageId":"alpine.DEB.2.00.0911021318400.3919@ds9.cixit.se","threadId":"21454","inReplyTo":null,"subject":"git pull --rebase and losing commits","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-11-02T12:26:37Z","receivedAt":"2009-11-02T12:26:37Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Hi!\n\nI have put my web site under Git control, and am running into some problems.\n\nWhenever I push changes, I go via a bare repository, which then is pulled \ninto a checked out tree in my \"public_html\" directory. However, some scripts \nI have does create files directly under the \"public_html\", and some of them \nI want to push into the Git history.\n\nI am trying to use --rebase everywhere to get a linear history in the cases \nwhere I have pushed changes to the bare repository while there were \nuncommited changes to the public_html directory.\n\nI have come up with a script that does this (I have removed the \nuninteresting non-git commands):\n\n # Commit local changes\n git add path/to/script/output/*\n for file in $(git diff-index --cached --name-only HEAD); do\n havenew=1\n done\n if [ $havenew = 1 ]; then\n git commit --quiet -m 'Automatic' path/to/script/output/*\n fi\n\n # Update tree (--strategy=ours avoids merge conflicts)\n git pull --rebase --strategy=ours origin master\n\n # Push rebased local changes\n git push origin master\n\n # Update all references\n git fetch origin master:remotes/origin/master\n\nHowever, this seems to lose commits. When I ran it today, it commited an \nautomatic change, and then pulled a tree that did not contain that change, \nmaking the changed file just disappear. I had to dig through the reflog to \nfind it:\n\n- This is the auto-commit:\n 608b7eda553552841f4a16167c680fc74ed3c55a \n509926edd306bb2f09f563a7cfda800a4f0fdaed Peter Krefting \n 1257162580 +0100 commit: Automatisk \nbloggkommentarsuppdatering\n\n- This is the \"git pull\":\n 509926edd306bb2f09f563a7cfda800a4f0fdaed \n9088bd4801a9008fe3fca0d351f97544cee014f1 Peter Krefting \n 1257162583 +0100 rebase finished: \nrefs/heads/master onto 9088bd4801a9008fe3fca0d351f97544cee014f1\n\nThe history of 9088bd... does not contain the rebased version of 509926..., \nit just went missing.\n\nI guess I am missing something vital here.\n\n $ git --version\n git version 1.5.6.5\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"126589","messageId":"200911021604.24066.trast@student.ethz.ch","threadId":"21454","inReplyTo":"alpine.DEB.2.00.0911021318400.3919@ds9.cixit.se","subject":"Re: git pull --rebase and losing commits","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-02T15:04:22Z","receivedAt":"2009-11-02T15:04:22Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Peter Krefting wrote:\n> # Update tree (--strategy=ours avoids merge conflicts)\n> git pull --rebase --strategy=ours origin master\n[...]\n> However, this seems to lose commits. When I ran it today, it commited an \n> automatic change, and then pulled a tree that did not contain that change, \n> making the changed file just disappear.\n\nNot very surprising if you use the 'ours' strategy, which doesn't\nmerge at all but instead takes the 'ours' side (IIRC that's the\nupstream for a rebase, but I always have these mixed up). It is *not*\nthe often requested (but ill-defined and hence never implemented)\n\"resolve all conflict hunks in favour of ours\" strategy.\n\nSo what happens is that git-rebase rebuilds some commit C from your\nside on some base B from the remote, but the 'ours' strategy turns the\n*tree* for C' into that of B. Then git-rebase sees that the trees\nhaven't changed, and concludes that C has already been applied and\ndrops it.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"126590","messageId":"20091102151022.GA3995@atjola.homenet","threadId":"21454","inReplyTo":"alpine.DEB.2.00.0911021318400.3919@ds9.cixit.se","subject":"Re: git pull --rebase and losing commits","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-11-02T15:10:22Z","receivedAt":"2009-11-02T15:10:22Z","isPatch":false,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.11.02 13:26:37 +0100, Peter Krefting wrote:\n> # Update tree (--strategy=ours avoids merge conflicts)\n> git pull --rebase --strategy=ours origin master\n\nThe \"ours\" strategy doesn't just avoid merge conflicts, it avoids making\nany changes at all. The ours strategy means \"just keep our state, just\npretend that we've merged\". And rebase will see that there were no\nchanges and conclude:\n\nAlready applied: 0001 test commit\n\nAnd thus it will drop the commit.\n\nBjörn\n"},{"id":"126614","messageId":"20091103063448.6117@nanako3.lavabit.com","threadId":"21454","inReplyTo":"200911021604.24066.trast@student.ethz.ch","subject":"Re: git pull --rebase and losing commits","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-11-02T21:34:48Z","receivedAt":"2009-11-02T21:34:48Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Thomas Rast \n\n> It is *not*\n> the often requested (but ill-defined and hence never implemented)\n> \"resolve all conflict hunks in favour of ours\" strategy.\n\nThis was implemented and posted here quite some time ago.\n\n http://thread.gmane.org/gmane.comp.version-control.git/85163/focus=85602\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"126622","messageId":"86my3444i2.fsf@blue.stonehenge.com","threadId":"21454","inReplyTo":"alpine.DEB.2.00.0911021318400.3919@ds9.cixit.se","subject":"Re: git pull --rebase and losing commits","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2009-11-03T04:27:33Z","receivedAt":"2009-11-03T04:27:33Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Peter\" == Peter Krefting writes:\n\nPeter> git pull --rebase --strategy=ours origin master\n\n\"No good can come of this.\"\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion\n"},{"id":"126624","messageId":"alpine.DEB.2.00.0911030757400.15633@ds9.cixit.se","threadId":"21454","inReplyTo":"20091102151022.GA3995@atjola.homenet","subject":"Re: git pull --rebase and losing commits","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-11-03T07:01:38Z","receivedAt":"2009-11-03T07:01:38Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Thomas Rast:\n\n> Not very surprising if you use the 'ours' strategy, which doesn't merge at \n> all but instead takes the 'ours' side (IIRC that's the upstream for a \n> rebase, but I always have these mixed up).\n\nSounds like it should be called \"theirs\", then. Or the documentation should \nbe clarify.\n\n> So what happens is that git-rebase rebuilds some commit C from your side \n> on some base B from the remote, but the 'ours' strategy turns the *tree* \n> for C' into that of B.\n\nRight. I thought it was working on the individual blobs (I want it to \nautomatically resolve conflicts by applying the version that is in the \nrepository I am running the rebase from, no matter what).\n\n\nBjörn Steinbrink:\n\n> The \"ours\" strategy doesn't just avoid merge conflicts, it avoids making\n> any changes at all. The ours strategy means \"just keep our state, just\n> pretend that we've merged\". And rebase will see that there were no\n> changes and conclude:\n>\n> Already applied: 0001 test commit\n>\n> And thus it will drop the commit.\n\nI've seen that message show up in my logs a couple of times. I'd better drop \nthe --strategy=ours, then. :-/\n\n\nNow to figure out if it is possible to get a setup like this working at all. \nMaybe dropping rebase in favour of regular merge may help a bit, but I still \nwant it to auto-resolve any conflicts for me.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"126637","messageId":"alpine.DEB.1.00.0911031047510.4985@pacific.mpi-cbg.de","threadId":"21454","inReplyTo":"alpine.DEB.2.00.0911030757400.15633@ds9.cixit.se","subject":"Re: git pull --rebase and losing commits","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-03T09:52:51Z","receivedAt":"2009-11-03T09:52:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 3 Nov 2009, Peter Krefting wrote:\n\n> Thomas Rast:\n> \n> > Not very surprising if you use the 'ours' strategy, which doesn't merge at\n> > all but instead takes the 'ours' side (IIRC that's the upstream for a\n> > rebase, but I always have these mixed up).\n> \n> Sounds like it should be called \"theirs\", then.\n\nWhy should it be called \"theirs\" when it takes \"ours\"?\n\nNote: the thing I think Thomas wanted to clarify is that this strategy \ndoes not _resolve conflicts_ to \"our\" version, but it just outright \nignores \"theirs\". IOW, after a merge with the \"ours\" strategy, \n\"HEAD^{tree}\" and \"HEAD^^{tree}\" will point to _exactly the same object_.\n\nIf you want to use any merge strategy, you must understand what it does \nfirst. There is no way around that. No change in UI, or in the core code \nof Git, can relieve you of this obligation.\n\nCiao,\nDscho\n"},{"id":"126639","messageId":"alpine.DEB.2.00.0911031103450.19057@ds9.cixit.se","threadId":"21454","inReplyTo":"alpine.DEB.1.00.0911031047510.4985@pacific.mpi-cbg.de","subject":"Re: git pull --rebase and losing commits","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-11-03T10:12:13Z","receivedAt":"2009-11-03T10:12:13Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Johannes Schindelin:\n\n>> Sounds like it should be called \"theirs\", then.\n> Why should it be called \"theirs\" when it takes \"ours\"?\n\nBecause it took \"their\" (= upstream) tree, not \"our\" (= local branch) tree.\n\nSeems to me the name is a bit confusing in the case of a rebase, as I am \n\"merging\" my changes *onto* the upstream, not the other way round as would \nbe the case with a regular merge.\n\n> Note: the thing I think Thomas wanted to clarify is that this strategy \n> does not _resolve conflicts_ to \"our\" version, but it just outright \n> ignores \"theirs\". IOW, after a merge with the \"ours\" strategy, \n> \"HEAD^{tree}\" and \"HEAD^^{tree}\" will point to _exactly the same object_.\n\nAnd in the case of a rebase, the other way around: With --rebase \n--strategy=ours, I am basically asking to throw all my local commits away?\n\n> If you want to use any merge strategy, you must understand what it does \n> first. There is no way around that. No change in UI, or in the core code \n> of Git, can relieve you of this obligation.\n\nNo, that is why I recommended that what needed clarification was the \ndocumentation. I read the documentation of \"ours\":\n\n \"This resolves any number of heads, but the result of the merge is\n always the current branch head. It is meant to be used to\n supersede old development history of side branches.\"\n\nand thought that it meant that it\n\na) could resolve a merge conflict, no matter the number of branches involved \n(\"resolves any number of heads\").\nb) would replace any merge conflict with the contents in the current \nrepository's branch (\"result of the merge is always the current branch head\").\n\nApparently, the \"used to supersede old development history\" means that it \nactually throws the entire contents of one of the branches out, which is not \nwhat I wanted. I didn't understand that from the documentation, however.\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"126640","messageId":"200911031112.25064.trast@student.ethz.ch","threadId":"21454","inReplyTo":"alpine.DEB.2.00.0911030757400.15633@ds9.cixit.se","subject":"Re: git pull --rebase and losing commits","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-03T10:12:22Z","receivedAt":"2009-11-03T10:12:22Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Peter Krefting wrote:\n> Thomas Rast:\n> \n> > Not very surprising if you use the 'ours' strategy, which doesn't merge at \n> > all but instead takes the 'ours' side (IIRC that's the upstream for a \n> > rebase, but I always have these mixed up).\n> \n> Sounds like it should be called \"theirs\", then. Or the documentation should \n> be clarify.\n\nThe problem isn't that ours and theirs are swapped, it's that in a\nrebase, the 'ours' side is the upstream and 'theirs' is the commit you\nare currently rebasing. This makes sort of sense, because you are\nrebuilding your commit on top of the upstream (or actually, the so-far\nrebuilt commits, starting with the upstream), so the merge happens\n\"on\" the upstream.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"127335","messageId":"200911111411.nABEBfox031023@ds9.cixit.se","threadId":"21454","inReplyTo":"alpine.DEB.1.00.0911031047510.4985@pacific.mpi-cbg.de","subject":"[PATCH] Clarify documentation on the \"ours\" merge strategy.","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-11-11T14:03:32Z","receivedAt":"2009-11-11T14:03:32Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Make it clear that the merge strategy will discard all changes made to\nthe branch being merged, and not just avoid creating merge conflicts.\n---\n Documentation/merge-strategies.txt | 3 ++-\n 1 files changed, 2 insertions(+), 1 deletions(-)\n\n> If you want to use any merge strategy, you must understand what it does\n> first.\n\nIndeed. Perhaps this clarification will help the next poor soul that tries\ndoing what I tried?\n\ndiff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt\nindex 4365b7e..a340dc9 100644\n--- a/Documentation/merge-strategies.txt\n+++ b/Documentation/merge-strategies.txt\n@@ -30,7 +30,8 @@ octopus::\n \n ours::\n \tThis resolves any number of heads, but the result of the\n-\tmerge is always the current branch head. It is meant to\n+\tmerge is always the current branch head, discarding any\n+\tchanges on the merged branch. It is meant to\n \tbe used to supersede old development history of side\n \tbranches.\n \n-- \n1.6.4\n"},{"id":"127338","messageId":"2faad3050911110713y4e33c7d2h21ad42efe4fd70b3@mail.gmail.com","threadId":"21454","inReplyTo":"200911111411.nABEBfox031023@ds9.cixit.se","subject":"Re: [PATCH] Clarify documentation on the \"ours\" merge strategy.","fromName":"Baz","fromEmail":"brian.ewins@gmail.com","sentAt":"2009-11-11T15:13:52Z","receivedAt":"2009-11-11T15:13:52Z","isPatch":true,"sender":{"key":"brian.ewins@gmail.com","avatar":"https://gravatar.com/avatar/9ac03d89105e50a7151e695a1b4b1228151064ec3ac380a73b74ab397796baf7?d=mp&s=160"},"body":"2009/11/11 Peter Krefting :\n> Make it clear that the merge strategy will discard all changes made to\n> the branch being merged, and not just avoid creating merge conflicts.\n> ---\n>  Documentation/merge-strategies.txt |    3 ++-\n>  1 files changed, 2 insertions(+), 1 deletions(-)\n>\n>> If you want to use any merge strategy, you must understand what it does\n>> first.\n>\n> Indeed. Perhaps this clarification will help the next poor soul that tries\n> doing what I tried?\n>\n> diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt\n> index 4365b7e..a340dc9 100644\n> --- a/Documentation/merge-strategies.txt\n> +++ b/Documentation/merge-strategies.txt\n> @@ -30,7 +30,8 @@ octopus::\n>\n>  ours::\n>        This resolves any number of heads, but the result of the\n> -       merge is always the current branch head.  It is meant to\n> +       merge is always the current branch head, discarding any\n> +       changes on the merged branch.  It is meant to\n\nI think part of the problem is that it is unclear what the \"current\nbranch head\" means when used in a rebase, and hence when this text is\nincluded in the help for git-rebase and git-pull. This flipped\nbehaviour is surprising given the natural meaning of 'ours', or\n'current branch', particularly for git pull:\n\ngit pull -s ours - discards changes in remote branch, keeps changes\nin current branch\ngit pull --rebase -s ours - discards changes in current branch, keeps\nchanges in remote branch\n\nPerhaps something more in the way of an explicit warning?\n\nours::\n This resolves any number of heads, but the result of the\n merge is always the current branch head, discarding any\n changes on the merged branch. It is meant to\n be used to supersede old development history of side\n branches. Note that when rebasing, the branch you are\n rebasing onto is the \"current branch head\", and using this\n strategy will lose all of your changes - unlikely to be what\n you wanted to do.\n\n-Baz\n\n>        be used to supersede old development history of side\n>        branches.\n>\n> --\n> 1.6.4\n>\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>\n"},{"id":"127373","messageId":"200911112135.25839.trast@student.ethz.ch","threadId":"21454","inReplyTo":"2faad3050911110713y4e33c7d2h21ad42efe4fd70b3@mail.gmail.com","subject":"Re: [PATCH] Clarify documentation on the \"ours\" merge strategy.","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-11T20:35:24Z","receivedAt":"2009-11-11T20:35:24Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Baz wrote:\n> 2009/11/11 Peter Krefting :\n> > ours::\n> > This resolves any number of heads, but the result of the\n> > - merge is always the current branch head. It is meant to\n> > + merge is always the current branch head, discarding any\n> > + changes on the merged branch. It is meant to\n> \n> I think part of the problem is that it is unclear what the \"current\n> branch head\" means when used in a rebase, and hence when this text is\n> included in the help for git-rebase and git-pull.\n[...]\n> Perhaps something more in the way of an explicit warning?\n> \n> ours::\n> This resolves any number of heads, but the result of the\n> merge is always the current branch head, discarding any\n> changes on the merged branch. It is meant to\n> be used to supersede old development history of side\n> branches. Note that when rebasing, the branch you are\n> rebasing onto is the \"current branch head\", and using this\n> strategy will lose all of your changes - unlikely to be what\n> you wanted to do.\n\nI'd much rather see this explained in the description of the rebase\n-m/-s options since it (the swap) applies to all uses of 'git rebase\n-m'. Perhaps with an extra (but short) note in the \"ours\"\ndescription, like so:\n\ndiff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt\nindex 33e0ef1..181947c 100644\n--- i/Documentation/git-rebase.txt\n+++ w/Documentation/git-rebase.txt\n@@ -228,6 +228,10 @@ OPTIONS\n \tUse merging strategies to rebase. When the recursive (default) merge\n \tstrategy is used, this allows rebase to be aware of renames on the\n \tupstream side.\n++\n+Note that in a rebase merge (hence merge conflict), the sides are\n+swapped: \"theirs\" is the to-be-applied patch, and \"ours\" is the so-far\n+rebased series, starting with .\n \n -s ::\n --strategy=::\ndiff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt\nindex 4365b7e..0cae1be 100644\n--- i/Documentation/merge-strategies.txt\n+++ w/Documentation/merge-strategies.txt\n@@ -33,6 +33,9 @@ ours::\n \tmerge is always the current branch head. It is meant to\n \tbe used to supersede old development history of side\n \tbranches.\n++\n+Because the sides in a rebase are swapped, using this strategy with\n+git-rebase is never a good idea.\n \n subtree::\n \tThis is a modified recursive strategy. When merging trees A and\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"127375","messageId":"2faad3050911111254h426e24ccg93d2824f9e971521@mail.gmail.com","threadId":"21454","inReplyTo":"200911112135.25839.trast@student.ethz.ch","subject":"Re: [PATCH] Clarify documentation on the \"ours\" merge strategy.","fromName":"Baz","fromEmail":"brian.ewins@gmail.com","sentAt":"2009-11-11T20:54:54Z","receivedAt":"2009-11-11T20:54:54Z","isPatch":true,"sender":{"key":"brian.ewins@gmail.com","avatar":"https://gravatar.com/avatar/9ac03d89105e50a7151e695a1b4b1228151064ec3ac380a73b74ab397796baf7?d=mp&s=160"},"body":"2009/11/11 Thomas Rast :\n> Baz wrote:\n>> 2009/11/11 Peter Krefting :\n>> >  ours::\n>> >        This resolves any number of heads, but the result of the\n>> > -       merge is always the current branch head.  It is meant to\n>> > +       merge is always the current branch head, discarding any\n>> > +       changes on the merged branch.  It is meant to\n>>\n>> I think part of the problem is that it is unclear what the \"current\n>> branch head\" means when used in a rebase, and hence when this text is\n>> included in the help for git-rebase and git-pull.\n> [...]\n>> Perhaps something more in the way of an explicit warning?\n>>\n>> ours::\n>>          This resolves any number of heads, but the result of the\n>>          merge is always the current branch head, discarding any\n>>          changes on the merged branch.  It is meant to\n>>          be used to supersede old development history of side\n>>          branches. Note that when rebasing, the branch you are\n>>          rebasing onto is the \"current branch head\", and using this\n>>          strategy will lose all of your changes - unlikely to be what\n>>          you wanted to do.\n>\n> I'd much rather see this explained in the description of the rebase\n> -m/-s options since it (the swap) applies to all uses of 'git rebase\n> -m'.  Perhaps with an extra (but short) note in the \"ours\"\n> description, like so:\n>\n> diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt\n> index 33e0ef1..181947c 100644\n> --- i/Documentation/git-rebase.txt\n> +++ w/Documentation/git-rebase.txt\n> @@ -228,6 +228,10 @@ OPTIONS\n>        Use merging strategies to rebase.  When the recursive (default) merge\n>        strategy is used, this allows rebase to be aware of renames on the\n>        upstream side.\n> ++\n> +Note that in a rebase merge (hence merge conflict), the sides are\n> +swapped: \"theirs\" is the to-be-applied patch, and \"ours\" is the so-far\n> +rebased series, starting with .\n>\n>  -s ::\n>  --strategy=::\n> diff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt\n> index 4365b7e..0cae1be 100644\n> --- i/Documentation/merge-strategies.txt\n> +++ w/Documentation/merge-strategies.txt\n> @@ -33,6 +33,9 @@ ours::\n>        merge is always the current branch head.  It is meant to\n>        be used to supersede old development history of side\n>        branches.\n> ++\n> +Because the sides in a rebase are swapped, using this strategy with\n> +git-rebase is never a good idea.\n\nYes, this (with Peter's patch) makes the danger nice & clear.\n\nThanks!\n\n-Baz\n\n>\n>  subtree::\n>        This is a modified recursive strategy. When merging trees A and\n>\n> --\n> Thomas Rast\n> trast@{inf,student}.ethz.ch\n>\n"},{"id":"127376","messageId":"7vskckn5b4.fsf@alter.siamese.dyndns.org","threadId":"21454","inReplyTo":"200911112135.25839.trast@student.ethz.ch","subject":"Re: [PATCH] Clarify documentation on the \"ours\" merge strategy.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-11T21:02:23Z","receivedAt":"2009-11-11T21:02:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> I'd much rather see this explained in the description of the rebase\n> -m/-s options since it (the swap) applies to all uses of 'git rebase\n> -m'. Perhaps with an extra (but short) note in the \"ours\"\n> description, like so:\n>\n> diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt\n> index 33e0ef1..181947c 100644\n> --- i/Documentation/git-rebase.txt\n> +++ w/Documentation/git-rebase.txt\n> @@ -228,6 +228,10 @@ OPTIONS\n> \tUse merging strategies to rebase. When the recursive (default) merge\n> \tstrategy is used, this allows rebase to be aware of renames on the\n> \tupstream side.\n> ++\n> +Note that in a rebase merge (hence merge conflict), the sides are\n> +swapped: \"theirs\" is the to-be-applied patch, and \"ours\" is the so-far\n> +rebased series, starting with .\n> \n> -s ::\n> --strategy=::\n> diff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt\n> index 4365b7e..0cae1be 100644\n> --- i/Documentation/merge-strategies.txt\n> +++ w/Documentation/merge-strategies.txt\n> @@ -33,6 +33,9 @@ ours::\n> \tmerge is always the current branch head. It is meant to\n> \tbe used to supersede old development history of side\n> \tbranches.\n> ++\n> +Because the sides in a rebase are swapped, using this strategy with\n> +git-rebase is never a good idea.\n> \n> subtree::\n> \tThis is a modified recursive strategy. When merging trees A and\n\nLooking very good.\n"},{"id":"127381","messageId":"20091111213049.GJ27518@vidovic","threadId":"21454","inReplyTo":"7vskckn5b4.fsf@alter.siamese.dyndns.org","subject":"[PATCH] Re: Clarify documentation on the \"ours\" merge strategy.","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2009-11-11T21:30:49Z","receivedAt":"2009-11-11T21:30:49Z","isPatch":true,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 11/11/09, Junio C Hamano wrote:\n> Thomas Rast writes:\n> \n> > ++\n> > +Because the sides in a rebase are swapped, using this strategy with\n> > +git-rebase is never a good idea.\n> \n> Looking very good.\n\nIf this strategy is _never_ a good idea in this case, I tend to think\nthat git should forbid this option, or at least, warn and refer to the\ndocumentation.\n\n-- \nNicolas Sebrecht\n"},{"id":"127395","messageId":"200911120037.11901.trast@student.ethz.ch","threadId":"21454","inReplyTo":"20091111213049.GJ27518@vidovic","subject":"Re: [PATCH] Re: Clarify documentation on the \"ours\" merge strategy.","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-11T23:37:10Z","receivedAt":"2009-11-11T23:37:10Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Nicolas Sebrecht wrote:\n> The 11/11/09, Junio C Hamano wrote:\n> > Thomas Rast writes:\n> > \n> > > ++\n> > > +Because the sides in a rebase are swapped, using this strategy with\n> > > +git-rebase is never a good idea.\n> > \n> > Looking very good.\n> \n> If this strategy is _never_ a good idea in this case, I tend to think\n> that git should forbid this option, or at least, warn and refer to the\n> documentation.\n\nThen again, I'm not sure if resolve vs. recursive makes a difference\nin a rebase. Octopus is weird for a two-head merge, I'm not sure why\nthe docs even talk about it. That would leave only subtree, which\nindeed has its uses. Should we add a note to that effect to\ngit-rebase.txt? Like, say,\n\ndiff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt\nindex 33e0ef1..6e54a57 100644\n--- i/Documentation/git-rebase.txt\n+++ w/Documentation/git-rebase.txt\n@@ -228,13 +228,19 @@ OPTIONS\n \tUse merging strategies to rebase. When the recursive (default) merge\n \tstrategy is used, this allows rebase to be aware of renames on the\n \tupstream side.\n++\n+Note that in a rebase merge (hence merge conflict), the sides are\n+swapped: \"theirs\" is the to-be-applied patch, and \"ours\" is the so-far\n+rebased series, starting with .\n \n -s ::\n --strategy=::\n \tUse the given merge strategy.\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). This implies --merge.\n+\tIf there is no `-s` option 'git-merge-recursive' is used\n+\tinstead. This implies --merge.\n++\n+Due to the peculiarities of 'git-rebase' (see \\--merge above) the only\n+built-in strategy that is actually useful is 'subtree'.\n \n -q::\n --quiet::\ndiff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt\nindex 4365b7e..c1c3add 100644\n--- i/Documentation/merge-strategies.txt\n+++ w/Documentation/merge-strategies.txt\n@@ -33,6 +33,9 @@ ours::\n \tmerge is always the current branch head. It is meant to\n \tbe used to supersede old development history of side\n \tbranches.\n++\n+Because the sides in a rebase are swapped, using this strategy with\n+'git-rebase' is never a good idea.\n \n subtree::\n \tThis is a modified recursive strategy. When merging trees A and\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"127416","messageId":"7vvdhggote.fsf@alter.siamese.dyndns.org","threadId":"21454","inReplyTo":"200911120037.11901.trast@student.ethz.ch","subject":"Re: [PATCH] Re: Clarify documentation on the \"ours\" merge strategy.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-12T07:55:09Z","receivedAt":"2009-11-12T07:55:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Then again, I'm not sure if resolve vs. recursive makes a difference\n> in a rebase. Octopus is weird for a two-head merge, I'm not sure why\n\n ...\n\n> +\tIf there is no `-s` option 'git-merge-recursive' is used\n> +\tinstead. This implies --merge.\n> ++\n> +Due to the peculiarities of 'git-rebase' (see \\--merge above) the only\n> +built-in strategy that is actually useful is 'subtree'.\n\n\"recursive is just a slower and sometimes buggier alternative to resolve\nbut can handle renames\" may mean \"people do not have much reason to choose\nresolve over recursive\". But that is quite different from \"resolve is not\nuseful here _due to_ the peculiarities of rebase\". Wouldn't anybody who\nthinks \"resolve vs. recursive would not make a difference in a rebase\"\nalso think \"resolve vs. recursive would not make a difference anywhere\"?\n\n58634db (rebase: Allow merge strategies to be used when rebasing,\n2006-06-21) added \"-m\" and \"-s\" to rebase to solve the problem of rebasing\nagainst an upstream that has moved files. What the commit actually did\nwas to use recursive (by default) while giving longer rope to the users by\nchoosing other strategies with \"-s\", without making any judgement as to\nwhy other strategies may possibly be useful.\n\nPerhaps there is some different issue at the root of this one. Why would\nanybody be tempted to say \"-s ours\" while running a rebase? What did the\nuser want to see it do (instead of being a no-op because \"ours\" by\ndefinition ignores the tree the change is replayed from)?\n\nIt is easy to dismiss it as a user misconception and it also is tempting\nto think that it would be helped with updated description of \"ours\" to\ndispel that misconception, but there may be some user wish that is totally\ndifferent from \"ours merge\" strategy but still can be validly labelled\nusing a word \"ours\" by somebody who does not know the way the word \"ours\"\nis used in the git land, and satisfying that unknown user wish might be\nthe real solution to this issue.\n"},{"id":"127430","messageId":"alpine.DEB.2.00.0911121034580.8825@ds9.cixit.se","threadId":"21454","inReplyTo":"7vvdhggote.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Re: Clarify documentation on the \"ours\" merge strategy.","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-11-12T09:41:38Z","receivedAt":"2009-11-12T09:41:38Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Junio C Hamano:\n\n> Perhaps there is some different issue at the root of this one. Why would \n> anybody be tempted to say \"-s ours\" while running a rebase? What did the \n> user want to see it do (instead of being a no-op because \"ours\" by \n> definition ignores the tree the change is replayed from)?\n\nThe reason why I wanted it in my initial example was due to me misreading \nthe documentation of \"ours\".\n\nMy scenario is like this:\n\nI have my web site under Git control (used to be CVS). Some parts of the web \nsite is updated in-place (blog comments being saved as HTML directly in the \nweb tree), whereas all other edits are done in clones of the repsository. \nThese changes are then added and committed to the checked out web tree and \npushed to the central repo.\n\nIn some cases, I wish to edit the comments in one of my clones (to remove \nspam not stopped by my spam filters, for instance), but editing these risks \ncreating a conflict if there has been other changes in the mean time.\n\nThe web tree checkout script uses rebase to avoid introducing merge commits \nevery time the blog comment is updated, as it in 99 % of cases is unrelated \nto any other changes found in the central repo.\n\nIn the few cases where the blog comment update from the web tree conflicts \nwith a change in the central repo, I want the \"git pull --rebase\" call to \noverwrite any changes in the central repo with my changes in the web tree \n(meaning that I would later have to manually re-delete the spam comments, \nbut I can live with that).\n\n> It is easy to dismiss it as a user misconception and it also is tempting \n> to think that it would be helped with updated description of \"ours\" to \n> dispel that misconception, but there may be some user wish that is totally \n> different from \"ours merge\" strategy but still can be validly labelled \n> using a word \"ours\" by somebody who does not know the way the word \"ours\" \n> is used in the git land, and satisfying that unknown user wish might be \n> the real solution to this issue.\n\nYes, I am apparently looking for something that is not available in the Git \ncodebase yet. :-)\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"127431","messageId":"20091112095521.GA3666@atjola.homenet","threadId":"21454","inReplyTo":"7vvdhggote.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Re: Clarify documentation on the \"ours\" merge strategy.","fromName":"Björn Steinbrink","fromEmail":"b.steinbrink@gmx.de","sentAt":"2009-11-12T09:55:21Z","receivedAt":"2009-11-12T09:55:21Z","isPatch":true,"sender":{"key":"b.steinbrink@gmx.de","avatar":"https://avatars.githubusercontent.com/u/230962?v=4"},"body":"On 2009.11.11 23:55:09 -0800, Junio C Hamano wrote:\n> 58634db (rebase: Allow merge strategies to be used when rebasing,\n> 2006-06-21) added \"-m\" and \"-s\" to rebase to solve the problem of rebasing\n> against an upstream that has moved files. What the commit actually did\n> was to use recursive (by default) while giving longer rope to the users by\n> choosing other strategies with \"-s\", without making any judgement as to\n> why other strategies may possibly be useful.\n\nAt least the original reason for 58634db became (partially?) moot half a\nyear later, thanks to 579c9bb19 \"Use merge-recursive in git-am -3\".\nRebase already falls back to recursive merging in am, so using rebase -m\nwith the recursive strategy just stops it from trying the fast path,\nright?\n\nThat should probably be reflected in the man page, but honestly I have\nno idea what to write there now. The note about recursive should go, but\nkeeping only \"Use merging strategies to rebase\" doesn't actually look\nlike it's going to be helpful in any way.\n\n> Perhaps there is some different issue at the root of this one. Why would\n> anybody be tempted to say \"-s ours\" while running a rebase? What did the\n> user want to see it do (instead of being a no-op because \"ours\" by\n> definition ignores the tree the change is replayed from)?\n\nGiven the few requests I've seen of it (here + #git), I'd guess that\nthe user wants \"git rebase -s ours $up\" to do either:\n\nMB=$(git merge-base $up HEAD)\ngit filter-branch --parent-filter \"sed -e s/$MB/$up/\" -- HEAD --not $up\n\ni.e. just re-attach things to upstream, ignoring whatever upstream did\n(git-svn users seem to want something like that sometimes to be able to\ndcommit. Dunno if they have some hatred against the other users of their\nsvn repo ;-))\n\nOr the user wants the infamous \"resolve conflicts to want I did\", often\nenough without thinking about what that actually means and how it can\neasily lead to total crap. (Yes, I'm biased...)\n\nBjörn\n"},{"id":"127530","messageId":"20091114111259.6117@nanako3.lavabit.com","threadId":"21454","inReplyTo":"alpine.DEB.2.00.0911121034580.8825@ds9.cixit.se","subject":"Re: [PATCH] Re: Clarify documentation on the \"ours\" merge strategy.","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-11-14T02:12:59Z","receivedAt":"2009-11-14T02:12:59Z","isPatch":true,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Peter Krefting \n\n> The web tree checkout script uses rebase to avoid introducing merge\n> commits every time the blog comment is updated, as it in 99 % of cases\n> is unrelated to any other changes found in the central repo.\n>\n> In the few cases where the blog comment update from the web tree\n> conflicts with a change in the central repo, I want the \"git pull\n> --rebase\" call to overwrite any changes in the central repo with my\n> changes in the web tree (meaning that I would later have to manually\n> re-delete the spam comments, but I can live with that).\n\nThat sounds like \"-Xours\" merge option that was discussed some time \nago. See\n\n http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021\n\nI remember that Junio and Petr were against it because it would \nencourage a bad workflow. Dscho was against the syntax used to \npass the options also.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"127593","messageId":"7vk4xsqhkv.fsf@alter.siamese.dyndns.org","threadId":"21454","inReplyTo":"20091114111259.6117@nanako3.lavabit.com","subject":"Re: [PATCH] Re: Clarify documentation on the \"ours\" merge strategy.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-15T09:10:24Z","receivedAt":"2009-11-15T09:10:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi writes:\n\n> Quoting Peter Krefting \n>\n>> The web tree checkout script uses rebase to avoid introducing merge\n>> commits every time the blog comment is updated, as it in 99 % of cases\n>> is unrelated to any other changes found in the central repo.\n>>\n>> In the few cases where the blog comment update from the web tree\n>> conflicts with a change in the central repo, I want the \"git pull\n>> --rebase\" call to overwrite any changes in the central repo with my\n>> changes in the web tree (meaning that I would later have to manually\n>> re-delete the spam comments, but I can live with that).\n>\n> That sounds like \"-Xours\" merge option that was discussed some time \n> ago. See\n>\n> http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=89021\n>\n> I remember that Junio and Petr were against it because it would \n> encourage a bad workflow. Dscho was against the syntax used to \n> pass the options also.\n\nYeah, Björn seems to speculate the same.\n\nEven though I still think -Xours/-Xtheirs are nonsense options in the\ncontext of source code management, I suspect that they might be exactly\nwhat Peter needs in this situation.\n\nAs long as the changes made on the \"web tree\" side only consist of\nuser-generated blog contents and never touch framework code that is\ncontrolled by his \"central repo\" side (and that condition should\nhold true; otherwise Peter's web site is seriously broken from the\nsecurity point of view and no SCM can fix that), running a merge with\nthe fabled -Xours option in the \"web tree\" to slurp in the changes made on\nthe \"central repo\" side does not sound like an unreasonable thing to do.\n"},{"id":"127619","messageId":"cover.1258309432.git.trast@student.ethz.ch","threadId":"21454","inReplyTo":"7vvdhggote.fsf@alter.siamese.dyndns.org","subject":"[PATCH 0/3] Document and refuse rebase -s ours","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-15T18:25:29Z","receivedAt":"2009-11-15T18:25:29Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio convinced me that it is not possible to limit the choice to only\n'subtree', so here's a short series that implements the other changes\nI had already posted in diff form.\n\nI also implemented Nicolas's suggestion to reject -s ours outright;\nI'm not really happy with starting a blacklist there, but maybe it\nhelps the next unwary user. I split it because even if you reject\n3/3, I think the first two should go in as extra documentation.\n\nThomas Rast (3):\n Documentation: clarify 'ours' merge strategy\n rebase docs: clarify --merge and --strategy\n rebase: refuse to rebase with -s ours\n\n Documentation/git-rebase.txt | 14 +++++++++++---\n Documentation/merge-strategies.txt | 5 +++--\n git-rebase--interactive.sh | 4 ++++\n git-rebase.sh | 4 ++++\n 4 files changed, 22 insertions(+), 5 deletions(-)\n"},{"id":"127621","messageId":"234d8bfd14ef0a90d4df16e00864058ff8ac8d38.1258309432.git.trast@student.ethz.ch","threadId":"21454","inReplyTo":"cover.1258309432.git.trast@student.ethz.ch","subject":"[PATCH 1/3] Documentation: clarify 'ours' merge strategy","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-15T18:25:30Z","receivedAt":"2009-11-15T18:25:30Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Make it clear in the docs that the merge takes the tree of HEAD and\nignores everything in the other branches. This should hopefully clear\nup confusion, usually caused by the user looking for a strategy that\nresolves all conflict hunks in favour of HEAD (which is completely\ndifferent and currently not supported).\n\nSigned-off-by: Thomas Rast \n---\n Documentation/merge-strategies.txt | 5 +++--\n 1 files changed, 3 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt\nindex 4365b7e..42910a3 100644\n--- a/Documentation/merge-strategies.txt\n+++ b/Documentation/merge-strategies.txt\n@@ -29,8 +29,9 @@ octopus::\n \tpulling or merging more than one branch.\n \n ours::\n-\tThis resolves any number of heads, but the result of the\n-\tmerge is always the current branch head. It is meant to\n+\tThis resolves any number of heads, but the resulting tree of the\n+\tmerge is always that of the current branch head, effectively\n+\tignoring all changes from all other branches. It is meant to\n \tbe used to supersede old development history of side\n \tbranches.\n \n-- \n1.6.5.2.420.gf6c057.dirty\n"},{"id":"127620","messageId":"b7f805f2497d748b685544b64cd91a36c3bdf5d6.1258309432.git.trast@student.ethz.ch","threadId":"21454","inReplyTo":"cover.1258309432.git.trast@student.ethz.ch","subject":"[PATCH 2/3] rebase docs: clarify --merge and --strategy","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-15T18:25:31Z","receivedAt":"2009-11-15T18:25:31Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Add a paragraph about the swapped sides in a --merge rebase, which was\notherwise only documented in the sources.\n\nAdd a paragraph about the effects of the 'ours' strategy to the -s\ndescription. Also remove the mention of the 'octopus' strategy, which\nwas copied from the git-merge description but is pointless in a\nrebase.\n\nSigned-off-by: Thomas Rast \n---\n Documentation/git-rebase.txt | 13 ++++++++++---\n 1 files changed, 10 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 33e0ef1..5fa9100 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -228,13 +228,20 @@ OPTIONS\n \tUse merging strategies to rebase. When the recursive (default) merge\n \tstrategy is used, this allows rebase to be aware of renames on the\n \tupstream side.\n++\n+Note that in a rebase merge (hence merge conflict), the sides are\n+swapped: \"theirs\" is the to-be-applied patch, and \"ours\" is the so-far\n+rebased series, starting with .\n \n -s ::\n --strategy=::\n \tUse the given merge strategy.\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). This implies --merge.\n+\tIf there is no `-s` option 'git-merge-recursive' is used\n+\tinstead. This implies --merge.\n++\n+Due to the peculiarities of 'git-rebase' (see \\--merge above), using\n+the 'ours' strategy simply discards all patches from the ,\n+which makes little sense.\n \n -q::\n --quiet::\n-- \n1.6.5.2.420.gf6c057.dirty\n"},{"id":"127622","messageId":"efd7770d166a97481e8e31e407b9c2da02a341e5.1258309432.git.trast@student.ethz.ch","threadId":"21454","inReplyTo":"cover.1258309432.git.trast@student.ethz.ch","subject":"[PATCH 3/3] rebase: refuse to rebase with -s ours","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-15T18:25:32Z","receivedAt":"2009-11-15T18:25:32Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Using the \"ours\" strategy with rebase just discards all changes,\nturning into (or if given). This is\nunlikely to be what the user wants, so simply refuse to do it.\n\nAlso document what would happen near the -s option, and point the user\nat it with the error message.\n\nSigned-off-by: Thomas Rast \n---\n Documentation/git-rebase.txt | 3 ++-\n git-rebase--interactive.sh | 4 ++++\n git-rebase.sh | 4 ++++\n 3 files changed, 10 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 5fa9100..2203e63 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -241,7 +241,8 @@ rebased series, starting with .\n +\n Due to the peculiarities of 'git-rebase' (see \\--merge above), using\n the 'ours' strategy simply discards all patches from the ,\n-which makes little sense.\n+which makes little sense. Thus 'git-rebase' does not accept this\n+strategy.\n \n -q::\n --quiet::\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 53ad248..c6bc156 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -584,6 +584,10 @@ first and then run 'git rebase --continue' again.\"\n \t\t\tSTRATEGY=\"-s $2\"\n \t\t\tshift ;;\n \t\tesac\n+\t\tif test \"$STRATEGY\" = \"-s ours\"\n+\t\tthen\n+\t\t\tdie \"Refusing to rebase with 'ours' strategy; see git help rebase.\"\n+\t\tfi\n \t\t;;\n \t-m)\n \t\t# we use merge anyway\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 6ec155c..2d7d566 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -306,6 +306,10 @@ do\n \t\t\tstrategy=\"$2\"\n \t\t\tshift ;;\n \t\tesac\n+\t\tif test $strategy = ours\n+\t\tthen\n+\t\t\tdie \"Refusing to rebase with 'ours' strategy; see git help rebase.\"\n+\t\tfi\n \t\tdo_merge=t\n \t\t;;\n \t-n|--no-stat)\n-- \n1.6.5.2.420.gf6c057.dirty\n"},{"id":"127624","messageId":"fabb9a1e0911151039g7c7373b5o3c14a9056c419f6@mail.gmail.com","threadId":"21454","inReplyTo":"efd7770d166a97481e8e31e407b9c2da02a341e5.1258309432.git.trast@student.ethz.ch","subject":"Re: [PATCH 3/3] rebase: refuse to rebase with -s ours","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-15T18:39:33Z","receivedAt":"2009-11-15T18:39:33Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Sun, Nov 15, 2009 at 19:25, Thomas Rast wrote:\n> +               if test \"$STRATEGY\" = \"-s ours\"\n\nIs this solid? Would \"-s ours\" (two spaces) work?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"127625","messageId":"200911151944.10630.trast@student.ethz.ch","threadId":"21454","inReplyTo":"fabb9a1e0911151039g7c7373b5o3c14a9056c419f6@mail.gmail.com","subject":"Re: [PATCH 3/3] rebase: refuse to rebase with -s ours","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-15T18:44:08Z","receivedAt":"2009-11-15T18:44:08Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Sverre Rabbelier wrote:\n> Heya,\n> \n> On Sun, Nov 15, 2009 at 19:25, Thomas Rast wrote:\n> > + if test \"$STRATEGY\" = \"-s ours\"\n> \n> Is this solid? Would \"-s ours\" (two spaces) work?\n\nWell, the variable is set by the case immediately before the new test:\n\n\tcase \"$#,$1\" in\n\t*,*=*)\n\t\tSTRATEGY=\"-s \"$(expr \"z$1\" : 'z-[^=]*=\\(.*\\)') ;;\n\t1,*)\n\t\tusage ;;\n\t*)\n\t\tSTRATEGY=\"-s $2\"\n\t\tshift ;;\n\tesac\n\nI didn't want to split that for a direct comparison with the second\nhalf of the value, but unless I'm missing something, you'd have to say\n-s ' ours' to make the test fail.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"127637","messageId":"7veinzfqj9.fsf@alter.siamese.dyndns.org","threadId":"21454","inReplyTo":"cover.1258309432.git.trast@student.ethz.ch","subject":"Re: [PATCH 0/3] Document and refuse rebase -s ours","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-15T21:04:42Z","receivedAt":"2009-11-15T21:04:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> I also implemented Nicolas's suggestion to reject -s ours outright;\n> I'm not really happy with starting a blacklist there, but maybe it\n> helps the next unwary user.\n\nI am inclined to agree with you and Nicolas on this, but I'll let the list\ndecide if [3/3] is a good idea.\n\nI'd rewrite [3/3] in the following way to keep it easier to maintain the\nblacklist, like this.\n\n case \"$1\" in\n - ours)\n + ours | theirs | octopus | subtree)\n die \"Refusing to rebase with $1; see git help rebase.\"\n esac\n\nIt would also make it easier to turn this into a whitelist if we choose\nto,\n\n git-rebase--interactive.sh | 5 +----\n git-rebase.sh | 5 +----\n git-sh-setup.sh | 7 +++++++\n 3 files changed, 9 insertions(+), 8 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 53d35f3..de7448b 100755\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -571,10 +571,7 @@ first and then run 'git rebase --continue' again.\"\n \t\t\tSTRATEGY=\"-s $2\"\n \t\t\tshift ;;\n \t\tesac\n-\t\tif test \"$STRATEGY\" = \"-s ours\"\n-\t\tthen\n-\t\t\tdie \"Refusing to rebase with 'ours' strategy; see git help rebase.\"\n-\t\tfi\n+\t\tgit_check_merge_strategy_used_in_rebase \"${STRATEGY#-s }\"\n \t\t;;\n \t-m)\n \t\t# we use merge anyway\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 2d7d566..dd9ec63 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -306,10 +306,7 @@ do\n \t\t\tstrategy=\"$2\"\n \t\t\tshift ;;\n \t\tesac\n-\t\tif test $strategy = ours\n-\t\tthen\n-\t\t\tdie \"Refusing to rebase with 'ours' strategy; see git help rebase.\"\n-\t\tfi\n+\t\tgit_check_merge_strategy_used_in_rebase \"$strategy\"\n \t\tdo_merge=t\n \t\t;;\n \t-n|--no-stat)\ndiff --git a/git-sh-setup.sh b/git-sh-setup.sh\nindex c41c2f7..724955f 100755\n--- a/git-sh-setup.sh\n+++ b/git-sh-setup.sh\n@@ -199,3 +199,10 @@ case $(uname -s) in\n \t}\n \t;;\n esac\n+\n+git_check_merge_strategy_used_in_rebase () {\n+\tcase \"$1\" in\n+\tours)\n+\t\tdie \"Refusing to rebase with $1; see git help rebase.\"\n+\tesac\n+}\n"},{"id":"127638","messageId":"7v7htrfqi1.fsf@alter.siamese.dyndns.org","threadId":"21454","inReplyTo":"b7f805f2497d748b685544b64cd91a36c3bdf5d6.1258309432.git.trast@student.ethz.ch","subject":"Re: [PATCH 2/3] rebase docs: clarify --merge and --strategy","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-15T21:05:26Z","receivedAt":"2009-11-15T21:05:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Thomas Rast writes:\n\n> Add a paragraph about the swapped sides in a --merge rebase, which was\n> otherwise only documented in the sources.\n>\n> Add a paragraph about the effects of the 'ours' strategy to the -s\n> description. Also remove the mention of the 'octopus' strategy, which\n> was copied from the git-merge description but is pointless in a\n> rebase.\n\nInstead of saying \"peculiarities\" without saying what is peculiar about\nit, it might be better to give an explanation that would help the reader\nunderstand why they appear \"swapped\".\n\nHere is my attempt. Thoughts?\n\n Documentation/git-rebase.txt | 12 ++++++++----\n 1 files changed, 8 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex e802421..a6f8182 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -229,9 +229,11 @@ OPTIONS\n \tstrategy is used, this allows rebase to be aware of renames on the\n \tupstream side.\n +\n-Note that in a rebase merge (hence merge conflict), the sides are\n-swapped: \"theirs\" is the to-be-applied patch, and \"ours\" is the so-far\n-rebased series, starting with .\n+Note that a rebase merge works by replaying each commit from the working\n+branch on top of the branch. Because of this, when a merge\n+conflict happens, the side reported as 'ours' is the so-far rebased\n+series, starting with , and 'theirs' is the working branch. In\n+other words, the sides are swapped.\n \n -s ::\n --strategy=::\n@@ -239,7 +241,9 @@ rebased series, starting with .\n \tIf there is no `-s` option 'git-merge-recursive' is used\n \tinstead. This implies --merge.\n +\n-Due to the peculiarities of 'git-rebase' (see \\--merge above), using\n+Because 'git-rebase' replays each commit from the working branch\n+on top of the branch using the given strategy,\n+(see \\--merge above), using\n the 'ours' strategy simply discards all patches from the ,\n which makes little sense. Thus 'git-rebase' does not accept this\n strategy.\n"},{"id":"127639","messageId":"200911152211.11928.trast@student.ethz.ch","threadId":"21454","inReplyTo":"7v7htrfqi1.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 2/3] rebase docs: clarify --merge and --strategy","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-15T21:11:10Z","receivedAt":"2009-11-15T21:11:10Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index e802421..a6f8182 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -229,9 +229,11 @@ OPTIONS\n> \tstrategy is used, this allows rebase to be aware of renames on the\n> \tupstream side.\n> +\n> -Note that in a rebase merge (hence merge conflict), the sides are\n> -swapped: \"theirs\" is the to-be-applied patch, and \"ours\" is the so-far\n> -rebased series, starting with .\n> +Note that a rebase merge works by replaying each commit from the working\n> +branch on top of the branch. Because of this, when a merge\n> +conflict happens, the side reported as 'ours' is the so-far rebased\n> +series, starting with , and 'theirs' is the working branch. In\n> +other words, the sides are swapped.\n\nThis is much nicer than mine!\n\n> -Due to the peculiarities of 'git-rebase' (see \\--merge above), using\n> +Because 'git-rebase' replays each commit from the working branch\n> +on top of the branch using the given strategy,\n> +(see \\--merge above), using\n> the 'ours' strategy simply discards all patches from the ,\n> which makes little sense. Thus 'git-rebase' does not accept this\n> strategy.\n\nHere I'm not sure if it makes such a big difference, since we already\nexplained the problem in --merge (and point to it). But yours is fine\ntoo.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"127640","messageId":"200911152213.18743.trast@student.ethz.ch","threadId":"21454","inReplyTo":"7veinzfqj9.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 0/3] Document and refuse rebase -s ours","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2009-11-15T21:13:15Z","receivedAt":"2009-11-15T21:13:15Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Junio C Hamano wrote:\n> \n> I'd rewrite [3/3] in the following way to keep it easier to maintain the\n> blacklist, like this.\n> \n> case \"$1\" in\n> - ours)\n> + ours | theirs | octopus | subtree)\n\nI agree with the rewrite; it's easier to maintain, even though it's\nnow in a quite strange place.\n\nHowever, I think the example you gave is misleading: 'subtree' is a\nuseful strategy if you want to rebase across a subtree merge boundary,\nisn't it?\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"127664","messageId":"alpine.DEB.2.00.0911160916250.9282@ds9.cixit.se","threadId":"21454","inReplyTo":"7vk4xsqhkv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Re: Clarify documentation on the \"ours\" merge strategy.","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2009-11-16T08:20:06Z","receivedAt":"2009-11-16T08:20:06Z","isPatch":true,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Junio C Hamano:\n\n> Even though I still think -Xours/-Xtheirs are nonsense options in the \n> context of source code management, I suspect that they might be exactly \n> what Peter needs in this situation.\n\nYes, it sounds like it would. That is not something I would use for source \ncode management, but it would fit this, and some other use-cases I have, \nquite nicely.\n\nI tend to use Git not only for source code management, but also for document \nsynchronisation across machines which may, or may not, be connected to a \nnetwork at any given time. Git is very nice for that sort of work.\n\n> ; otherwise Peter's web site is seriously broken from the security point \n> of view and no SCM can fix that),\n\nIndeed. If it that was the case, I deserve whatever problems I get :-)\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"127680","messageId":"alpine.DEB.1.00.0911161333470.4985@pacific.mpi-cbg.de","threadId":"21454","inReplyTo":"efd7770d166a97481e8e31e407b9c2da02a341e5.1258309432.git.trast@student.ethz.ch","subject":"Re: [PATCH 3/3] rebase: refuse to rebase with -s ours","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-16T12:35:13Z","receivedAt":"2009-11-16T12:35:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 15 Nov 2009, Thomas Rast wrote:\n\n> Using the \"ours\" strategy with rebase just discards all changes, turning \n> into (or if given). This is unlikely to \n> be what the user wants, so simply refuse to do it.\n\n\"Unlikely\" or \"impossible\"?\n\nBesides, I find it rather arbitrary that the \"ours\" strategy is refused, \nbut none of the user-provided merge strategies. IOW disallowing \"ours\" \nmay very well foster unreasonable expectations.\n\nCiao,\nDscho\n"},{"id":"127695","messageId":"7vpr7ip7ji.fsf@alter.siamese.dyndns.org","threadId":"21454","inReplyTo":"alpine.DEB.1.00.0911161333470.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH 3/3] rebase: refuse to rebase with -s ours","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-16T19:57:05Z","receivedAt":"2009-11-16T19:57:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Sun, 15 Nov 2009, Thomas Rast wrote:\n>\n>> Using the \"ours\" strategy with rebase just discards all changes, turning \n>> into (or if given). This is unlikely to \n>> be what the user wants, so simply refuse to do it.\n>\n> \"Unlikely\" or \"impossible\"?\n\nIt is more like \"very likely to be a mistake\".\n\nOur tradition has been to give them long enough rope, but the recent trend\nis to consider ourselves experienced enough with various git workflows to\nbe capable of identifying not just \"cannot possibly a meaningful request\"\nbut also \"almost always a mistake\" cases, and tighten the rope to help\npeople from stumbling, I think.\n\nBut it needs more careful thought to avoid forbidding useful use cases,\nand your input is hugely appreciated if you have doubts (even better, an\nexample of useful use case that will become impossible).\n\n> Besides, I find it rather arbitrary that the \"ours\" strategy is refused, \n> but none of the user-provided merge strategies. IOW disallowing \"ours\" \n> may very well foster unreasonable expectations.\n\nI cannot read this quite clearly. Unreasonable expectations being...?\n\n * \"ours\" is disallowed but anything else including user-provided ones are\n Ok, so we are allowed to circumvent this restriction by adding a\n synonym for \"ours\" as a user-defined one, and are encouraged to do\n so. ---that is a wrong message to send. Is that what you mean?\n\n * strategy X, unlike \"ours\", is allowed, so users will have rights to\n expect use of X as a rebase strategy would yield useful result, but\n that is wrong---Dscho knows that merge strategy X (I cannot read which\n one you had in mind if this is what you are talking about) does not\n work well in this and that cases. Is this what you mean, and if so\n what is X?\n\nPerhaps you had something other than the above two in mind?\n"},{"id":"127698","messageId":"alpine.DEB.1.00.0911162213590.4985@pacific.mpi-cbg.de","threadId":"21454","inReplyTo":"7vpr7ip7ji.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] rebase: refuse to rebase with -s ours","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-11-16T21:25:13Z","receivedAt":"2009-11-16T21:25:13Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 16 Nov 2009, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Sun, 15 Nov 2009, Thomas Rast wrote:\n> >\n> >> Using the \"ours\" strategy with rebase just discards all changes, \n> >> turning into (or if given). This is \n> >> unlikely to be what the user wants, so simply refuse to do it.\n> \n> > Besides, I find it rather arbitrary that the \"ours\" strategy is \n> > refused, but none of the user-provided merge strategies. IOW \n> > disallowing \"ours\" may very well foster unreasonable expectations.\n> \n> I cannot read this quite clearly.\n\nI meant the following: if \"rebase -s ours\" refuses to run, but my boss has \nwritten this cunning merge strategy \"superduper\" which is equally unlikely \nto yield a sensible result, \"rebase -s superduper\" should still refuse to \nrun, no?\n\nNow, this scenario might be too rare to take care of, but maybe it shows \nthat we have a design flaw here?\n\nCiao,\nDscho\n\nP.S.: Please note that I do not make a case against Thomas' patch series. \nAs gitzilla once said \"I cannot provide alternative patches, so that's \nthat\".\n"},{"id":"127699","messageId":"7viqdannxo.fsf@alter.siamese.dyndns.org","threadId":"21454","inReplyTo":"alpine.DEB.1.00.0911162213590.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH 3/3] rebase: refuse to rebase with -s ours","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-16T21:45:55Z","receivedAt":"2009-11-16T21:45:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I meant the following: if \"rebase -s ours\" refuses to run, but my boss has \n> written this cunning merge strategy \"superduper\" which is equally unlikely \n> to yield a sensible result, \"rebase -s superduper\" should still refuse to \n> run, no?\n\nWhy should it?\n\n> Now, this scenario might be too rare to take care of, but maybe it shows \n> that we have a design flaw here?\n\nThe decision is up to the user who is much more familiar with such a\ncustom 'superduper' strategy, and git itself is in no position to make\nthat decision for the user. It is none of our business to forbid users\nfrom using what he wrote, when we do not know what it is.\n\nI do not think the \"rarity\" is relevant.\n\nWhat do you mean by a design flaw? In other words, how should things look\nlike in your ideal design?\n\nCertainly you are not talking about a design that enforces users who want\nto use custom strategy to first submit the strategy implementation to us\nfor a review and have our blessings (perhaps we digitally sign approved\nstrategy implementations) before being able to use it in \"merge -s\" and\n\"rebase -s\".\n\nI can _guess_ what you are _not_ talking about but I cannot tell what you\n_are_ talking about; sorry.\n"},{"id":"127702","messageId":"fabb9a1e0911161404u56b1498cpfea7650f6c46845e@mail.gmail.com","threadId":"21454","inReplyTo":"7viqdannxo.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 3/3] rebase: refuse to rebase with -s ours","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-16T22:04:12Z","receivedAt":"2009-11-16T22:04:12Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Nov 16, 2009 at 22:45, Junio C Hamano wrote:\n> I can _guess_ what you are _not_ talking about but I cannot tell what you\n> _are_ talking about; sorry.\n\nI would hazard a way for the merge strategy to indicate whether it is\nfit to be used as rebase strategy?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"127707","messageId":"4B01DA65.7050003@gmail.com","threadId":"21454","inReplyTo":"alpine.DEB.1.00.0911162213590.4985@pacific.mpi-cbg.de","subject":"Re: [PATCH 3/3] rebase: refuse to rebase with -s ours","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2009-11-16T23:04:05Z","receivedAt":"2009-11-16T23:04:05Z","isPatch":true,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n[...]\n> As gitzilla once said \"I cannot provide alternative patches, so that's \n> that\".\n\nI'm not sure I actually said that [*1*] but I did point out that when \nthere is an active discussion about which of multiple ways a feature can \nbe implemented, the party that produces code usually gets their way.\n\n[*1*] There was beer involved and I was jet-lagged so maybe I did say \nthat when I meant what I wrote above.\n"}]}