{"thread":{"id":"50810","subject":"[PATCH 0/3] rebase: learn --keep-base","startedAt":"2019-03-23T15:25:30Z","lastAt":"2019-08-27T08:11:12Z","messageCount":123,"participants":["Denton Liu","Eric Sunshine","Junio C Hamano","Johannes Schindelin","Ævar Arnfjörð Bjarmason","SZEDER Gábor","Johannes Sixt","Phillip Wood","Pratyush Yadav","Philip Oakley"],"isPatch":true,"patchVersion":1,"patchTotal":3},"messages":[{"id":"372306","messageId":"cover.1553354374.git.liu.denton@gmail.com","threadId":"50810","inReplyTo":null,"subject":"[PATCH 0/3] rebase: learn --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-23T15:25:22Z","receivedAt":"2019-03-23T15:25:30Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"This series teaches rebase the --keep-base option.\n\n'git rebase --keep-base ' is equivalent to\n'git rebase --onto ... ' or\n'git rebase --onto $(git merge-base HEAD) ' .\n\nThis seems to be a common case that people (including myself!) run into; I was\nable to find these StackOverflow posts about this use case:\n\n* https://stackoverflow.com/questions/53234798/can-i-rebase-on-a-branchs-fork-point-without-explicitly-specifying-the-parent\n* https://stackoverflow.com/questions/41529128/how-do-you-rebase-only-changes-between-two-branches-into-another-branch\n* https://stackoverflow.com/a/4207357\n\n\nDenton Liu (3):\n rebase: teach rebase --keep-base\n t3416: test rebase --keep-base\n git-rebase.txt: document --keep-base option\n\n Documentation/git-rebase.txt | 12 +++++--\n builtin/rebase.c | 25 ++++++++++++--\n t/t3416-rebase-onto-threedots.sh | 57 ++++++++++++++++++++++++++++++++\n 3 files changed, 88 insertions(+), 6 deletions(-)\n\n-- \n2.21.0.512.g57bf1b23e1\n\n"},{"id":"372307","messageId":"f802e5442013613221a4efd8ef1fecce0f3a9914.1553354374.git.liu.denton@gmail.com","threadId":"50810","inReplyTo":"cover.1553354374.git.liu.denton@gmail.com","subject":"[PATCH 1/3] rebase: teach rebase --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-23T15:25:28Z","receivedAt":"2019-03-23T15:25:37Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"A common scenario is if a user is working on a topic branch and they\nwish to make some changes to intermediate commits or autosquashing, they\nwould run something such as\n\n\tgit rebase -i --onto master... master\n\nin order to preserve the merge base. This prevents unnecessary commit\nchurning.\n\nAlternatively, a user wishing to test individual commits in a topic\nbranch without changing anything may run\n\n\tgit rebase -x ./test.sh master... master\n\nSince rebasing onto the merge base of the branch and the upstream is\nsuch a common case, introduce the --keep-base option as a shortcut.\n\nThis allows us to rewrite the above as\n\n\tgit rebase -i --keep-base master\n\nand\n\n\tgit rebase -x ./test.sh --keep-base master\n\nrespectively.\n\nSigned-off-by: Denton Liu \n---\n builtin/rebase.c | 25 ++++++++++++++++++++++---\n 1 file changed, 22 insertions(+), 3 deletions(-)\n\ndiff --git a/builtin/rebase.c b/builtin/rebase.c\nindex 77deebc65c..fffee89064 100644\n--- a/builtin/rebase.c\n+++ b/builtin/rebase.c\n@@ -27,8 +27,8 @@\n #include \"branch.h\"\n \n static char const * const builtin_rebase_usage[] = {\n-\tN_(\"git rebase [-i] [options] [--exec ] [--onto ] \"\n-\t\t\"[] []\"),\n+\tN_(\"git rebase [-i] [options] [--exec ] \"\n+\t\t\"[--onto | --keep-base] [ []]\"),\n \tN_(\"git rebase [-i] [options] [--exec ] [--onto ] \"\n \t\t\"--root []\"),\n \tN_(\"git rebase --continue | --abort | --skip | --edit-todo\"),\n@@ -1018,6 +1018,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)\n \t};\n \tconst char *branch_name;\n \tint ret, flags, total_argc, in_progress = 0;\n+\tint keep_base = 0;\n \tint ok_to_skip_pre_rebase = 0;\n \tstruct strbuf msg = STRBUF_INIT;\n \tstruct strbuf revisions = STRBUF_INIT;\n@@ -1051,6 +1052,8 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)\n \t\tOPT_STRING(0, \"onto\", &options.onto_name,\n \t\t\t N_(\"revision\"),\n \t\t\t N_(\"rebase onto given branch instead of upstream\")),\n+\t\tOPT_BOOL(0, \"keep-base\", &keep_base,\n+\t\t\t N_(\"use the merge-base of upstream and branch as the current base\")),\n \t\tOPT_BOOL(0, \"no-verify\", &ok_to_skip_pre_rebase,\n \t\t\t N_(\"allow pre-rebase hook to run\")),\n \t\tOPT_NEGBIT('q', \"quiet\", &options.flags,\n@@ -1217,6 +1220,13 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)\n \t\tusage_with_options(builtin_rebase_usage,\n \t\t\t\t builtin_rebase_options);\n \n+\tif (keep_base) {\n+\t\tif (options.onto_name)\n+\t\t\tdie(_(\"cannot combine '--keep-base' with '--onto'\"));\n+\t\tif (options.root)\n+\t\t\tdie(_(\"cannot combine '--keep-base' with '--root'\"));\n+\t}\n+\n \tif (action != NO_ACTION && !in_progress)\n \t\tdie(_(\"No rebase in progress?\"));\n \tsetenv(GIT_REFLOG_ACTION_ENVIRONMENT, \"rebase\", 0);\n@@ -1541,10 +1551,19 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)\n \t}\n \n \t/* Make sure the branch to rebase onto is valid. */\n-\tif (!options.onto_name)\n+\tif (keep_base) {\n+\t strbuf_reset(&buf);\n+\t strbuf_addstr(&buf, options.upstream_name);\n+\t strbuf_addstr(&buf, \"...\");\n+\t options.onto_name = xstrdup(buf.buf);\n+\t} else if (!options.onto_name)\n \t\toptions.onto_name = options.upstream_name;\n \tif (strstr(options.onto_name, \"...\")) {\n \t\tif (get_oid_mb(options.onto_name, &merge_base) < 0)\n+\t\t if (keep_base)\n+\t\t\tdie(_(\"'%s': need exactly one merge base with branch\"),\n+\t\t\t\toptions.upstream_name);\n+\t\t else\n \t\t\tdie(_(\"'%s': need exactly one merge base\"),\n \t\t\t options.onto_name);\n \t\toptions.onto = lookup_commit_or_die(&merge_base,\n-- \n2.21.0.512.g57bf1b23e1\n\n"},{"id":"372308","messageId":"6398944a6f9e696a6f6f7d616447160af93b0639.1553354374.git.liu.denton@gmail.com","threadId":"50810","inReplyTo":"cover.1553354374.git.liu.denton@gmail.com","subject":"[PATCH 2/3] t3416: test rebase --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-23T15:25:36Z","receivedAt":"2019-03-23T15:25:45Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Test rebase --keep-base to ensure it works correctly in the normal case\nand fails when there are multiple merge-bases, both in regular and\ninteractive mode. Also, test to make sure conflicting options causes\nrebase to fail.\n\nWhile we're at it, add a missing set_fake_editor call to\n'rebase -i --onto master...side'.\n\nSigned-off-by: Denton Liu \n---\n t/t3416-rebase-onto-threedots.sh | 57 ++++++++++++++++++++++++++++++++\n 1 file changed, 57 insertions(+)\n\ndiff --git a/t/t3416-rebase-onto-threedots.sh b/t/t3416-rebase-onto-threedots.sh\nindex ddf2f64853..9c2548423b 100755\n--- a/t/t3416-rebase-onto-threedots.sh\n+++ b/t/t3416-rebase-onto-threedots.sh\n@@ -99,7 +99,64 @@ test_expect_success 'rebase -i --onto master...side' '\n \tgit checkout side &&\n \tgit reset --hard K &&\n \n+\tset_fake_editor &&\n \ttest_must_fail git rebase -i --onto master...side J\n '\n \n+test_expect_success 'rebase --keep-base --onto incompatible' '\n+\ttest_must_fail git rebase --keep-base --onto master...\n+'\n+\n+test_expect_success 'rebase --keep-base --root incompatible' '\n+\ttest_must_fail git rebase --keep-base --root\n+'\n+\n+test_expect_success 'rebase --keep-base master from topic' '\n+\tgit reset --hard &&\n+\tgit checkout topic &&\n+\tgit reset --hard G &&\n+\n+\tgit rebase --keep-base master &&\n+\tgit rev-parse C >base.expect &&\n+\tgit merge-base master HEAD >base.actual &&\n+\ttest_cmp base.expect base.actual &&\n+\n+\tgit rev-parse HEAD~2 >actual &&\n+\tgit rev-parse C^0 >expect &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rebase --keep-base master from side' '\n+\tgit reset --hard &&\n+\tgit checkout side &&\n+\tgit reset --hard K &&\n+\n+\ttest_must_fail git rebase --keep-base master\n+'\n+\n+test_expect_success 'rebase -i --keep-base master from topic' '\n+\tgit reset --hard &&\n+\tgit checkout topic &&\n+\tgit reset --hard G &&\n+\n+\tset_fake_editor &&\n+\tEXPECT_COUNT=2 git rebase -i --keep-base master &&\n+\tgit rev-parse C >base.expect &&\n+\tgit merge-base master HEAD >base.actual &&\n+\ttest_cmp base.expect base.actual &&\n+\n+\tgit rev-parse HEAD~2 >actual &&\n+\tgit rev-parse C^0 >expect &&\n+\ttest_cmp expect actual\n+'\n+\n+test_expect_success 'rebase -i --keep-base master from side' '\n+\tgit reset --hard &&\n+\tgit checkout side &&\n+\tgit reset --hard K &&\n+\n+\tset_fake_editor &&\n+\ttest_must_fail git rebase -i --keep-base master\n+'\n+\n test_done\n-- \n2.21.0.512.g57bf1b23e1\n\n"},{"id":"372309","messageId":"8896a65c2cecfc84c494545e47c918a45cd63602.1553354374.git.liu.denton@gmail.com","threadId":"50810","inReplyTo":"cover.1553354374.git.liu.denton@gmail.com","subject":"[PATCH 3/3] git-rebase.txt: document --keep-base option","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-23T15:25:43Z","receivedAt":"2019-03-23T15:25:52Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Document the --keep-base rebase option.\n\nWhile we're at it, change an instance of \"merge-base\" to \"merge base\",\nwhich is the consistent spelling.\n\nSigned-off-by: Denton Liu \n---\n Documentation/git-rebase.txt | 12 +++++++++---\n 1 file changed, 9 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 6363d674b7..780d381667 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -8,8 +8,8 @@ git-rebase - Reapply commits on top of another base tip\n SYNOPSIS\n --------\n [verse]\n-'git rebase' [-i | --interactive] [] [--exec ] [--onto ]\n-\t[ []]\n+'git rebase' [-i | --interactive] [] [--exec ]\n+\t[--onto | --keep-base] [ []]\n 'git rebase' [-i | --interactive] [] [--exec ] [--onto ]\n \t--root []\n 'git rebase' --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch\n@@ -217,6 +217,12 @@ As a special case, you may use \"A\\...B\" as a shortcut for the\n merge base of A and B if there is exactly one merge base. You can\n leave out at most one of A and B, in which case it defaults to HEAD.\n \n+--keep-base::\n+\tSet the starting point at which to create the new commits to the\n+\tmerge base of . Running\n+\t'git rebase --keep-base ' is equivalent to\n+\trunning 'git rebase --onto ... '.\n+\n ::\n \tUpstream branch to compare against. May be any valid commit,\n \tnot just an existing branch name. Defaults to the configured\n@@ -863,7 +869,7 @@ NOTE: While an \"easy case recovery\" sometimes appears to be successful\n --interactive` will be **resurrected**!\n \n The idea is to manually tell 'git rebase' \"where the old 'subsystem'\n-ended and your 'topic' began\", that is, what the old merge-base\n+ended and your 'topic' began\", that is, what the old merge base\n between them was. You will have to find a way to name the last commit\n of the old 'subsystem', for example:\n \n-- \n2.21.0.512.g57bf1b23e1\n\n"},{"id":"372321","messageId":"CAPig+cT=jW0w==1ipD4Pem6Y+7orSH5q39j0rBhF87C8AT6Zjg@mail.gmail.com","threadId":"50810","inReplyTo":"f802e5442013613221a4efd8ef1fecce0f3a9914.1553354374.git.liu.denton@gmail.com","subject":"Re: [PATCH 1/3] rebase: teach rebase --keep-base","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2019-03-24T03:46:09Z","receivedAt":"2019-03-24T03:46:21Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sat, Mar 23, 2019 at 11:25 AM Denton Liu wrote:>\n> [...]\n> Since rebasing onto the merge base of the branch and the upstream is\n> such a common case, introduce the --keep-base option as a shortcut.\n> [...]\n> Signed-off-by: Denton Liu \n> ---\n> diff --git a/builtin/rebase.c b/builtin/rebase.c\n> @@ -1541,10 +1551,19 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)\n> /* Make sure the branch to rebase onto is valid. */\n> - if (!options.onto_name)\n> + if (keep_base) {\n> + strbuf_reset(&buf);\n> + strbuf_addstr(&buf, options.upstream_name);\n> + strbuf_addstr(&buf, \"...\");\n> + options.onto_name = xstrdup(buf.buf);\n> + } else if (!options.onto_name)\n> options.onto_name = options.upstream_name;\n> if (strstr(options.onto_name, \"...\")) {\n> if (get_oid_mb(options.onto_name, &merge_base) < 0)\n> + if (keep_base)\n> + die(_(\"'%s': need exactly one merge base with branch\"),\n> + options.upstream_name);\n> + else\n\nStyle: Indent with tabs, not spaces.\n"},{"id":"372362","messageId":"xmqqy354o1l8.fsf@gitster-ct.c.googlers.com","threadId":"50810","inReplyTo":"cover.1553354374.git.liu.denton@gmail.com","subject":"Re: [PATCH 0/3] rebase: learn --keep-base","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-24T13:15:31Z","receivedAt":"2019-03-24T13:15:37Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Denton Liu writes:\n\n> This series teaches rebase the --keep-base option.\n>\n> 'git rebase --keep-base ' is equivalent to\n> 'git rebase --onto ... ' or\n> 'git rebase --onto $(git merge-base HEAD) ' .\n>\n> This seems to be a common case that people (including myself!) run\n> into; I was able to find these StackOverflow posts about this use\n> case:\n\nSince this is 0/3 I won't complain too loudly, but read the above\nagain while pretending that you didn't know what your initial\nmotivating example was. The last three lines does not explain\nanything useful to such a reader, and the reader needs to decipher\nthe two sample commands to guess what you wanted to achieve.\n\nBefore \"teaches rebase the --keep-base option\", you must tell what\nyou wanted to do with that new feature to attract readers---convince\nthem your new contribution is worth their time to read over.\n\nIf I understand correctly, what \"--onto $(git merge-base @{u} HEAD) @{u}\"\nlets you express is:\n\n\tno matter how much progress the upstream has made while I\n\twas away from the keyboard, I want to rebase the current\n\ttopic on top of the same commit from the upstream, on which\n\tI based the current iteration of the topic.\n\nI suspect that such a rebase will become no-op without \"-i\". Am I\nmistaken? I am not sure if \"--keep-base\" is useful without \"-i\".\n\nBut of course, it would be useful with \"-i\", i.e. when you want to\nfurther polish the topic. You need to give to the command\nto let it know where their work stops and your work begins,\ni.e. letting the command figure out what commits to replay. But in\nsuch a workflow, you do not want to affect on top of what\ncommit the replayed history is built. And \"keep base\" would be a\nvery direct way to achieve that.\n\n\n\n"},{"id":"372364","messageId":"xmqqtvfso1cz.fsf@gitster-ct.c.googlers.com","threadId":"50810","inReplyTo":"f802e5442013613221a4efd8ef1fecce0f3a9914.1553354374.git.liu.denton@gmail.com","subject":"Re: [PATCH 1/3] rebase: teach rebase --keep-base","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-24T13:20:28Z","receivedAt":"2019-03-24T13:20:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Denton Liu writes:\n\n> A common scenario is if a user is working on a topic branch and they\n> wish to make some changes to intermediate commits or autosquashing, they\n> would run something such as\n>\n> \tgit rebase -i --onto master... master\n>\n> in order to preserve the merge base. This prevents unnecessary commit\n> churning.\n>\n> Alternatively, a user wishing to test individual commits in a topic\n> branch without changing anything may run\n>\n> \tgit rebase -x ./test.sh master... master\n>\n> Since rebasing onto the merge base of the branch and the upstream is\n> such a common case, introduce the --keep-base option as a shortcut.\n>\n> This allows us to rewrite the above as\n>\n> \tgit rebase -i --keep-base master\n>\n> and\n>\n> \tgit rebase -x ./test.sh --keep-base master\n>\n> respectively.\n\nI never use the \"feature\" myself, but I recall that when \"git\nrebase\" is run on a branch appropriately prepared, you do not even\nhave to say (iow, you type \"git rebase\" and rebase\non top of @{upstream}). \n\nCan this new \"--keep-base\" feature mesh well with it? When the\ncurrent branch has forked from origin/master, for example, it would\nbe good if\n\n\t$ git rebase -i --same-base\n\nbecomes a usable short-hand for\n\n\t$ git rebase -i --same-base origin/master\n\naka\n\n\t$ git rebase -i --onto $(git merge-base HEAD origin/master) origin/master\n\n"},{"id":"372365","messageId":"xmqqpnqgo0k2.fsf@gitster-ct.c.googlers.com","threadId":"50810","inReplyTo":"f802e5442013613221a4efd8ef1fecce0f3a9914.1553354374.git.liu.denton@gmail.com","subject":"Re: [PATCH 1/3] rebase: teach rebase --keep-base","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-03-24T13:37:49Z","receivedAt":"2019-03-24T13:37:53Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Denton Liu writes:\n\n> \tif (strstr(options.onto_name, \"...\")) {\n> \t\tif (get_oid_mb(options.onto_name, &merge_base) < 0)\n> +\t\t if (keep_base)\n> +\t\t\tdie(_(\"'%s': need exactly one merge base with branch\"),\n> +\t\t\t\toptions.upstream_name);\n> +\t\t else\n> \t\t\tdie(_(\"'%s': need exactly one merge base\"),\n> \t\t\t options.onto_name);\n\nIf you turn a single statement body into if/else, have {} around the\nbody of the outer if, i.e.\n\n\tif (get_oid_mb(...) < 0) {\n\t\tif (keep_base)\n\t\t\tdie(_(\"'%s': need exactly one merge base with branch\"),\n\t\t\t options.upstream_name);\n\t\telse\n\t\t\tdie(_(\"'%s': need exactly one merge base\"),\n\t\t\t options.onto_name);\n\t}\n\nOtherwise -Werror=danglng-else will stop compilation.\n\nThanks.\n"},{"id":"372388","messageId":"20190325000427.GA9384@archbookpro.localdomain","threadId":"50810","inReplyTo":"xmqqy354o1l8.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 0/3] rebase: learn --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-25T00:04:27Z","receivedAt":"2019-03-25T00:04:32Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi Junio,\n\nOn Sun, Mar 24, 2019 at 10:15:31PM +0900, Junio C Hamano wrote:\n> Denton Liu writes:\n> \n> > This series teaches rebase the --keep-base option.\n> >\n> > 'git rebase --keep-base ' is equivalent to\n> > 'git rebase --onto ... ' or\n> > 'git rebase --onto $(git merge-base HEAD) ' .\n> >\n> > This seems to be a common case that people (including myself!) run\n> > into; I was able to find these StackOverflow posts about this use\n> > case:\n> \n> Since this is 0/3 I won't complain too loudly, but read the above\n> again while pretending that you didn't know what your initial\n> motivating example was. The last three lines does not explain\n> anything useful to such a reader, and the reader needs to decipher\n> the two sample commands to guess what you wanted to achieve.\n> \n> Before \"teaches rebase the --keep-base option\", you must tell what\n> you wanted to do with that new feature to attract readers---convince\n> them your new contribution is worth their time to read over.\n> \n> If I understand correctly, what \"--onto $(git merge-base @{u} HEAD) @{u}\"\n> lets you express is:\n> \n> \tno matter how much progress the upstream has made while I\n> \twas away from the keyboard, I want to rebase the current\n> \ttopic on top of the same commit from the upstream, on which\n> \tI based the current iteration of the topic.\n\nThanks for the clarification. I'll try my best to write future cover\nletters more clearly.\n\n> \n> I suspect that such a rebase will become no-op without \"-i\". Am I\n> mistaken? I am not sure if \"--keep-base\" is useful without \"-i\".\n\nIt's useful in the case of \"-x\", although that is a grey area since \"-x\"\nuses interactive machinery internally. Aside from \"-x\", I can't really\nthink of a situation where we would use \"--keep-base\" without \"-i\".\n\n> \n> But of course, it would be useful with \"-i\", i.e. when you want to\n> further polish the topic. You need to give to the command\n> to let it know where their work stops and your work begins,\n> i.e. letting the command figure out what commits to replay. But in\n> such a workflow, you do not want to affect on top of what\n> commit the replayed history is built. And \"keep base\" would be a\n> very direct way to achieve that.\n> \n> \n> \n\nThanks,\n\nDenton\n"},{"id":"372389","messageId":"20190325000618.GB9384@archbookpro.localdomain","threadId":"50810","inReplyTo":"xmqqtvfso1cz.fsf@gitster-ct.c.googlers.com","subject":"Re: [PATCH 1/3] rebase: teach rebase --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-25T00:06:18Z","receivedAt":"2019-03-25T00:06:22Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi Junio,\n\nOn Sun, Mar 24, 2019 at 10:20:28PM +0900, Junio C Hamano wrote:\n> Denton Liu writes:\n> \n> > A common scenario is if a user is working on a topic branch and they\n> > wish to make some changes to intermediate commits or autosquashing, they\n> > would run something such as\n> >\n> > \tgit rebase -i --onto master... master\n> >\n> > in order to preserve the merge base. This prevents unnecessary commit\n> > churning.\n> >\n> > Alternatively, a user wishing to test individual commits in a topic\n> > branch without changing anything may run\n> >\n> > \tgit rebase -x ./test.sh master... master\n> >\n> > Since rebasing onto the merge base of the branch and the upstream is\n> > such a common case, introduce the --keep-base option as a shortcut.\n> >\n> > This allows us to rewrite the above as\n> >\n> > \tgit rebase -i --keep-base master\n> >\n> > and\n> >\n> > \tgit rebase -x ./test.sh --keep-base master\n> >\n> > respectively.\n> \n> I never use the \"feature\" myself, but I recall that when \"git\n> rebase\" is run on a branch appropriately prepared, you do not even\n> have to say (iow, you type \"git rebase\" and rebase\n> on top of @{upstream}). \n> \n> Can this new \"--keep-base\" feature mesh well with it? When the\n> current branch has forked from origin/master, for example, it would\n> be good if\n> \n> \t$ git rebase -i --same-base\n> \n> becomes a usable short-hand for\n> \n> \t$ git rebase -i --same-base origin/master\n\nBy \"--same-base\", I am assuming you mistyped and meant to write\n\"--keep-base\"? If that's the case, I can make it a shorthand.\n\nThanks,\n\nDenton\n\n> \n> aka\n> \n> \t$ git rebase -i --onto $(git merge-base HEAD origin/master) origin/master\n> \n"},{"id":"372397","messageId":"20190325054145.GA1652@archbookpro.localdomain","threadId":"50810","inReplyTo":"20190325000618.GB9384@archbookpro.localdomain","subject":"Re: [PATCH 1/3] rebase: teach rebase --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-25T05:41:45Z","receivedAt":"2019-03-25T05:41:50Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"On Sun, Mar 24, 2019 at 05:06:18PM -0700, Denton Liu wrote:\n> Hi Junio,\n> \n> On Sun, Mar 24, 2019 at 10:20:28PM +0900, Junio C Hamano wrote:\n> > Denton Liu writes:\n> > \n> > > A common scenario is if a user is working on a topic branch and they\n> > > wish to make some changes to intermediate commits or autosquashing, they\n> > > would run something such as\n> > >\n> > > \tgit rebase -i --onto master... master\n> > >\n> > > in order to preserve the merge base. This prevents unnecessary commit\n> > > churning.\n> > >\n> > > Alternatively, a user wishing to test individual commits in a topic\n> > > branch without changing anything may run\n> > >\n> > > \tgit rebase -x ./test.sh master... master\n> > >\n> > > Since rebasing onto the merge base of the branch and the upstream is\n> > > such a common case, introduce the --keep-base option as a shortcut.\n> > >\n> > > This allows us to rewrite the above as\n> > >\n> > > \tgit rebase -i --keep-base master\n> > >\n> > > and\n> > >\n> > > \tgit rebase -x ./test.sh --keep-base master\n> > >\n> > > respectively.\n> > \n> > I never use the \"feature\" myself, but I recall that when \"git\n> > rebase\" is run on a branch appropriately prepared, you do not even\n> > have to say (iow, you type \"git rebase\" and rebase\n> > on top of @{upstream}). \n> > \n> > Can this new \"--keep-base\" feature mesh well with it? When the\n> > current branch has forked from origin/master, for example, it would\n> > be good if\n> > \n> > \t$ git rebase -i --same-base\n> > \n> > becomes a usable short-hand for\n> > \n> > \t$ git rebase -i --same-base origin/master\n> \n> By \"--same-base\", I am assuming you mistyped and meant to write\n> \"--keep-base\"? If that's the case, I can make it a shorthand.\n\nSorry, I misunderstood your question. \"--keep-base\" already has the\nshorthand case handled by default.\n\nOne caveat is that \"--fork-point\" is automatically implied if no\nupstream is supplied but this behaviour is the same for \"--onto\" or when\nno other options are supplied as well.\n\nI don't use the feature either so I'm not really sure if this behaviour\nwould be the most sane thing to do.\n\n> Thanks,\n> \n> Denton\n> \n> > \n> > aka\n> > \n> > \t$ git rebase -i --onto $(git merge-base HEAD origin/master) origin/master\n> > \n"},{"id":"372398","messageId":"20190325054730.GB1652@archbookpro.localdomain","threadId":"50810","inReplyTo":"f802e5442013613221a4efd8ef1fecce0f3a9914.1553354374.git.liu.denton@gmail.com","subject":"Re: [PATCH 1/3] rebase: teach rebase --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-25T05:47:30Z","receivedAt":"2019-03-25T05:47:37Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"On Sat, Mar 23, 2019 at 08:25:28AM -0700, Denton Liu wrote:\n> A common scenario is if a user is working on a topic branch and they\n> wish to make some changes to intermediate commits or autosquashing, they\n\nSorry, small typo here:\n\ns/autosquashing/autosquash/\n\n-Denton\n\n> would run something such as\n> \n> \tgit rebase -i --onto master... master\n> \n> in order to preserve the merge base. This prevents unnecessary commit\n> churning.\n> \n> Alternatively, a user wishing to test individual commits in a topic\n> branch without changing anything may run\n> \n> \tgit rebase -x ./test.sh master... master\n> \n> Since rebasing onto the merge base of the branch and the upstream is\n> such a common case, introduce the --keep-base option as a shortcut.\n> \n> This allows us to rewrite the above as\n> \n> \tgit rebase -i --keep-base master\n> \n> and\n> \n> \tgit rebase -x ./test.sh --keep-base master\n> \n> respectively.\n> \n> Signed-off-by: Denton Liu \n> ---\n> builtin/rebase.c | 25 ++++++++++++++++++++++---\n> 1 file changed, 22 insertions(+), 3 deletions(-)\n> \n> diff --git a/builtin/rebase.c b/builtin/rebase.c\n> index 77deebc65c..fffee89064 100644\n> --- a/builtin/rebase.c\n> +++ b/builtin/rebase.c\n> @@ -27,8 +27,8 @@\n> #include \"branch.h\"\n> \n> static char const * const builtin_rebase_usage[] = {\n> -\tN_(\"git rebase [-i] [options] [--exec ] [--onto ] \"\n> -\t\t\"[] []\"),\n> +\tN_(\"git rebase [-i] [options] [--exec ] \"\n> +\t\t\"[--onto | --keep-base] [ []]\"),\n> \tN_(\"git rebase [-i] [options] [--exec ] [--onto ] \"\n> \t\t\"--root []\"),\n> \tN_(\"git rebase --continue | --abort | --skip | --edit-todo\"),\n> @@ -1018,6 +1018,7 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)\n> \t};\n> \tconst char *branch_name;\n> \tint ret, flags, total_argc, in_progress = 0;\n> +\tint keep_base = 0;\n> \tint ok_to_skip_pre_rebase = 0;\n> \tstruct strbuf msg = STRBUF_INIT;\n> \tstruct strbuf revisions = STRBUF_INIT;\n> @@ -1051,6 +1052,8 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)\n> \t\tOPT_STRING(0, \"onto\", &options.onto_name,\n> \t\t\t N_(\"revision\"),\n> \t\t\t N_(\"rebase onto given branch instead of upstream\")),\n> +\t\tOPT_BOOL(0, \"keep-base\", &keep_base,\n> +\t\t\t N_(\"use the merge-base of upstream and branch as the current base\")),\n> \t\tOPT_BOOL(0, \"no-verify\", &ok_to_skip_pre_rebase,\n> \t\t\t N_(\"allow pre-rebase hook to run\")),\n> \t\tOPT_NEGBIT('q', \"quiet\", &options.flags,\n> @@ -1217,6 +1220,13 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)\n> \t\tusage_with_options(builtin_rebase_usage,\n> \t\t\t\t builtin_rebase_options);\n> \n> +\tif (keep_base) {\n> +\t\tif (options.onto_name)\n> +\t\t\tdie(_(\"cannot combine '--keep-base' with '--onto'\"));\n> +\t\tif (options.root)\n> +\t\t\tdie(_(\"cannot combine '--keep-base' with '--root'\"));\n> +\t}\n> +\n> \tif (action != NO_ACTION && !in_progress)\n> \t\tdie(_(\"No rebase in progress?\"));\n> \tsetenv(GIT_REFLOG_ACTION_ENVIRONMENT, \"rebase\", 0);\n> @@ -1541,10 +1551,19 @@ int cmd_rebase(int argc, const char **argv, const char *prefix)\n> \t}\n> \n> \t/* Make sure the branch to rebase onto is valid. */\n> -\tif (!options.onto_name)\n> +\tif (keep_base) {\n> +\t strbuf_reset(&buf);\n> +\t strbuf_addstr(&buf, options.upstream_name);\n> +\t strbuf_addstr(&buf, \"...\");\n> +\t options.onto_name = xstrdup(buf.buf);\n> +\t} else if (!options.onto_name)\n> \t\toptions.onto_name = options.upstream_name;\n> \tif (strstr(options.onto_name, \"...\")) {\n> \t\tif (get_oid_mb(options.onto_name, &merge_base) < 0)\n> +\t\t if (keep_base)\n> +\t\t\tdie(_(\"'%s': need exactly one merge base with branch\"),\n> +\t\t\t\toptions.upstream_name);\n> +\t\t else\n> \t\t\tdie(_(\"'%s': need exactly one merge base\"),\n> \t\t\t options.onto_name);\n> \t\toptions.onto = lookup_commit_or_die(&merge_base,\n> -- \n> 2.21.0.512.g57bf1b23e1\n> \n"},{"id":"372455","messageId":"nycvar.QRO.7.76.6.1903251948200.41@tvgsbejvaqbjf.bet","threadId":"50810","inReplyTo":"f802e5442013613221a4efd8ef1fecce0f3a9914.1553354374.git.liu.denton@gmail.com","subject":"Re: [PATCH 1/3] rebase: teach rebase --keep-base","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-25T18:50:38Z","receivedAt":"2019-03-25T18:50:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Denton,\n\nOn Sat, 23 Mar 2019, Denton Liu wrote:\n\n> [...]\n>\n> This allows us to rewrite the above as\n>\n> \tgit rebase -i --keep-base master\n>\n> and\n>\n> \tgit rebase -x ./test.sh --keep-base master\n>\n> respectively.\n\nJust a quick note: this breaks t5407 because that test uses `git rebase\n--keep` and expects that abbreviated option to be expanded to\n`--keep-empty`, which is now no longer the only possible expansion.\n\nI just submitted a patch series to fix that, and other uses of abbreviated\noptions in the test suite, in\nhttps://public-inbox.org/git/pull.167.git.gitgitgadget@gmail.com/T/#t\n\nCiao,\nJohannes\n\nP.S.: Did you run the test suite before submitting your patches?\n"},{"id":"372460","messageId":"20190325192928.GA31067@dev-l","threadId":"50810","inReplyTo":"nycvar.QRO.7.76.6.1903251948200.41@tvgsbejvaqbjf.bet","subject":"Re: [PATCH 1/3] rebase: teach rebase --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-25T19:29:28Z","receivedAt":"2019-03-25T19:29:32Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi Johannes,\n\nOn Mon, Mar 25, 2019 at 07:50:38PM +0100, Johannes Schindelin wrote:\n> Hi Denton,\n> \n> On Sat, 23 Mar 2019, Denton Liu wrote:\n> \n> > [...]\n> >\n> > This allows us to rewrite the above as\n> >\n> > \tgit rebase -i --keep-base master\n> >\n> > and\n> >\n> > \tgit rebase -x ./test.sh --keep-base master\n> >\n> > respectively.\n> \n> Just a quick note: this breaks t5407 because that test uses `git rebase\n> --keep` and expects that abbreviated option to be expanded to\n> `--keep-empty`, which is now no longer the only possible expansion.\n> \n> I just submitted a patch series to fix that, and other uses of abbreviated\n> options in the test suite, in\n> https://public-inbox.org/git/pull.167.git.gitgitgadget@gmail.com/T/#t\n\nThanks for catching this. I replied with a (tiny) review.\n\n> \n> Ciao,\n> Johannes\n> \n> P.S.: Did you run the test suite before submitting your patches?\n\nUsually I'm more diligent about running tests but I wrote this patchset\nin the back of a car when I was running low on batteries. I only ran the\nrebase-related tests but I guess that wasn't enough.\n\nMy mistake, though. I'll be sure to _always_ run tests in the future.\n\nThanks,\n\nDenton\n"},{"id":"372516","messageId":"nycvar.QRO.7.76.6.1903261424270.41@tvgsbejvaqbjf.bet","threadId":"50810","inReplyTo":"20190325192928.GA31067@dev-l","subject":"Re: [PATCH 1/3] rebase: teach rebase --keep-base","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2019-03-26T13:27:47Z","receivedAt":"2019-03-26T13:28:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Denton,\n\nOn Mon, 25 Mar 2019, Denton Liu wrote:\n\n> On Mon, Mar 25, 2019 at 07:50:38PM +0100, Johannes Schindelin wrote:\n>\n> > P.S.: Did you run the test suite before submitting your patches?\n>\n> Usually I'm more diligent about running tests but I wrote this patchset\n> in the back of a car when I was running low on batteries. I only ran the\n> rebase-related tests but I guess that wasn't enough.\n\nI totally understand that kind of scenario.\n\n> My mistake, though. I'll be sure to _always_ run tests in the future.\n\nPlease do not feel bad. I did work pretty hard on making the Azure\nPipelines support as fast as it is for the very purpose of helping exactly\nsituations like yours: to hand off the testing to the cloud when batteries\nrun low (or when you want to use your laptop for something else than\nrunning Git's test suite).\n\nAnd of course to verify that you don't break things on platforms other\nthan the one you happen to develop on. And to check the documentation. And\nto run some static analyses.\n\n:-)\n\nMaybe you want to open PRs at https://github.com/git/git or at\nhttps://github.com/gitgitgadget/git to benefit from that kind of automatic\ntesting, benefitting from my work (which would make me feel real good\nabout spending that amount of time on it).\n\nCiao,\nJohannes\n"},{"id":"372519","messageId":"87bm1xbt55.fsf@evledraar.gmail.com","threadId":"50810","inReplyTo":"cover.1553354374.git.liu.denton@gmail.com","subject":"Re: [PATCH 0/3] rebase: learn --keep-base","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-03-26T14:35:34Z","receivedAt":"2019-03-26T14:35:40Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Sat, Mar 23 2019, Denton Liu wrote:\n\n> This series teaches rebase the --keep-base option.\n>\n> 'git rebase --keep-base ' is equivalent to\n> 'git rebase --onto ... ' or\n> 'git rebase --onto $(git merge-base HEAD) ' .\n>\n> This seems to be a common case that people (including myself!) run into; I was\n> able to find these StackOverflow posts about this use case:\n>\n> * https://stackoverflow.com/questions/53234798/can-i-rebase-on-a-branchs-fork-point-without-explicitly-specifying-the-parent\n> * https://stackoverflow.com/questions/41529128/how-do-you-rebase-only-changes-between-two-branches-into-another-branch\n> * https://stackoverflow.com/a/4207357\n\nLike with another series of yours I think this would be best squashed\ninto one patch.\n\nMaybe I've misunderstood this but isn't this like --fork-point except\nwith just plain \"git merge-base\" instead of \"git merge-base\n--fork-point\", but then again 2/3 shows multiple base aren't supported,\nbut merge-base supports that.\n\nI'd find something like the \"DISCUSSION ON FORK-POINT MODE\" in\ngit-merge-base helpful with examples of what we'd pick in the various\nscenarios, and also if whatever commit this picks was something you\ncould have \"git merge-base\" spew out, so you could get what rebase would\ndo here from other tooling (which maybe is possible, but I'm confused by\nthe \"no multiple bases\"...).\n"},{"id":"372533","messageId":"20190326175052.GA14922@dev-l","threadId":"50810","inReplyTo":"87bm1xbt55.fsf@evledraar.gmail.com","subject":"Re: [PATCH 0/3] rebase: learn --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-26T17:50:52Z","receivedAt":"2019-03-26T17:50:58Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi Ævar,\n\nOn Tue, Mar 26, 2019 at 03:35:34PM +0100, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Sat, Mar 23 2019, Denton Liu wrote:\n> \n> > This series teaches rebase the --keep-base option.\n> >\n> > 'git rebase --keep-base ' is equivalent to\n> > 'git rebase --onto ... ' or\n> > 'git rebase --onto $(git merge-base HEAD) ' .\n> >\n> > This seems to be a common case that people (including myself!) run into; I was\n> > able to find these StackOverflow posts about this use case:\n> >\n> > * https://stackoverflow.com/questions/53234798/can-i-rebase-on-a-branchs-fork-point-without-explicitly-specifying-the-parent\n> > * https://stackoverflow.com/questions/41529128/how-do-you-rebase-only-changes-between-two-branches-into-another-branch\n> > * https://stackoverflow.com/a/4207357\n> \n> Like with another series of yours I think this would be best squashed\n> into one patch.\n\nWill do.\n\n> \n> Maybe I've misunderstood this but isn't this like --fork-point except\n> with just plain \"git merge-base\" instead of \"git merge-base\n> --fork-point\", but then again 2/3 shows multiple base aren't supported,\n> but merge-base supports that.\n> \n\n--fork-point gets used to determine the _set of_ commits which are to be\nrebased, whereas --keep-base (and --onto) determine the base where that\nset of commits will be spliced. As a result, these two options cover\northogonal use-cases.\n\nThe reason why --keep-base doesn't support multiple bases for the same\nreason that --onto already disallows multiple bases. If we have multiple\nbases, how do we determine which one is the \"true base\" to use? It makes\nmore sense to error out and let the user manually specify it.\n\n> I'd find something like the \"DISCUSSION ON FORK-POINT MODE\" in\n> git-merge-base helpful with examples of what we'd pick in the various\n> scenarios, and also if whatever commit this picks was something you\n> could have \"git merge-base\" spew out, so you could get what rebase would\n> do here from other tooling (which maybe is possible, but I'm confused by\n> the \"no multiple bases\"...).\n\nIf I'm understanding you correctly then yes, this could be done with\nother tooling. See the 0/3 for equivalent commands.\n\nPerhaps I should update the rebase documentation to mention that\n--fork-point and --keep-base are orthogonal because it's unclear for\nyou, it's probably unclear for other users as well.\n\nThanks,\n\nDenton\n"},{"id":"372547","messageId":"878sx1bcgr.fsf@evledraar.gmail.com","threadId":"50810","inReplyTo":"20190326175052.GA14922@dev-l","subject":"Re: [PATCH 0/3] rebase: learn --keep-base","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-03-26T20:35:48Z","receivedAt":"2019-03-26T20:36:00Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Mar 26 2019, Denton Liu wrote:\n\n> Hi Ævar,\n>\n> On Tue, Mar 26, 2019 at 03:35:34PM +0100, Ævar Arnfjörð Bjarmason wrote:\n>>\n>> On Sat, Mar 23 2019, Denton Liu wrote:\n>>\n>> > This series teaches rebase the --keep-base option.\n>> >\n>> > 'git rebase --keep-base ' is equivalent to\n>> > 'git rebase --onto ... ' or\n>> > 'git rebase --onto $(git merge-base HEAD) ' .\n>> >\n>> > This seems to be a common case that people (including myself!) run into; I was\n>> > able to find these StackOverflow posts about this use case:\n>> >\n>> > * https://stackoverflow.com/questions/53234798/can-i-rebase-on-a-branchs-fork-point-without-explicitly-specifying-the-parent\n>> > * https://stackoverflow.com/questions/41529128/how-do-you-rebase-only-changes-between-two-branches-into-another-branch\n>> > * https://stackoverflow.com/a/4207357\n>>\n>> Like with another series of yours I think this would be best squashed\n>> into one patch.\n>\n> Will do.\n>\n>>\n>> Maybe I've misunderstood this but isn't this like --fork-point except\n>> with just plain \"git merge-base\" instead of \"git merge-base\n>> --fork-point\", but then again 2/3 shows multiple base aren't supported,\n>> but merge-base supports that.\n>>\n>\n> --fork-point gets used to determine the _set of_ commits which are to be\n> rebased, whereas --keep-base (and --onto) determine the base where that\n> set of commits will be spliced. As a result, these two options cover\n> orthogonal use-cases.\n\nRight. After playing with this a bit more though --fork-point is mostly\nthere, it it does find the same fork point, as evidenced all your tests\n(that aren't asserting incompatibility with other options) passing with\nthis:\n\n diff --git a/t/t3416-rebase-onto-threedots.sh b/t/t3416-rebase-onto-threedots.sh\n index 9c2548423b..ab2d50e69a 100755\n --- a/t/t3416-rebase-onto-threedots.sh\n +++ b/t/t3416-rebase-onto-threedots.sh\n @@ -116,7 +116,7 @@ test_expect_success 'rebase --keep-base master from topic' '\n git checkout topic &&\n git reset --hard G &&\n\n - git rebase --keep-base master &&\n + git rebase $(git merge-base --fork-point master HEAD) &&\n git rev-parse C >base.expect &&\n git merge-base master HEAD >base.actual &&\n test_cmp base.expect base.actual &&\n @@ -140,7 +140,7 @@ test_expect_success 'rebase -i --keep-base master from topic' '\n git reset --hard G &&\n\n set_fake_editor &&\n - EXPECT_COUNT=2 git rebase -i --keep-base master &&\n + EXPECT_COUNT=2 git rebase -i $(git merge-base --fork-point master HEAD) &&\n git rev-parse C >base.expect &&\n git merge-base master HEAD >base.actual &&\n test_cmp base.expect base.actual &&\n\nI've poked at some of this recently in\nhttps://public-inbox.org/git/20190221214059.9195-3-avarab@gmail.com/ as\nnoted in the feedback there (I haven't gotten around to v2 yet) it's\nentirely possible that I haven't understood this at all :)\n\nBut it seems to me that this patch/implementation conflates two\nunrelated things.\n\nOnce is that we use --fork-point to mean that we're going to find the\ndivergence point with \"merge-base --fork-point\". This gets you halfway\nto where you want to be, i.e. AFAICT the --keep-base and --fork-point\nwill always find the same commit for \"git rebase\" and \"git rebase\n--keep-base\". See the \"options.restrict_revision = get_fork_point(...)\"\npart of the code.\n\nThe other, which you want to disable, is that --fork-point *also* says\n\"OK, once we've found the divergence point, let's then rebase it on the\nlatest upstream. Or in the example above the \"master\" part of \"git\nmerge-base --fork-point master HEAD\".\n\nShouldn't --keep-base just be implemented in terms of skipping *that*\npart, i.e. we find the fork point using the upstream info, but then\ndon't rebase *on* upstream.\n\nThe reason the distinction matters is because with your patch these two\nact differently:\n\n git rebase --keep-base\n git rebase $(git merge-base @{u} HEAD)\n\nThe latter will skip work (\"Current branch master is up to date\"), but\n--keep-base will always re-rebase things. There's some cases where\n--fork-point does that, which I was trying to address with my linked WIP\npatch above.\n\nWhereas the thing you actually want to work is:\n\n git rebase -i --keep-base\n git rebase -i $(git merge-base @{u} HEAD)\n\nI.e. to have both of those allow you to re-arrange/fixup whatever and\nstill rebase on the same divergence point with @{u}, and won't run\nrebase when there's no work to do unless you give it --force-rebase.\n\n> reason that --onto already disallows multiple bases. If we have multiple\n> bases, how do we determine which one is the \"true base\" to use? It makes\n> more sense to error out and let the user manually specify it.\n\nAh, makes sense.\n\n>> I'd find something like the \"DISCUSSION ON FORK-POINT MODE\" in\n>> git-merge-base helpful with examples of what we'd pick in the various\n>> scenarios, and also if whatever commit this picks was something you\n>> could have \"git merge-base\" spew out, so you could get what rebase would\n>> do here from other tooling (which maybe is possible, but I'm confused by\n>> the \"no multiple bases\"...).\n>\n> If I'm understanding you correctly then yes, this could be done with\n> other tooling. See the 0/3 for equivalent commands.\n>\n> Perhaps I should update the rebase documentation to mention that\n> --fork-point and --keep-base are orthogonal because it's unclear for\n> you, it's probably unclear for other users as well.\n>\n> Thanks,\n>\n> Denton\n"},{"id":"372549","messageId":"20190326213031.GA21504@dev-l","threadId":"50810","inReplyTo":"878sx1bcgr.fsf@evledraar.gmail.com","subject":"Re: [PATCH 0/3] rebase: learn --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-26T21:30:31Z","receivedAt":"2019-03-26T21:30:36Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"Hi Ævar,\n\nOn Tue, Mar 26, 2019 at 09:35:48PM +0100, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Tue, Mar 26 2019, Denton Liu wrote:\n> \n> > Hi Ævar,\n> >\n> > On Tue, Mar 26, 2019 at 03:35:34PM +0100, Ævar Arnfjörð Bjarmason wrote:\n> >>\n> >> On Sat, Mar 23 2019, Denton Liu wrote:\n> >>\n> >> > This series teaches rebase the --keep-base option.\n> >> >\n> >> > 'git rebase --keep-base ' is equivalent to\n> >> > 'git rebase --onto ... ' or\n> >> > 'git rebase --onto $(git merge-base HEAD) ' .\n> >> >\n> >> > This seems to be a common case that people (including myself!) run into; I was\n> >> > able to find these StackOverflow posts about this use case:\n> >> >\n> >> > * https://stackoverflow.com/questions/53234798/can-i-rebase-on-a-branchs-fork-point-without-explicitly-specifying-the-parent\n> >> > * https://stackoverflow.com/questions/41529128/how-do-you-rebase-only-changes-between-two-branches-into-another-branch\n> >> > * https://stackoverflow.com/a/4207357\n> >>\n> >> Like with another series of yours I think this would be best squashed\n> >> into one patch.\n> >\n> > Will do.\n> >\n> >>\n> >> Maybe I've misunderstood this but isn't this like --fork-point except\n> >> with just plain \"git merge-base\" instead of \"git merge-base\n> >> --fork-point\", but then again 2/3 shows multiple base aren't supported,\n> >> but merge-base supports that.\n> >>\n> >\n> > --fork-point gets used to determine the _set of_ commits which are to be\n> > rebased, whereas --keep-base (and --onto) determine the base where that\n> > set of commits will be spliced. As a result, these two options cover\n> > orthogonal use-cases.\n> \n> Right. After playing with this a bit more though --fork-point is mostly\n> there, it it does find the same fork point, as evidenced all your tests\n> (that aren't asserting incompatibility with other options) passing with\n> this:\n> \n> diff --git a/t/t3416-rebase-onto-threedots.sh b/t/t3416-rebase-onto-threedots.sh\n> index 9c2548423b..ab2d50e69a 100755\n> --- a/t/t3416-rebase-onto-threedots.sh\n> +++ b/t/t3416-rebase-onto-threedots.sh\n> @@ -116,7 +116,7 @@ test_expect_success 'rebase --keep-base master from topic' '\n> git checkout topic &&\n> git reset --hard G &&\n> \n> - git rebase --keep-base master &&\n> + git rebase $(git merge-base --fork-point master HEAD) &&\n> git rev-parse C >base.expect &&\n> git merge-base master HEAD >base.actual &&\n> test_cmp base.expect base.actual &&\n> @@ -140,7 +140,7 @@ test_expect_success 'rebase -i --keep-base master from topic' '\n> git reset --hard G &&\n> \n> set_fake_editor &&\n> - EXPECT_COUNT=2 git rebase -i --keep-base master &&\n> + EXPECT_COUNT=2 git rebase -i $(git merge-base --fork-point master HEAD) &&\n> git rev-parse C >base.expect &&\n> git merge-base master HEAD >base.actual &&\n> test_cmp base.expect base.actual &&\n> \n> I've poked at some of this recently in\n> https://public-inbox.org/git/20190221214059.9195-3-avarab@gmail.com/ as\n> noted in the feedback there (I haven't gotten around to v2 yet) it's\n> entirely possible that I haven't understood this at all :)\n> \n> But it seems to me that this patch/implementation conflates two\n> unrelated things.\n> \n> Once is that we use --fork-point to mean that we're going to find the\n> divergence point with \"merge-base --fork-point\". This gets you halfway\n> to where you want to be, i.e. AFAICT the --keep-base and --fork-point\n> will always find the same commit for \"git rebase\" and \"git rebase\n> --keep-base\". See the \"options.restrict_revision = get_fork_point(...)\"\n> part of the code.\n\nI don't think this is true. The code that --keep-base uses to find the\nmerge base is get_oid_mb, see the relevant snippet\n\n\tif (strstr(options.onto_name, \"...\")) {\n\t\tif (get_oid_mb(options.onto_name, &merge_base) < 0)\n\nwhereas the --fork-point code uses get_fork_point, as you mentioned\nabove. As a result, they don't necessarily refer to the same commit in\nthe case where upstream is rewound.\n\n> \n> The other, which you want to disable, is that --fork-point *also* says\n> \"OK, once we've found the divergence point, let's then rebase it on the\n> latest upstream. Or in the example above the \"master\" part of \"git\n> merge-base --fork-point master HEAD\".\n\nCorrect, I guess in essence this is what I'm doing.\n\n> \n> Shouldn't --keep-base just be implemented in terms of skipping *that*\n> part, i.e. we find the fork point using the upstream info, but then\n> don't rebase *on* upstream.\n> \n> The reason the distinction matters is because with your patch these two\n> act differently:\n> \n> git rebase --keep-base\n> git rebase $(git merge-base @{u} HEAD)\n> \n> The latter will skip work (\"Current branch master is up to date\"), but\n> --keep-base will always re-rebase things. There's some cases where\n> --fork-point does that, which I was trying to address with my linked WIP\n> patch above.\n\nI believe this is desired behaviour. Suppose we have this (modified)\ngraph from the git-merge-base docs, where B3 was formerly part of\norigin/master but it was then rewound:\n\n ---o---o---B2--o---o---o---B (origin/master)\n \\\n B3\n \\\n Derived (local master)\n\nIf we run \"git rebase --keep-base\", we'll get the following graph:\n\n ---o---o---B2--o---o---o---B (origin/master)\n \\\n Derived (local master)\n\nwhich I believe is the desired behaviour (we're abandoning B3 since\nupstream abandoned it).\n\nI hope I'm understanding you correctly. Please let me know if I've\nmisinterpreted anything you've said or if anything I've said is unclear.\n\nThanks,\n\nDenton\n\n> \n> Whereas the thing you actually want to work is:\n> \n> git rebase -i --keep-base\n> git rebase -i $(git merge-base @{u} HEAD)\n> \n> I.e. to have both of those allow you to re-arrange/fixup whatever and\n> still rebase on the same divergence point with @{u}, and won't run\n> rebase when there's no work to do unless you give it --force-rebase.\n> \n> > reason that --onto already disallows multiple bases. If we have multiple\n> > bases, how do we determine which one is the \"true base\" to use? It makes\n> > more sense to error out and let the user manually specify it.\n> \n> Ah, makes sense.\n> \n> >> I'd find something like the \"DISCUSSION ON FORK-POINT MODE\" in\n> >> git-merge-base helpful with examples of what we'd pick in the various\n> >> scenarios, and also if whatever commit this picks was something you\n> >> could have \"git merge-base\" spew out, so you could get what rebase would\n> >> do here from other tooling (which maybe is possible, but I'm confused by\n> >> the \"no multiple bases\"...).\n> >\n> > If I'm understanding you correctly then yes, this could be done with\n> > other tooling. See the 0/3 for equivalent commands.\n> >\n> > Perhaps I should update the rebase documentation to mention that\n> > --fork-point and --keep-base are orthogonal because it's unclear for\n> > you, it's probably unclear for other users as well.\n> >\n> > Thanks,\n> >\n> > Denton\n"},{"id":"372580","messageId":"871s2sba2h.fsf@evledraar.gmail.com","threadId":"50810","inReplyTo":"20190326213031.GA21504@dev-l","subject":"Re: [PATCH 0/3] rebase: learn --keep-base","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-03-27T15:39:50Z","receivedAt":"2019-03-27T15:39:56Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Mar 26 2019, Denton Liu wrote:\n\n> Hi Ævar,\n>\n> On Tue, Mar 26, 2019 at 09:35:48PM +0100, Ævar Arnfjörð Bjarmason wrote:\n>>\n>> On Tue, Mar 26 2019, Denton Liu wrote:\n>>\n>> > Hi Ævar,\n>> >\n>> > On Tue, Mar 26, 2019 at 03:35:34PM +0100, Ævar Arnfjörð Bjarmason wrote:\n>> >>\n>> >> On Sat, Mar 23 2019, Denton Liu wrote:\n>> >>\n>> >> > This series teaches rebase the --keep-base option.\n>> >> >\n>> >> > 'git rebase --keep-base ' is equivalent to\n>> >> > 'git rebase --onto ... ' or\n>> >> > 'git rebase --onto $(git merge-base HEAD) ' .\n>> >> >\n>> >> > This seems to be a common case that people (including myself!) run into; I was\n>> >> > able to find these StackOverflow posts about this use case:\n>> >> >\n>> >> > * https://stackoverflow.com/questions/53234798/can-i-rebase-on-a-branchs-fork-point-without-explicitly-specifying-the-parent\n>> >> > * https://stackoverflow.com/questions/41529128/how-do-you-rebase-only-changes-between-two-branches-into-another-branch\n>> >> > * https://stackoverflow.com/a/4207357\n>> >>\n>> >> Like with another series of yours I think this would be best squashed\n>> >> into one patch.\n>> >\n>> > Will do.\n>> >\n>> >>\n>> >> Maybe I've misunderstood this but isn't this like --fork-point except\n>> >> with just plain \"git merge-base\" instead of \"git merge-base\n>> >> --fork-point\", but then again 2/3 shows multiple base aren't supported,\n>> >> but merge-base supports that.\n>> >>\n>> >\n>> > --fork-point gets used to determine the _set of_ commits which are to be\n>> > rebased, whereas --keep-base (and --onto) determine the base where that\n>> > set of commits will be spliced. As a result, these two options cover\n>> > orthogonal use-cases.\n>>\n>> Right. After playing with this a bit more though --fork-point is mostly\n>> there, it it does find the same fork point, as evidenced all your tests\n>> (that aren't asserting incompatibility with other options) passing with\n>> this:\n>>\n>> diff --git a/t/t3416-rebase-onto-threedots.sh b/t/t3416-rebase-onto-threedots.sh\n>> index 9c2548423b..ab2d50e69a 100755\n>> --- a/t/t3416-rebase-onto-threedots.sh\n>> +++ b/t/t3416-rebase-onto-threedots.sh\n>> @@ -116,7 +116,7 @@ test_expect_success 'rebase --keep-base master from topic' '\n>> git checkout topic &&\n>> git reset --hard G &&\n>>\n>> - git rebase --keep-base master &&\n>> + git rebase $(git merge-base --fork-point master HEAD) &&\n>> git rev-parse C >base.expect &&\n>> git merge-base master HEAD >base.actual &&\n>> test_cmp base.expect base.actual &&\n>> @@ -140,7 +140,7 @@ test_expect_success 'rebase -i --keep-base master from topic' '\n>> git reset --hard G &&\n>>\n>> set_fake_editor &&\n>> - EXPECT_COUNT=2 git rebase -i --keep-base master &&\n>> + EXPECT_COUNT=2 git rebase -i $(git merge-base --fork-point master HEAD) &&\n>> git rev-parse C >base.expect &&\n>> git merge-base master HEAD >base.actual &&\n>> test_cmp base.expect base.actual &&\n>>\n>> I've poked at some of this recently in\n>> https://public-inbox.org/git/20190221214059.9195-3-avarab@gmail.com/ as\n>> noted in the feedback there (I haven't gotten around to v2 yet) it's\n>> entirely possible that I haven't understood this at all :)\n>>\n>> But it seems to me that this patch/implementation conflates two\n>> unrelated things.\n>>\n>> Once is that we use --fork-point to mean that we're going to find the\n>> divergence point with \"merge-base --fork-point\". This gets you halfway\n>> to where you want to be, i.e. AFAICT the --keep-base and --fork-point\n>> will always find the same commit for \"git rebase\" and \"git rebase\n>> --keep-base\". See the \"options.restrict_revision = get_fork_point(...)\"\n>> part of the code.\n>\n> I don't think this is true. The code that --keep-base uses to find the\n> merge base is get_oid_mb, see the relevant snippet\n>\n> \tif (strstr(options.onto_name, \"...\")) {\n> \t\tif (get_oid_mb(options.onto_name, &merge_base) < 0)\n>\n> whereas the --fork-point code uses get_fork_point, as you mentioned\n> above. As a result, they don't necessarily refer to the same commit in\n> the case where upstream is rewound.\n>\n>>\n>> The other, which you want to disable, is that --fork-point *also* says\n>> \"OK, once we've found the divergence point, let's then rebase it on the\n>> latest upstream. Or in the example above the \"master\" part of \"git\n>> merge-base --fork-point master HEAD\".\n>\n> Correct, I guess in essence this is what I'm doing.\n>\n>>\n>> Shouldn't --keep-base just be implemented in terms of skipping *that*\n>> part, i.e. we find the fork point using the upstream info, but then\n>> don't rebase *on* upstream.\n>>\n>> The reason the distinction matters is because with your patch these two\n>> act differently:\n>>\n>> git rebase --keep-base\n>> git rebase $(git merge-base @{u} HEAD)\n>>\n>> The latter will skip work (\"Current branch master is up to date\"), but\n>> --keep-base will always re-rebase things. There's some cases where\n>> --fork-point does that, which I was trying to address with my linked WIP\n>> patch above.\n>\n> I believe this is desired behaviour. Suppose we have this (modified)\n> graph from the git-merge-base docs, where B3 was formerly part of\n> origin/master but it was then rewound:\n>\n> ---o---o---B2--o---o---o---B (origin/master)\n> \\\n> B3\n> \\\n> Derived (local master)\n>\n> If we run \"git rebase --keep-base\", we'll get the following graph:\n>\n> ---o---o---B2--o---o---o---B (origin/master)\n> \\\n> Derived (local master)\n>\n> which I believe is the desired behaviour (we're abandoning B3 since\n> upstream abandoned it).\n>\n> I hope I'm understanding you correctly. Please let me know if I've\n> misinterpreted anything you've said or if anything I've said is unclear.\n\nYeah. I'm still confused, but mainly because I haven't allocated enough\nbrainpower to try to understand it :)\n\nSo yeah, I can believe it's subtly different, would be great to have a\nv2 whose docs/tests cover those subtleties, right now (as seen in my\ndiscussion upthread) the tests that are there can identically use the\nfork point.\n\nI also wonder if we can holistically think about this UI / how we can\nexpose different things. E.g. for the times I've needed this and have\nmanually dug up the fork point I haven't wanted to handle the case of\nupstream rewinding, just re-rebase-i on some old base, while still\nhaving upstream tracking info, and for rebase to exit early if there's\nnothing to do (similar to if I feed it the fork point as a rev).\n\n>>\n>> Whereas the thing you actually want to work is:\n>>\n>> git rebase -i --keep-base\n>> git rebase -i $(git merge-base @{u} HEAD)\n>>\n>> I.e. to have both of those allow you to re-arrange/fixup whatever and\n>> still rebase on the same divergence point with @{u}, and won't run\n>> rebase when there's no work to do unless you give it --force-rebase.\n>>\n>> > reason that --onto already disallows multiple bases. If we have multiple\n>> > bases, how do we determine which one is the \"true base\" to use? It makes\n>> > more sense to error out and let the user manually specify it.\n>>\n>> Ah, makes sense.\n>>\n>> >> I'd find something like the \"DISCUSSION ON FORK-POINT MODE\" in\n>> >> git-merge-base helpful with examples of what we'd pick in the various\n>> >> scenarios, and also if whatever commit this picks was something you\n>> >> could have \"git merge-base\" spew out, so you could get what rebase would\n>> >> do here from other tooling (which maybe is possible, but I'm confused by\n>> >> the \"no multiple bases\"...).\n>> >\n>> > If I'm understanding you correctly then yes, this could be done with\n>> > other tooling. See the 0/3 for equivalent commands.\n>> >\n>> > Perhaps I should update the rebase documentation to mention that\n>> > --fork-point and --keep-base are orthogonal because it's unclear for\n>> > you, it's probably unclear for other users as well.\n>> >\n>> > Thanks,\n>> >\n>> > Denton\n"},{"id":"372652","messageId":"20190328221745.GA3941@dev-l","threadId":"50810","inReplyTo":"cover.1553354374.git.liu.denton@gmail.com","subject":"[PATCH v2] rebase: teach rebase --keep-base","fromName":"Denton Liu","fromEmail":"liu.denton@gmail.com","sentAt":"2019-03-28T22:17:45Z","receivedAt":"2019-03-28T22:17:51Z","isPatch":true,"sender":{"key":"liu.denton@gmail.com","avatar":"https://avatars.githubusercontent.com/u/9620836?v=4"},"body":"A common scenario is if a user is working on a topic branch and they\nwish to make some changes to intermediate commits or autosquash, they\nwould run something such as\n\n\tgit rebase -i --onto master... master\n\nin order to preserve the merge base. This prevents unnecessary commit\nchurning.\n\nAlternatively, a user wishing to test individual commits in a topic\nbranch without changing anything may run\n\n\tgit rebase -x ./test.sh master... master\n\nSince rebasing onto the merge base of the branch and the upstream is\nsuch a common case, introduce the --keep-base option as a shortcut.\n\nThis allows us to rewrite the above as\n\n\tgit rebase -i --keep-base master\n\nand\n\n\tgit rebase -x ./test.sh --keep-base master\n\nrespectively.\n\nAdd tests to ensure --keep-base works correctly in the normal case and\nfails when there are multiple merge bases, both in regular and\ninteractive mode. Also, test to make sure conflicting options cause\nrebase to fail. While we're adding test cases, add a missing\nset_fake_editor call to 'rebase -i --onto master...side'.\n\nWhile we're documenting the --keep-base option, change an instance of\n\"merge-base\" to \"merge base\", which is the consistent spelling.\n\nHelped-by: Eric Sunshine \nHelped-by: Junio C Hamano \nHelped-by: Ævar Arnfjörð Bjarmason \nSigned-off-by: Denton Liu \n---\n\nÆvar, I have a feeling that we're still miscommunicating and we don't\nfully understand each other. I'm putting up v2 to hopefully clear things\nup a little but I welcome more feedback.\n\nThis patch now depends \"[PATCH 1/8] tests (rebase): spell out the\n`--keep-empty` option\" which is the first patch of Johannes's \"Do not\nuse abbreviated options in tests\" patchset[1]. (Thanks for catching\nthat, Johannes!)\n\nChanges since v1:\n\n* Squashed old set into one patch\n* Fixed indentation style and dangling else\n* Added more documentation after discussion with Ævar\n\n[1]: https://public-inbox.org/git/a1b4b74b9167e279dae4cd8c58fb28d8a714a66a.1553537656.git.gitgitgadget@gmail.com/\n\n Documentation/git-rebase.txt | 25 ++++++++++++--\n builtin/rebase.c | 32 ++++++++++++++----\n t/t3416-rebase-onto-threedots.sh | 57 ++++++++++++++++++++++++++++++++\n 3 files changed, 105 insertions(+), 9 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 6363d674b7..27be1f48ff 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -8,8 +8,8 @@ git-rebase - Reapply commits on top of another base tip\n SYNOPSIS\n --------\n [verse]\n-'git rebase' [-i | --interactive] [] [--exec ] [--onto ]\n-\t[ []]\n+'git rebase' [-i | --interactive] [] [--exec ]\n+\t[--onto | --keep-base] [ []]\n 'git rebase' [-i | --interactive] [] [--exec ] [--onto ]\n \t--root []\n 'git rebase' --continue | --skip | --abort | --quit | --edit-todo | --show-current-patch\n@@ -217,6 +217,19 @@ As a special case, you may use \"A\\...B\" as a shortcut for the\n merge base of A and B if there is exactly one merge base. You can\n leave out at most one of A and B, in which case it defaults to HEAD.\n \n+--keep-base::\n+\tSet the starting point at which to create the new commits to the\n+\tmerge base of . Running\n+\t'git rebase --keep-base ' is equivalent to\n+\trunning 'git rebase --onto ... '.\n++\n+Although both this option and --fork-point find the merge base between\n+ and , this option uses the merge base as the _starting\n+point_ on which new commits will be created, whereas --fork-point uses\n+the merge base to determine the _set of commits_ which will be rebased.\n++\n+See also INCOMPATIBLE OPTIONS below.\n+\n ::\n \tUpstream branch to compare against. May be any valid commit,\n \tnot just an existing branch name. Defaults to the configured\n@@ -364,6 +377,10 @@ ends up being empty, the will be used as a fallback.\n +\n If either or --root is given on the command line, then the\n default is `--no-fork-point`, otherwise the default is `--fork-point`.\n++\n+If your branch was based on but was rewound and\n+your branch contains commits which were dropped, this option can be used\n+with `--keep-base` in order to drop those commits from your branch.\n \n --ignore-whitespace::\n --whitespace=