{"thread":{"id":"37050","subject":"[BUG] rebase no longer omits local commits","startedAt":"2014-07-03T15:14:26Z","lastAt":"2014-07-17T09:36:22Z","messageCount":15,"participants":["Ted Felix","John Keeping","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"245378","messageId":"53B57352.50202@tedfelix.com","threadId":"37050","inReplyTo":null,"subject":"[BUG] rebase no longer omits local commits","fromName":"Ted Felix","fromEmail":"ted@tedfelix.com","sentAt":"2014-07-03T15:14:26Z","receivedAt":"2014-07-03T15:14:26Z","isPatch":false,"sender":{"key":"ted@tedfelix.com","avatar":"https://gravatar.com/avatar/222e94b6ee19381bf0badf8afb96d689cd523e84c4fb1676163c9ac2326f68e1?d=mp&s=160"},"body":"Starting with git 1.9.0, rebase no longer omits local commits that \nappear in both the upstream and local branches.\n\nI've bisected this down to commit bb3f458: \"rebase: fix fork-point with \nzero arguments\".  The attached script reproduces the problem.  Reverting \nthe aforementioned commit fixes the problem.\n\nA failed run of this script will result in conflicts.  A successful run \nagainst master with bb3f458 reverted ends as follows:\n\n From /tmp/rebase-issue/maint\n    fe401cd..955af04  master     -> origin/master\nfatal: Not a valid object name: ''\nFirst, rewinding head to replay your work on top of it...\nApplying: Third change\n\n(I'm not sure if that \"fatal: Not a valid object name: ''\" is of any \nconcern.  It started appearing for me at some point during the bisect.)\n\nLet me know if there's more I can do to help.\n\n\n\n#!/bin/bash\n\n# git-rebase is supposed to drop commits that it finds in both the \n# local and upstream branches.  As of 1.9.0, this isn't happening.\n# This script reproduces the problem.\n\n# I've bisected the issue down to commit bb3f458.  Reverting that commit\n# solves the problem.\n\n# Run this in a directory where you have create privs.\n# At the end, if there are conflicts, then the test has failed.\n\n# Create a repo.\nmkdir rebase-issue\ncd rebase-issue\nmkdir maint\ncd maint\ngit init\n\n# Create a README file and put some text in it\necho \"Hi there!\" >README\ngit add README\ngit commit -a -m \"Initial commit\"\n\n# Clone the repo for \"dev\"\ncd ..\ngit clone maint dev\n\n# Dev makes *two* changes to the *same* area.\ncd dev\n# edit something, make some typos\necho \"Freekwently Mispeled Werdz\" >README\ngit commit -a -m \"First change\"\n# edit same thing, fix those typos\necho \"Frequently Misspelled Words\" >README\ngit commit -a -m \"Second change\"\n\n# Create patches to send to maintainer...\ngit format-patch -M origin/master\nmv *.patch ../maint\n\n# Add a third change that should make it through for completeness.\necho \"Frequently Misspelled Words version 2\" >README\ngit commit -a -m \"Third change\"\n\n# We have to sleep (to make sure the times do not match?).\n# If we don't, this script will succeed on fast machines.\n# This can probably be reduced to 2 which should guarantee that\n# the seconds will turn over on the clock.\necho\necho \"Waiting 5 seconds to make sure apply time is different from patch time...\"\nsleep 5\n\necho\necho \"Maint applies patches...\"\ncd ../maint\ngit am -3 *.patch\n\necho\necho \"Dev does the fetch/rebase...\"\ncd ../dev\ngit fetch\ngit rebase\n\necho\ngit --version\n\n"},{"id":"245386","messageId":"20140703190917.GE13153@serenity.lan","threadId":"37050","inReplyTo":"53B57352.50202@tedfelix.com","subject":"Re: [BUG] rebase no longer omits local commits","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-07-03T19:09:17Z","receivedAt":"2014-07-03T19:09:17Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, Jul 03, 2014 at 11:14:26AM -0400, Ted Felix wrote:\n> Starting with git 1.9.0, rebase no longer omits local commits that \n> appear in both the upstream and local branches.\n> \n> I've bisected this down to commit bb3f458: \"rebase: fix fork-point with \n> zero arguments\".  The attached script reproduces the problem.  Reverting \n> the aforementioned commit fixes the problem.\n> \n> A failed run of this script will result in conflicts.  A successful run \n> against master with bb3f458 reverted ends as follows:\n> \n>  From /tmp/rebase-issue/maint\n>     fe401cd..955af04  master     -> origin/master\n> fatal: Not a valid object name: ''\n> First, rewinding head to replay your work on top of it...\n> Applying: Third change\n> \n> (I'm not sure if that \"fatal: Not a valid object name: ''\" is of any \n> concern.  It started appearing for me at some point during the bisect.)\n\nIt is the problem that bb3f458 fixes.  The change in behaviour is\nactually introduced by ad8261d (rebase: use reflog to find common base\nwith upstream).\n\nIn your example, I think this is working as designed.  You can restore\nthe previous behaviour either with `git rebase --no-fork-point` or with\n`git rebase @{u}`.\n\nThe change is designed to help users recover from an upstream rebase, as\ndescribed in the \"DISCUSSION ON FORK-POINT MODE\" section of\ngit-merge-base(1) and makes `git rebase` match the behaviour of\n`git pull --rebase` so that:\n\n\tgit fetch &&\n\tgit rebase\n\nreally is equivalent to:\n\n\tgit pull --rebase\n"},{"id":"245398","messageId":"20140703222501.GF13153@serenity.lan","threadId":"37050","inReplyTo":"20140703190917.GE13153@serenity.lan","subject":"Re: [BUG] rebase no longer omits local commits","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-07-03T22:25:02Z","receivedAt":"2014-07-03T22:25:02Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Thu, Jul 03, 2014 at 08:09:17PM +0100, John Keeping wrote:\n> On Thu, Jul 03, 2014 at 11:14:26AM -0400, Ted Felix wrote:\n> > Starting with git 1.9.0, rebase no longer omits local commits that \n> > appear in both the upstream and local branches.\n> \n> It is the problem that bb3f458 fixes.  The change in behaviour is\n> actually introduced by ad8261d (rebase: use reflog to find common base\n> with upstream).\n> \n> In your example, I think this is working as designed.  You can restore\n> the previous behaviour either with `git rebase --no-fork-point` or with\n> `git rebase @{u}`.\n> \n> The change is designed to help users recover from an upstream rebase, as\n> described in the \"DISCUSSION ON FORK-POINT MODE\" section of\n> git-merge-base(1).\n\nHaving thought about this a bit more, I think the case you've identified\nis an unexpected side effect of that commit.\n\nPerhaps we shuld do something like this (which passes the test suite):\n\n-- >8 --\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 06c810b..0c6c5d3 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -544,7 +544,8 @@ if test \"$fork_point\" = t\n then\n \tnew_upstream=$(git merge-base --fork-point \"$upstream_name\" \\\n \t\t\t\"${switch_to:-HEAD}\")\n-\tif test -n \"$new_upstream\"\n+\tif test -n \"$new_upstream\" &&\n+\t   ! git merge-base --is-ancestor \"$new_upstream\" \"$upstream_name\"\n \tthen\n \t\tupstream=$new_upstream\n \tfi\n-- 8< --\n\nSince the intent of `--fork-point` is to find the best starting point\nfor the \"$upstream...$orig_head\" range, if the fork point is behind the\nnew location of the upstream then should we leave the upstream as it\nwas?\n\nI haven't thought through this completely, but it seems like we should\nbe doing a check like the above, at least when we're in\n\"$fork_point=auto\" mode.\n"},{"id":"245483","messageId":"xmqqbnt1dpdk.fsf@gitster.dls.corp.google.com","threadId":"37050","inReplyTo":"20140703222501.GF13153@serenity.lan","subject":"Re: [BUG] rebase no longer omits local commits","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-07-07T17:56:23Z","receivedAt":"2014-07-07T17:56:23Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> Perhaps we shuld do something like this (which passes the test suite):\n>\n> -- >8 --\n> diff --git a/git-rebase.sh b/git-rebase.sh\n> index 06c810b..0c6c5d3 100755\n> --- a/git-rebase.sh\n> +++ b/git-rebase.sh\n> @@ -544,7 +544,8 @@ if test \"$fork_point\" = t\n>  then\n>  \tnew_upstream=$(git merge-base --fork-point \"$upstream_name\" \\\n>  \t\t\t\"${switch_to:-HEAD}\")\n> -\tif test -n \"$new_upstream\"\n> +\tif test -n \"$new_upstream\" &&\n> +\t   ! git merge-base --is-ancestor \"$new_upstream\" \"$upstream_name\"\n>  \tthen\n>  \t\tupstream=$new_upstream\n>  \tfi\n> -- 8< --\n>\n> Since the intent of `--fork-point` is to find the best starting point\n> for the \"$upstream...$orig_head\" range, if the fork point is behind the\n> new location of the upstream then should we leave the upstream as it\n> was?\n\nProbably; but the check to avoid giving worse fork-point should be\nin the implementation of \"merge-base --fork-point\" itself, so that\nwe do not have to do the above to both \"rebase\" and \"pull --rebase\",\nno?\n\n> I haven't thought through this completely, but it seems like we should\n> be doing a check like the above, at least when we're in\n> \"$fork_point=auto\" mode.\n"},{"id":"245494","messageId":"20140707211456.GA2322@serenity.lan","threadId":"37050","inReplyTo":"xmqqbnt1dpdk.fsf@gitster.dls.corp.google.com","subject":"Re: [BUG] rebase no longer omits local commits","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-07-07T21:14:57Z","receivedAt":"2014-07-07T21:14:57Z","isPatch":false,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Mon, Jul 07, 2014 at 10:56:23AM -0700, Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n> \n> > Perhaps we shuld do something like this (which passes the test suite):\n> >\n> > -- >8 --\n> > diff --git a/git-rebase.sh b/git-rebase.sh\n> > index 06c810b..0c6c5d3 100755\n> > --- a/git-rebase.sh\n> > +++ b/git-rebase.sh\n> > @@ -544,7 +544,8 @@ if test \"$fork_point\" = t\n> >  then\n> >  \tnew_upstream=$(git merge-base --fork-point \"$upstream_name\" \\\n> >  \t\t\t\"${switch_to:-HEAD}\")\n> > -\tif test -n \"$new_upstream\"\n> > +\tif test -n \"$new_upstream\" &&\n> > +\t   ! git merge-base --is-ancestor \"$new_upstream\" \"$upstream_name\"\n> >  \tthen\n> >  \t\tupstream=$new_upstream\n> >  \tfi\n> > -- 8< --\n> >\n> > Since the intent of `--fork-point` is to find the best starting point\n> > for the \"$upstream...$orig_head\" range, if the fork point is behind the\n> > new location of the upstream then should we leave the upstream as it\n> > was?\n> \n> Probably; but the check to avoid giving worse fork-point should be\n> in the implementation of \"merge-base --fork-point\" itself, so that\n> we do not have to do the above to both \"rebase\" and \"pull --rebase\",\n> no?\n\nI don't think so, since in that case we're not actually finding the fork\npoint as defined in the documentation, we're finding the upstream rebase\nwants.\n\nHaving played with this a bit, I think we shouldn't be replacing the\nupstream with the fork point but should instead add the fork point as an\nadditional negative ref:\n\n\t$upstream...$orig_head ^$fork_point\n\nHere's a script that creates a repository showing this:\n\n-- >8 --\n#!/bin/sh\ngit init rebase-test &&\ncd rebase-test &&\necho one >file &&\ngit add file &&\ngit commit -m one &&\necho frist >file2 &&\ngit add file2 &&\ngit commit -m first &&\ngit branch --track dev &&\necho first >file2 &&\ngit commit -a --amend --no-edit &&\necho two >file &&\ngit commit -a -m two &&\necho three >file &&\ngit commit -a -m three &&\necho second >file2 &&\ngit commit -a -m second &&\ngit checkout dev &&\ngit cherry-pick -2 master &&\necho four >file &&\ngit commit -a -m four &&\nprintf '\\nWithout fork point (old behaviour)\\n' &&\ngit rev-list --oneline --cherry @{u}... &&\nprintf '\\nFork point as upstream (current behaviour)\\n' &&\ngit rev-list --oneline --cherry $(git merge-base --fork-point master HEAD)... &&\nprintf '\\nWith fork point\\n' &&\ngit rev-list --oneline --cherry @{u}... ^$(git merge-base --fork-point master HEAD)\n-- 8< --\n\nIn this case the rebase should be clean since the only applicable patch\nchanges \"three\" to \"four\" in \"file\", but the current rebase code fails\nboth with `--fork-point` and with `--no-fork-point`.\n\nWith `--fork-point` we try to apply \"two\" and \"three\" which have already\nbeen cherry-picked across (as Ted originally reported) and with\n`--no-fork-point`, we try to apply \"first\" which conflicts because we\nhave the version prior to it being fixed up on master.\n\nI hacked up git-rebase to test this and the change to use the fork point\nas in the last line of the script above does indeed make the rebase go\nthrough cleanly, but I have not yet looked at how to cleanly patch in\nthat behaviour.\n\nI haven't tested git-pull, but it looks like it has always (since 2009)\nbehaved in the way `git rebase --fork-point` does now, failing to detect\ncherry-picked commits that are now in the upstream.\n"},{"id":"246081","messageId":"47e67c62fb2a8c8846f5d3a12d71aebf8fa875d7.1405451643.git.john@keeping.me.uk","threadId":"37050","inReplyTo":"20140707211456.GA2322@serenity.lan","subject":"[PATCH 1/2] rebase--am: use --cherry-pick instead of --ignore-if-in-upstream","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-07-15T19:14:02Z","receivedAt":"2014-07-15T19:14:02Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"When using `git format-patch --ignore-if-in-upstream` we are only\nallowed to give a single revision range.  In the next commit we will\nwant to add an additional exclusion revision in order to handle fork\npoints correctly, so convert `git-rebase--am` to use a symmetric\ndifference with `--cherry-pick --right-only`.\n\nThis does not change the result of the format-patch invocation, just how\nwe spell the arguments.\n\nSigned-off-by: John Keeping <john@keeping.me.uk>\n---\n git-rebase--am.sh | 15 +++++++++++----\n 1 file changed, 11 insertions(+), 4 deletions(-)\n\ndiff --git a/git-rebase--am.sh b/git-rebase--am.sh\nindex ca20e1e..902bf2d 100644\n--- a/git-rebase--am.sh\n+++ b/git-rebase--am.sh\n@@ -29,7 +29,13 @@ skip)\n \t;;\n esac\n \n-test -n \"$rebase_root\" && root_flag=--root\n+if test -z \"$rebase_root\"\n+\t# this is now equivalent to ! -z \"$upstream\"\n+then\n+\trevisions=$upstream...$orig_head\n+else\n+\trevisions=$onto...$orig_head\n+fi\n \n ret=0\n if test -n \"$keep_empty\"\n@@ -38,14 +44,15 @@ then\n \t# empty commits and even if it didn't the format doesn't really lend\n \t# itself well to recording empty patches.  fortunately, cherry-pick\n \t# makes this easy\n-\tgit cherry-pick ${gpg_sign_opt:+\"$gpg_sign_opt\"} --allow-empty \"$revisions\"\n+\tgit cherry-pick ${gpg_sign_opt:+\"$gpg_sign_opt\"} --allow-empty \\\n+\t\t--right-only \"$revisions\"\n \tret=$?\n else\n \trm -f \"$GIT_DIR/rebased-patches\"\n \n-\tgit format-patch -k --stdout --full-index --ignore-if-in-upstream \\\n+\tgit format-patch -k --stdout --full-index --cherry-pick --right-only \\\n \t\t--src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter \\\n-\t\t$root_flag \"$revisions\" >\"$GIT_DIR/rebased-patches\"\n+\t\t\"$revisions\" >\"$GIT_DIR/rebased-patches\"\n \tret=$?\n \n \tif test 0 != $ret\n-- \n2.0.1.472.g6f92e5f.dirty\n"},{"id":"246082","messageId":"01d69c566e04256fb0321ab9685d1f05a80cb41d.1405451643.git.john@keeping.me.uk","threadId":"37050","inReplyTo":"47e67c62fb2a8c8846f5d3a12d71aebf8fa875d7.1405451643.git.john@keeping.me.uk","subject":"[PATCH 2/2] rebase: omit patch-identical commits with --fork-point","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-07-15T19:14:03Z","receivedAt":"2014-07-15T19:14:03Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"When the `--fork-point` argument was added to `git rebase`, we changed\nthe value of $upstream to be the fork point instead of the point from\nwhich we want to rebase.  When $orig_head..$upstream is empty this does\nnot change the behaviour, but when there are new changes in the upstream\nwe are no longer checking if any of them are patch-identical with\nchanges in $upstream..$orig_head.\n\nFix this by introducing a new variable to hold the fork point and using\nthis to restrict the range as an extra (negative) revision argument so\nthat the set of desired revisions becomes (in fork-point mode):\n\n\tgit rev-list --cherry-pick --right-only \\\n\t\t$upstream...$orig_head ^$fork_point\n\nThis allows us to correctly handle the scenario where we have the\nfollowing topology:\n\n\t    C --- D --- E  <- dev\n\t   /\n\t  B  <- master@{1}\n\t /\n\to --- B' --- C* --- D*  <- master\n\nwhere:\n- B' is a fixed-up version of B that is not patch-identical with B;\n- C* and D* are patch-identical to C and D respectively and conflict\n  textually if applied in the wrong order;\n- E depends textually on D.\n\nThe correct result of `git rebase master dev` is that B is identified as\nthe fork-point of dev and master, so that C, D, E are the commits that\nneed to be replayed onto master; but C and D are patch-identical with C*\nand D* and so can be dropped, so that the end result is:\n\n\to --- B' --- C* --- D* --- E  <- dev\n\nIf the fork-point is not identified, then picking B onto a branch\ncontaining B' results in a conflict and if the patch-identical commits\nare not correctly identified then picking C onto a branch containing D\n(or equivalently D*) results in a conflict.\n\nThis change allows us to handle both of these cases, where previously we\neither identified the fork-point (with `--fork-point`) but not the\npatch-identical commits *or* (with `--no-fork-point`) identified the\npatch-identical commits but not the fact that master had been rewritten.\n\nReported-by: Ted Felix <ted@tedfelix.com>\nSigned-off-by: John Keeping <john@keeping.me.uk>\n---\n git-rebase--am.sh          | 6 ++++--\n git-rebase--interactive.sh | 2 +-\n git-rebase.sh              | 7 ++++---\n 3 files changed, 9 insertions(+), 6 deletions(-)\n\ndiff --git a/git-rebase--am.sh b/git-rebase--am.sh\nindex 902bf2d..f923732 100644\n--- a/git-rebase--am.sh\n+++ b/git-rebase--am.sh\n@@ -45,14 +45,16 @@ then\n \t# itself well to recording empty patches.  fortunately, cherry-pick\n \t# makes this easy\n \tgit cherry-pick ${gpg_sign_opt:+\"$gpg_sign_opt\"} --allow-empty \\\n-\t\t--right-only \"$revisions\"\n+\t\t--right-only \"$revisions\" \\\n+\t\t${restrict_revision+^$restrict_revision}\n \tret=$?\n else\n \trm -f \"$GIT_DIR/rebased-patches\"\n \n \tgit format-patch -k --stdout --full-index --cherry-pick --right-only \\\n \t\t--src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter \\\n-\t\t\"$revisions\" >\"$GIT_DIR/rebased-patches\"\n+\t\t\"$revisions\" ${restrict_revision+^$restrict_revision} \\\n+\t\t>\"$GIT_DIR/rebased-patches\"\n \tret=$?\n \n \tif test 0 != $ret\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 7e1eda0..b64dd28 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -963,7 +963,7 @@ else\n fi\n git rev-list $merges_option --pretty=oneline --abbrev-commit \\\n \t--abbrev=7 --reverse --left-right --topo-order \\\n-\t$revisions | \\\n+\t$revisions ${restrict_revision+^$restrict_revision} | \\\n \tsed -n \"s/^>//p\" |\n while read -r shortsha1 rest\n do\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 06c810b..55da9db 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -59,6 +59,7 @@ If you prefer to skip this patch, run \"git rebase --skip\" instead.\n To check out the original branch and stop rebasing, run \"git rebase --abort\".')\n \"\n unset onto\n+unset restrict_revision\n cmd=\n strategy=\n strategy_opts=\n@@ -546,7 +547,7 @@ then\n \t\t\t\"${switch_to:-HEAD}\")\n \tif test -n \"$new_upstream\"\n \tthen\n-\t\tupstream=$new_upstream\n+\t\trestrict_revision=$new_upstream\n \tfi\n fi\n \n@@ -572,7 +573,7 @@ require_clean_work_tree \"rebase\" \"$(gettext \"Please commit or stash them.\")\"\n # and if this is not an interactive rebase.\n mb=$(git merge-base \"$onto\" \"$orig_head\")\n if test \"$type\" != interactive && test \"$upstream\" = \"$onto\" &&\n-\ttest \"$mb\" = \"$onto\" &&\n+\ttest \"$mb\" = \"$onto\" && test -z \"$restrict_revision\" &&\n \t# linear history?\n \t! (git rev-list --parents \"$onto\"..\"$orig_head\" | sane_grep \" .* \") > /dev/null\n then\n@@ -626,7 +627,7 @@ if test -n \"$rebase_root\"\n then\n \trevisions=\"$onto..$orig_head\"\n else\n-\trevisions=\"$upstream..$orig_head\"\n+\trevisions=\"${restrict_revision-$upstream}..$orig_head\"\n fi\n \n run_specific_rebase\n-- \n2.0.1.472.g6f92e5f.dirty\n"},{"id":"246089","messageId":"53C58597.9040509@tedfelix.com","threadId":"37050","inReplyTo":"01d69c566e04256fb0321ab9685d1f05a80cb41d.1405451643.git.john@keeping.me.uk","subject":"Re: [PATCH 2/2] rebase: omit patch-identical commits with --fork-point","fromName":"Ted Felix","fromEmail":"ted@tedfelix.com","sentAt":"2014-07-15T19:48:39Z","receivedAt":"2014-07-15T19:48:39Z","isPatch":true,"sender":{"key":"ted@tedfelix.com","avatar":"https://gravatar.com/avatar/222e94b6ee19381bf0badf8afb96d689cd523e84c4fb1676163c9ac2326f68e1?d=mp&s=160"},"body":"   Thanks, John.  My test script is working fine for me now with these \npatches.\n"},{"id":"246102","messageId":"xmqqmwcatgza.fsf@gitster.dls.corp.google.com","threadId":"37050","inReplyTo":"01d69c566e04256fb0321ab9685d1f05a80cb41d.1405451643.git.john@keeping.me.uk","subject":"Re: [PATCH 2/2] rebase: omit patch-identical commits with --fork-point","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-07-15T22:06:01Z","receivedAt":"2014-07-15T22:06:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> When the `--fork-point` argument was added to `git rebase`, we changed\n> the value of $upstream to be the fork point instead of the point from\n> which we want to rebase.  When $orig_head..$upstream is empty this does\n> not change the behaviour, but when there are new changes in the upstream\n> we are no longer checking if any of them are patch-identical with\n> changes in $upstream..$orig_head.\n>\n> Fix this by introducing a new variable to hold the fork point and using\n> this to restrict the range as an extra (negative) revision argument so\n> that the set of desired revisions becomes (in fork-point mode):\n>\n> \tgit rev-list --cherry-pick --right-only \\\n> \t\t$upstream...$orig_head ^$fork_point\n>\n> This allows us to correctly handle the scenario where we have the\n> following topology:\n>\n> \t    C --- D --- E  <- dev\n> \t   /\n> \t  B  <- master@{1}\n> \t /\n> \to --- B' --- C* --- D*  <- master\n>\n> where:\n> - B' is a fixed-up version of B that is not patch-identical with B;\n> - C* and D* are patch-identical to C and D respectively and conflict\n>   textually if applied in the wrong order;\n> - E depends textually on D.\n>\n> The correct result of `git rebase master dev` is that B is identified as\n> the fork-point of dev and master, so that C, D, E are the commits that\n> need to be replayed onto master; but C and D are patch-identical with C*\n> and D* and so can be dropped, so that the end result is:\n>\n> \to --- B' --- C* --- D* --- E  <- dev\n>\n> If the fork-point is not identified, then picking B onto a branch\n> containing B' results in a conflict and if the patch-identical commits\n> are not correctly identified then picking C onto a branch containing D\n> (or equivalently D*) results in a conflict.\n>\n> This change allows us to handle both of these cases, where previously we\n> either identified the fork-point (with `--fork-point`) but not the\n> patch-identical commits *or* (with `--no-fork-point`) identified the\n> patch-identical commits but not the fact that master had been rewritten.\n>\n> Reported-by: Ted Felix <ted@tedfelix.com>\n> Signed-off-by: John Keeping <john@keeping.me.uk>\n> ---\n>  git-rebase--am.sh          | 6 ++++--\n>  git-rebase--interactive.sh | 2 +-\n>  git-rebase.sh              | 7 ++++---\n>  3 files changed, 9 insertions(+), 6 deletions(-)\n\nCan we have some tests, too?\n\nThe changes look correct from a cursory reading.\n\nThanks.\n"},{"id":"246178","messageId":"47e67c62fb2a8c8846f5d3a12d71aebf8fa875d7.1405538598.git.john@keeping.me.uk","threadId":"37050","inReplyTo":"xmqqmwcatgza.fsf@gitster.dls.corp.google.com","subject":"[PATCH v2 1/2] rebase--am: use --cherry-pick instead of --ignore-if-in-upstream","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-07-16T19:23:48Z","receivedAt":"2014-07-16T19:23:48Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"When using `git format-patch --ignore-if-in-upstream` we are only\nallowed to give a single revision range.  In the next commit we will\nwant to add an additional exclusion revision in order to handle fork\npoints correctly, so convert `git-rebase--am` to use a symmetric\ndifference with `--cherry-pick --right-only`.\n\nThis does not change the result of the format-patch invocation, just how\nwe spell the arguments.\n\nSigned-off-by: John Keeping <john@keeping.me.uk>\n---\n\nUnchanged from v1.\n\n git-rebase--am.sh | 15 +++++++++++----\n 1 file changed, 11 insertions(+), 4 deletions(-)\n\ndiff --git a/git-rebase--am.sh b/git-rebase--am.sh\nindex ca20e1e..902bf2d 100644\n--- a/git-rebase--am.sh\n+++ b/git-rebase--am.sh\n@@ -29,7 +29,13 @@ skip)\n \t;;\n esac\n \n-test -n \"$rebase_root\" && root_flag=--root\n+if test -z \"$rebase_root\"\n+\t# this is now equivalent to ! -z \"$upstream\"\n+then\n+\trevisions=$upstream...$orig_head\n+else\n+\trevisions=$onto...$orig_head\n+fi\n \n ret=0\n if test -n \"$keep_empty\"\n@@ -38,14 +44,15 @@ then\n \t# empty commits and even if it didn't the format doesn't really lend\n \t# itself well to recording empty patches.  fortunately, cherry-pick\n \t# makes this easy\n-\tgit cherry-pick ${gpg_sign_opt:+\"$gpg_sign_opt\"} --allow-empty \"$revisions\"\n+\tgit cherry-pick ${gpg_sign_opt:+\"$gpg_sign_opt\"} --allow-empty \\\n+\t\t--right-only \"$revisions\"\n \tret=$?\n else\n \trm -f \"$GIT_DIR/rebased-patches\"\n \n-\tgit format-patch -k --stdout --full-index --ignore-if-in-upstream \\\n+\tgit format-patch -k --stdout --full-index --cherry-pick --right-only \\\n \t\t--src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter \\\n-\t\t$root_flag \"$revisions\" >\"$GIT_DIR/rebased-patches\"\n+\t\t\"$revisions\" >\"$GIT_DIR/rebased-patches\"\n \tret=$?\n \n \tif test 0 != $ret\n-- \n2.0.1.472.g6f92e5f.dirty\n"},{"id":"246177","messageId":"374b26180807c67f7bd152ce5a2f52e34397e3a6.1405538598.git.john@keeping.me.uk","threadId":"37050","inReplyTo":"47e67c62fb2a8c8846f5d3a12d71aebf8fa875d7.1405538598.git.john@keeping.me.uk","subject":"[PATCH v2 2/2] rebase: omit patch-identical commits with --fork-point","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-07-16T19:23:49Z","receivedAt":"2014-07-16T19:23:49Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"When the `--fork-point` argument was added to `git rebase`, we changed\nthe value of $upstream to be the fork point instead of the point from\nwhich we want to rebase.  When $orig_head..$upstream is empty this does\nnot change the behaviour, but when there are new changes in the upstream\nwe are no longer checking if any of them are patch-identical with\nchanges in $upstream..$orig_head.\n\nFix this by introducing a new variable to hold the fork point and using\nthis to restrict the range as an extra (negative) revision argument so\nthat the set of desired revisions becomes (in fork-point mode):\n\n\tgit rev-list --cherry-pick --right-only \\\n\t\t$upstream...$orig_head ^$fork_point\n\nThis allows us to correctly handle the scenario where we have the\nfollowing topology:\n\n\t    C --- D --- E  <- dev\n\t   /\n\t  B  <- master@{1}\n\t /\n\to --- B' --- C* --- D*  <- master\n\nwhere:\n- B' is a fixed-up version of B that is not patch-identical with B;\n- C* and D* are patch-identical to C and D respectively and conflict\n  textually if applied in the wrong order;\n- E depends textually on D.\n\nThe correct result of `git rebase master dev` is that B is identified as\nthe fork-point of dev and master, so that C, D, E are the commits that\nneed to be replayed onto master; but C and D are patch-identical with C*\nand D* and so can be dropped, so that the end result is:\n\n\to --- B' --- C* --- D* --- E  <- dev\n\nIf the fork-point is not identified, then picking B onto a branch\ncontaining B' results in a conflict and if the patch-identical commits\nare not correctly identified then picking C onto a branch containing D\n(or equivalently D*) results in a conflict.\n\nThis change allows us to handle both of these cases, where previously we\neither identified the fork-point (with `--fork-point`) but not the\npatch-identical commits *or* (with `--no-fork-point`) identified the\npatch-identical commits but not the fact that master had been rewritten.\n\nReported-by: Ted Felix <ted@tedfelix.com>\nSigned-off-by: John Keeping <john@keeping.me.uk>\n---\n\nChange from v1:\n    - add a test case\n\n git-rebase--am.sh          |  6 ++++--\n git-rebase--interactive.sh |  2 +-\n git-rebase.sh              |  7 ++++---\n t/t3400-rebase.sh          | 23 +++++++++++++++++++++++\n 4 files changed, 32 insertions(+), 6 deletions(-)\n\ndiff --git a/git-rebase--am.sh b/git-rebase--am.sh\nindex 902bf2d..f923732 100644\n--- a/git-rebase--am.sh\n+++ b/git-rebase--am.sh\n@@ -45,14 +45,16 @@ then\n \t# itself well to recording empty patches.  fortunately, cherry-pick\n \t# makes this easy\n \tgit cherry-pick ${gpg_sign_opt:+\"$gpg_sign_opt\"} --allow-empty \\\n-\t\t--right-only \"$revisions\"\n+\t\t--right-only \"$revisions\" \\\n+\t\t${restrict_revision+^$restrict_revision}\n \tret=$?\n else\n \trm -f \"$GIT_DIR/rebased-patches\"\n \n \tgit format-patch -k --stdout --full-index --cherry-pick --right-only \\\n \t\t--src-prefix=a/ --dst-prefix=b/ --no-renames --no-cover-letter \\\n-\t\t\"$revisions\" >\"$GIT_DIR/rebased-patches\"\n+\t\t\"$revisions\" ${restrict_revision+^$restrict_revision} \\\n+\t\t>\"$GIT_DIR/rebased-patches\"\n \tret=$?\n \n \tif test 0 != $ret\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex 7e1eda0..b64dd28 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -963,7 +963,7 @@ else\n fi\n git rev-list $merges_option --pretty=oneline --abbrev-commit \\\n \t--abbrev=7 --reverse --left-right --topo-order \\\n-\t$revisions | \\\n+\t$revisions ${restrict_revision+^$restrict_revision} | \\\n \tsed -n \"s/^>//p\" |\n while read -r shortsha1 rest\n do\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 06c810b..55da9db 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -59,6 +59,7 @@ If you prefer to skip this patch, run \"git rebase --skip\" instead.\n To check out the original branch and stop rebasing, run \"git rebase --abort\".')\n \"\n unset onto\n+unset restrict_revision\n cmd=\n strategy=\n strategy_opts=\n@@ -546,7 +547,7 @@ then\n \t\t\t\"${switch_to:-HEAD}\")\n \tif test -n \"$new_upstream\"\n \tthen\n-\t\tupstream=$new_upstream\n+\t\trestrict_revision=$new_upstream\n \tfi\n fi\n \n@@ -572,7 +573,7 @@ require_clean_work_tree \"rebase\" \"$(gettext \"Please commit or stash them.\")\"\n # and if this is not an interactive rebase.\n mb=$(git merge-base \"$onto\" \"$orig_head\")\n if test \"$type\" != interactive && test \"$upstream\" = \"$onto\" &&\n-\ttest \"$mb\" = \"$onto\" &&\n+\ttest \"$mb\" = \"$onto\" && test -z \"$restrict_revision\" &&\n \t# linear history?\n \t! (git rev-list --parents \"$onto\"..\"$orig_head\" | sane_grep \" .* \") > /dev/null\n then\n@@ -626,7 +627,7 @@ if test -n \"$rebase_root\"\n then\n \trevisions=\"$onto..$orig_head\"\n else\n-\trevisions=\"$upstream..$orig_head\"\n+\trevisions=\"${restrict_revision-$upstream}..$orig_head\"\n fi\n \n run_specific_rebase\ndiff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh\nindex 80e0a95..47b5682 100755\n--- a/t/t3400-rebase.sh\n+++ b/t/t3400-rebase.sh\n@@ -169,6 +169,29 @@ test_expect_success 'default to common base in @{upstream}s reflog if no upstrea\n \ttest_cmp expect actual\n '\n \n+test_expect_success 'cherry-picked commits and fork-point work together' '\n+\tgit checkout default-base &&\n+\techo Amended >A &&\n+\tgit commit -a --no-edit --amend &&\n+\ttest_commit B B &&\n+\ttest_commit new_B B \"New B\" &&\n+\ttest_commit C C &&\n+\tgit checkout default &&\n+\tgit reset --hard default-base@{4} &&\n+\ttest_commit D D &&\n+\tgit cherry-pick -2 default-base^ &&\n+\ttest_commit final_B B \"Final B\" &&\n+\tgit rebase &&\n+\techo Amended >expect &&\n+\ttest_cmp A expect &&\n+\techo \"Final B\" >expect &&\n+\ttest_cmp B expect &&\n+\techo C >expect &&\n+\ttest_cmp C expect &&\n+\techo D >expect &&\n+\ttest_cmp D expect\n+'\n+\n test_expect_success 'rebase -q is quiet' '\n \tgit checkout -b quiet topic &&\n \tgit rebase -q master >output.out 2>&1 &&\n-- \n2.0.1.472.g6f92e5f.dirty\n"},{"id":"246182","messageId":"xmqqa989rqx3.fsf@gitster.dls.corp.google.com","threadId":"37050","inReplyTo":"374b26180807c67f7bd152ce5a2f52e34397e3a6.1405538598.git.john@keeping.me.uk","subject":"Re: [PATCH v2 2/2] rebase: omit patch-identical commits with --fork-point","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-07-16T20:26:32Z","receivedAt":"2014-07-16T20:26:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"John Keeping <john@keeping.me.uk> writes:\n\n> When the `--fork-point` argument was added to `git rebase`, we changed\n> the value of $upstream to be the fork point instead of the point from\n> which we want to rebase.  When $orig_head..$upstream is empty this does\n> not change the behaviour, but when there are new changes in the upstream\n> we are no longer checking if any of them are patch-identical with\n> changes in $upstream..$orig_head.\n>\n> Fix this by introducing a new variable to hold the fork point and using\n> this to restrict the range as an extra (negative) revision argument so\n> that the set of desired revisions becomes (in fork-point mode):\n>\n> \tgit rev-list --cherry-pick --right-only \\\n> \t\t$upstream...$orig_head ^$fork_point\n>\n> This allows us to correctly handle the scenario where we have the\n> following topology:\n>\n> \t    C --- D --- E  <- dev\n> \t   /\n> \t  B  <- master@{1}\n> \t /\n> \to --- B' --- C* --- D*  <- master\n>\n> where:\n> - B' is a fixed-up version of B that is not patch-identical with B;\n> - C* and D* are patch-identical to C and D respectively and conflict\n>   textually if applied in the wrong order;\n> - E depends textually on D.\n>\n> The correct result of `git rebase master dev` is that B is identified as\n> the fork-point of dev and master, so that C, D, E are the commits that\n> need to be replayed onto master; but C and D are patch-identical with C*\n> and D* and so can be dropped, so that the end result is:\n>\n> \to --- B' --- C* --- D* --- E  <- dev\n>\n> If the fork-point is not identified, then picking B onto a branch\n> containing B' results in a conflict and if the patch-identical commits\n> are not correctly identified then picking C onto a branch containing D\n> (or equivalently D*) results in a conflict.\n>\n> This change allows us to handle both of these cases, where previously we\n> either identified the fork-point (with `--fork-point`) but not the\n> patch-identical commits *or* (with `--no-fork-point`) identified the\n> patch-identical commits but not the fact that master had been rewritten.\n>\n> Reported-by: Ted Felix <ted@tedfelix.com>\n> Signed-off-by: John Keeping <john@keeping.me.uk>\n> ---\n>\n> Change from v1:\n>     - add a test case\n\n> diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh\n> index 80e0a95..47b5682 100755\n> --- a/t/t3400-rebase.sh\n> +++ b/t/t3400-rebase.sh\n> @@ -169,6 +169,29 @@ test_expect_success 'default to common base in @{upstream}s reflog if no upstrea\n>  \ttest_cmp expect actual\n>  '\n>  \n> +test_expect_success 'cherry-picked commits and fork-point work together' '\n> +\tgit checkout default-base &&\n> +\techo Amended >A &&\n> +\tgit commit -a --no-edit --amend &&\n> +\ttest_commit B B &&\n> +\ttest_commit new_B B \"New B\" &&\n> +\ttest_commit C C &&\n> +\tgit checkout default &&\n> +\tgit reset --hard default-base@{4} &&\n> +\ttest_commit D D &&\n> +\tgit cherry-pick -2 default-base^ &&\n> +\ttest_commit final_B B \"Final B\" &&\n> +\tgit rebase &&\n\nmental note: this rebases default (i.e. the current branch) on\ndefault-base; it depends on branch.default.{remote,merge} being set\nby the previous test piece.\n\n> +\techo Amended >expect &&\n> +\ttest_cmp A expect &&\n> +\techo \"Final B\" >expect &&\n> +\ttest_cmp B expect &&\n> +\techo C >expect &&\n> +\ttest_cmp C expect &&\n> +\techo D >expect &&\n> +\ttest_cmp D expect\n> +'\n\nThanks.  Do these labels on the commits have any relation to the\ntopology illustrated in the log message?\n\nIt looks like the above produces this:\n\n      a'---D---B'--new_B'---final_B (default)\n     /\n    o----a---B---new_B---C (default-base)\n                          \\\n                           D''---final_B''\n\nwhere 'a' is \"Modify A.\" from the original set-up and B and new_B\nare the cherry-picks to be filtered out during the rebase.  Am I\nreading the test correctly?\n\n>  test_expect_success 'rebase -q is quiet' '\n>  \tgit checkout -b quiet topic &&\n>  \tgit rebase -q master >output.out 2>&1 &&\n"},{"id":"246184","messageId":"20140716212755.GD2322@serenity.lan","threadId":"37050","inReplyTo":"xmqqa989rqx3.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH v2 2/2] rebase: omit patch-identical commits with --fork-point","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-07-16T21:27:55Z","receivedAt":"2014-07-16T21:27:55Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Jul 16, 2014 at 01:26:32PM -0700, Junio C Hamano wrote:\n> John Keeping <john@keeping.me.uk> writes:\n> \n> > When the `--fork-point` argument was added to `git rebase`, we changed\n> > the value of $upstream to be the fork point instead of the point from\n> > which we want to rebase.  When $orig_head..$upstream is empty this does\n> > not change the behaviour, but when there are new changes in the upstream\n> > we are no longer checking if any of them are patch-identical with\n> > changes in $upstream..$orig_head.\n> >\n> > Fix this by introducing a new variable to hold the fork point and using\n> > this to restrict the range as an extra (negative) revision argument so\n> > that the set of desired revisions becomes (in fork-point mode):\n> >\n> > \tgit rev-list --cherry-pick --right-only \\\n> > \t\t$upstream...$orig_head ^$fork_point\n> >\n> > This allows us to correctly handle the scenario where we have the\n> > following topology:\n> >\n> > \t    C --- D --- E  <- dev\n> > \t   /\n> > \t  B  <- master@{1}\n> > \t /\n> > \to --- B' --- C* --- D*  <- master\n> >\n> > where:\n> > - B' is a fixed-up version of B that is not patch-identical with B;\n> > - C* and D* are patch-identical to C and D respectively and conflict\n> >   textually if applied in the wrong order;\n> > - E depends textually on D.\n> >\n> > The correct result of `git rebase master dev` is that B is identified as\n> > the fork-point of dev and master, so that C, D, E are the commits that\n> > need to be replayed onto master; but C and D are patch-identical with C*\n> > and D* and so can be dropped, so that the end result is:\n> >\n> > \to --- B' --- C* --- D* --- E  <- dev\n> >\n> > If the fork-point is not identified, then picking B onto a branch\n> > containing B' results in a conflict and if the patch-identical commits\n> > are not correctly identified then picking C onto a branch containing D\n> > (or equivalently D*) results in a conflict.\n> >\n> > This change allows us to handle both of these cases, where previously we\n> > either identified the fork-point (with `--fork-point`) but not the\n> > patch-identical commits *or* (with `--no-fork-point`) identified the\n> > patch-identical commits but not the fact that master had been rewritten.\n> >\n> > Reported-by: Ted Felix <ted@tedfelix.com>\n> > Signed-off-by: John Keeping <john@keeping.me.uk>\n> > ---\n> >\n> > Change from v1:\n> >     - add a test case\n> \n> > diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh\n> > index 80e0a95..47b5682 100755\n> > --- a/t/t3400-rebase.sh\n> > +++ b/t/t3400-rebase.sh\n> > @@ -169,6 +169,29 @@ test_expect_success 'default to common base in @{upstream}s reflog if no upstrea\n> >  \ttest_cmp expect actual\n> >  '\n> >  \n> > +test_expect_success 'cherry-picked commits and fork-point work together' '\n> > +\tgit checkout default-base &&\n> > +\techo Amended >A &&\n> > +\tgit commit -a --no-edit --amend &&\n> > +\ttest_commit B B &&\n> > +\ttest_commit new_B B \"New B\" &&\n> > +\ttest_commit C C &&\n> > +\tgit checkout default &&\n> > +\tgit reset --hard default-base@{4} &&\n> > +\ttest_commit D D &&\n> > +\tgit cherry-pick -2 default-base^ &&\n> > +\ttest_commit final_B B \"Final B\" &&\n> > +\tgit rebase &&\n> \n> mental note: this rebases default (i.e. the current branch) on\n> default-base; it depends on branch.default.{remote,merge} being set\n> by the previous test piece.\n> \n> > +\techo Amended >expect &&\n> > +\ttest_cmp A expect &&\n> > +\techo \"Final B\" >expect &&\n> > +\ttest_cmp B expect &&\n> > +\techo C >expect &&\n> > +\ttest_cmp C expect &&\n> > +\techo D >expect &&\n> > +\ttest_cmp D expect\n> > +'\n> \n> Thanks.  Do these labels on the commits have any relation to the\n> topology illustrated in the log message?\n\nNo, I didn't consider the log message when adding the test; it simply\nuses the next letters that are unused in the test repository.\n\n> It looks like the above produces this:\n> \n>       a'---D---B'--new_B'---final_B (default)\n>      /\n>     o----a---B---new_B---C (default-base)\n>                           \\\n>                            D''---final_B''\n> \n> where 'a' is \"Modify A.\" from the original set-up and B and new_B\n> are the cherry-picks to be filtered out during the rebase.  Am I\n> reading the test correctly?\n\nYes, that's right.  The idea is to make sure that we skip the\ncherry-picked commits, which requires two commits that will conflict if\nwe try to apply the first on top of the second and to make sure that we\ndon't lose the new commit on the upstream (C).\n\n> >  test_expect_success 'rebase -q is quiet' '\n> >  \tgit checkout -b quiet topic &&\n> >  \tgit rebase -q master >output.out 2>&1 &&\n"},{"id":"246186","messageId":"53C6F043.7090209@tedfelix.com","threadId":"37050","inReplyTo":"374b26180807c67f7bd152ce5a2f52e34397e3a6.1405538598.git.john@keeping.me.uk","subject":"Re: [PATCH v2 2/2] rebase: omit patch-identical commits with --fork-point","fromName":"Ted Felix","fromEmail":"ted@tedfelix.com","sentAt":"2014-07-16T21:36:03Z","receivedAt":"2014-07-16T21:36:03Z","isPatch":true,"sender":{"key":"ted@tedfelix.com","avatar":"https://gravatar.com/avatar/222e94b6ee19381bf0badf8afb96d689cd523e84c4fb1676163c9ac2326f68e1?d=mp&s=160"},"body":"On 07/16/2014 03:23 PM, John Keeping wrote:\n> Change from v1:\n>      - add a test case\n\nTest case is working fine for me.  It passes with the patch and fails \nwithout.  However, it does seem to cause all the rest of the test cases \nto fail if it fails.  Is there some cleanup missing?\n\nTed.\n"},{"id":"246220","messageId":"20140717093622.GE2322@serenity.lan","threadId":"37050","inReplyTo":"53C6F043.7090209@tedfelix.com","subject":"Re: [PATCH v2 2/2] rebase: omit patch-identical commits with --fork-point","fromName":"John Keeping","fromEmail":"john@keeping.me.uk","sentAt":"2014-07-17T09:36:22Z","receivedAt":"2014-07-17T09:36:22Z","isPatch":true,"sender":{"key":"john@keeping.me.uk","avatar":"https://avatars.githubusercontent.com/u/1702081?v=4"},"body":"On Wed, Jul 16, 2014 at 05:36:03PM -0400, Ted Felix wrote:\n> On 07/16/2014 03:23 PM, John Keeping wrote:\n> > Change from v1:\n> >      - add a test case\n> \n> Test case is working fine for me.  It passes with the patch and fails \n> without.  However, it does seem to cause all the rest of the test cases \n> to fail if it fails.  Is there some cleanup missing?\n\nThe individual test cases in the script don't run in isolation, so I\ndon't think it's surprising the the remainder fail if this one ends up\nstuck in rebase-in-progress state.  I think the same will happen with\nmost of the other test cases in this script.\n"}]}