{"thread":{"id":"35974","subject":"[PATCH/RFC] rebase: new convenient option to edit a single commit","startedAt":"2014-02-27T13:01:18Z","lastAt":"2014-03-10T08:41:04Z","messageCount":40,"participants":["Nguyễn Thái Ngọc Duy","Matthieu Moy","Jeff King","Duy Nguyen","Philip Oakley","Eric Sunshine","Michael Haggerty","David Kastrup","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"235469","messageId":"1393506078-7310-1-git-send-email-pclouds@gmail.com","threadId":"35974","inReplyTo":null,"subject":"[PATCH/RFC] rebase: new convenient option to edit a single commit","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2014-02-27T13:01:18Z","receivedAt":"2014-02-27T13:01:18Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"I find myself often do \"git rebase -i xxx\" and replace one \"pick\" line\nwith \"edit\" to amend just one commit when I see something I don't like\nin that commit. This happens often while cleaning up a series. This\nautomates the \"replace\" step so it sends me straight to that commit.\n\n\"commit --fixup\" then \"rebase --autosquash\" would work too but I still\nneed to edit todo file to make it stop after squashing so I can test\nthat commit. So still extra steps.\n\nOr is there a better way to do this?\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n git-rebase--interactive.sh | 17 ++++++++++++++---\n git-rebase.sh | 10 ++++++++++\n 2 files changed, 24 insertions(+), 3 deletions(-)\n\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex d741b04..0988b5c 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -1027,9 +1027,20 @@ fi\n has_action \"$todo\" ||\n \tdie_abort \"Nothing to do\"\n \n-cp \"$todo\" \"$todo\".backup\n-git_sequence_editor \"$todo\" ||\n-\tdie_abort \"Could not execute editor\"\n+if test -n \"$edit_one\"\n+then\n+\tedit_one=\"`git rev-parse --short $edit_one`\"\n+\tsed \"1s/pick $edit_one /edit $edit_one /\" \"$todo\" > \"$todo.new\" ||\n+\t\tdie_abort \"failed to update todo list\"\n+\tgrep \"^edit $edit_one \" \"$todo.new\" >/dev/null ||\n+\t\tdie_abort \"expected to find 'edit $edit_one' line but did not\"\n+\tmv \"$todo.new\" \"$todo\" ||\n+\t\tdie_abort \"failed to update todo list\"\n+else\n+\tcp \"$todo\" \"$todo\".backup\n+\tgit_sequence_editor \"$todo\" ||\n+\t\tdie_abort \"Could not execute editor\"\n+fi\n \n has_action \"$todo\" ||\n \tdie_abort \"Nothing to do\"\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 1cf8dba..98796cc 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -31,6 +31,7 @@ verify allow pre-rebase hook to run\n rerere-autoupdate allow rerere to update index with resolved conflicts\n root! rebase all reachable commits up to the root(s)\n autosquash move commits that begin with squash!/fixup! under -i\n+1,edit-one! generate todo list to edit this commit\n committer-date-is-author-date! passed to 'git am'\n ignore-date! passed to 'git am'\n whitespace=! passed to 'git apply'\n@@ -249,6 +250,10 @@ do\n \t-i)\n \t\tinteractive_rebase=explicit\n \t\t;;\n+\t-1)\n+\t\tinteractive_rebase=explicit\n+\t\tedit_one=t\n+\t\t;;\n \t-k)\n \t\tkeep_empty=yes\n \t\t;;\n@@ -450,6 +455,11 @@ then\n \t\t;;\n \t*)\tupstream_name=\"$1\"\n \t\tshift\n+\t\tif test -n \"$edit_one\"\n+\t\tthen\n+\t\t\tedit_one=\"$upstream_name\"\n+\t\t\tupstream_name=\"$upstream_name^\"\n+\t\tfi\n \t\t;;\n \tesac\n \tupstream=$(peel_committish \"${upstream_name}\") ||\n-- \n1.9.0.66.g14f785a\n"},{"id":"235476","messageId":"vpqvbw08xy0.fsf@anie.imag.fr","threadId":"35974","inReplyTo":"1393506078-7310-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH/RFC] rebase: new convenient option to edit a single commit","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-02-27T13:52:39Z","receivedAt":"2014-02-27T13:52:39Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> I find myself often do \"git rebase -i xxx\" and replace one \"pick\" line\n> with \"edit\" to amend just one commit when I see something I don't like\n> in that commit. This happens often while cleaning up a series. This\n> automates the \"replace\" step so it sends me straight to that commit.\n\nSounds a good idea to me.\n\n> git-rebase--interactive.sh | 17 ++++++++++++++---\n> git-rebase.sh | 10 ++++++++++\n\n(obviously, don't forget doc and test if this becomes a non-RFC)\n\n> has_action \"$todo\" ||\n> \tdie_abort \"Nothing to do\"\n> diff --git a/git-rebase.sh b/git-rebase.sh\n> index 1cf8dba..98796cc 100755\n> --- a/git-rebase.sh\n> +++ b/git-rebase.sh\n> @@ -31,6 +31,7 @@ verify allow pre-rebase hook to run\n> rerere-autoupdate allow rerere to update index with resolved conflicts\n> root! rebase all reachable commits up to the root(s)\n> autosquash move commits that begin with squash!/fixup! under -i\n> +1,edit-one! generate todo list to edit this commit\n> committer-date-is-author-date! passed to 'git am'\n> ignore-date! passed to 'git am'\n> whitespace=! passed to 'git apply'\n> @@ -249,6 +250,10 @@ do\n> \t-i)\n> \t\tinteractive_rebase=explicit\n> \t\t;;\n> +\t-1)\n> +\t\tinteractive_rebase=explicit\n> +\t\tedit_one=t\n> +\t\t;;\n> \t-k)\n> \t\tkeep_empty=yes\n> \t\t;;\n> @@ -450,6 +455,11 @@ then\n> \t\t;;\n> \t*)\tupstream_name=\"$1\"\n> \t\tshift\n> +\t\tif test -n \"$edit_one\"\n> +\t\tthen\n> +\t\t\tedit_one=\"$upstream_name\"\n> +\t\t\tupstream_name=\"$upstream_name^\"\n> +\t\tfi\n> \t\t;;\n\nI think you forgot the case where the user specified -1 but no extra\nargument (i.e. use the default to upstream branch). Shouldn't the added\ncode be after the esac?\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235547","messageId":"20140228065802.GB31731@sigill.intra.peff.net","threadId":"35974","inReplyTo":"1393506078-7310-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH/RFC] rebase: new convenient option to edit a single commit","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-28T06:58:02Z","receivedAt":"2014-02-28T06:58:02Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Feb 27, 2014 at 08:01:18PM +0700, Nguyễn Thái Ngọc Duy wrote:\n\n> I find myself often do \"git rebase -i xxx\" and replace one \"pick\" line\n> with \"edit\" to amend just one commit when I see something I don't like\n> in that commit. This happens often while cleaning up a series. This\n> automates the \"replace\" step so it sends me straight to that commit.\n\nYeah, I do this a lot, too. The interface you propose makes sense to\nme, though I'm not sure how much I would use it, as I often do not know\nthe specifier of the commit I want to change (was it \"HEAD~3 or\nHEAD~4?\"). I guess using \":/\" could make that easier.\n\nOne comment on the option name:\n\n> +1,edit-one! generate todo list to edit this commit\n\nI'd expect \"-$n\" to mean \"rebase the last $n commits\" (as opposed to\neverything not in the upstream). That does not work currently, of\ncourse, but:\n\n 1. It has the potential to confuse people who read it, since it's\n unlike what \"-1\" means in most of the rest of git.\n\n 2. It closes the door if we want to support \"-$n\" in the future.\n\n-Peff\n"},{"id":"235551","messageId":"CACsJy8BC089h3j4H-DV5+BdhK74=k4v+=vO6a26xRJ==BLJ3-Q@mail.gmail.com","threadId":"35974","inReplyTo":"20140228065802.GB31731@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] rebase: new convenient option to edit a single commit","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-02-28T07:34:16Z","receivedAt":"2014-02-28T07:34:16Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Feb 28, 2014 at 1:58 PM, Jeff King wrote:\n> On Thu, Feb 27, 2014 at 08:01:18PM +0700, Nguyễn Thái Ngọc Duy wrote:\n>\n>> I find myself often do \"git rebase -i xxx\" and replace one \"pick\" line\n>> with \"edit\" to amend just one commit when I see something I don't like\n>> in that commit. This happens often while cleaning up a series. This\n>> automates the \"replace\" step so it sends me straight to that commit.\n>\n> Yeah, I do this a lot, too. The interface you propose makes sense to\n> me, though I'm not sure how much I would use it, as I often do not know\n> the specifier of the commit I want to change (was it \"HEAD~3 or\n> HEAD~4?\"). I guess using \":/\" could make that easier.\n\nIn my case, I just copy/paste the commit ID from \"git log -lp\". I\nthink :/ already works with rebase..\n\n>\n> One comment on the option name:\n>\n>> +1,edit-one! generate todo list to edit this commit\n>\n> I'd expect \"-$n\" to mean \"rebase the last $n commits\" (as opposed to\n> everything not in the upstream). That does not work currently, of\n> course, but:\n>\n> 1. It has the potential to confuse people who read it, since it's\n> unlike what \"-1\" means in most of the rest of git.\n>\n> 2. It closes the door if we want to support \"-$n\" in the future.\n\nI really like to do \"git rebase -5\" == \"git rebase HEAD~5\" but never\ngotten around do make it so. \"-1/--edit-one\" was chosen without much\nthought. Will change it to something else.\n-- \nDuy\n"},{"id":"235552","messageId":"20140228073826.GA32496@sigill.intra.peff.net","threadId":"35974","inReplyTo":"CACsJy8BC089h3j4H-DV5+BdhK74=k4v+=vO6a26xRJ==BLJ3-Q@mail.gmail.com","subject":"Re: [PATCH/RFC] rebase: new convenient option to edit a single commit","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-02-28T07:38:26Z","receivedAt":"2014-02-28T07:38:26Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 28, 2014 at 02:34:16PM +0700, Duy Nguyen wrote:\n\n> > Yeah, I do this a lot, too. The interface you propose makes sense to\n> > me, though I'm not sure how much I would use it, as I often do not know\n> > the specifier of the commit I want to change (was it \"HEAD~3 or\n> > HEAD~4?\"). I guess using \":/\" could make that easier.\n> \n> In my case, I just copy/paste the commit ID from \"git log -lp\". I\n> think :/ already works with rebase..\n\nI think it should work. I just meant \"I will have to get in the habit of\nstarting to use :/\". :)\n\n-Peff\n"},{"id":"235640","messageId":"F6E4FBE2B31243C5BA75DB824D74C3DC@PhilipOakley","threadId":"35974","inReplyTo":"20140228065802.GB31731@sigill.intra.peff.net","subject":"Re: [PATCH/RFC] rebase: new convenient option to edit a single commit","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2014-02-28T17:09:08Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Jeff King\" \n> I'd expect \"-$n\" to mean \"rebase the last $n commits\" (as opposed to\n> everything not in the upstream). That does not work currently, of\n> course, but:\n>\n> 1. It has the potential to confuse people who read it, since it's\n> unlike what \"-1\" means in most of the rest of git.\n>\n> 2. It closes the door if we want to support \"-$n\" in the future.\n>\n\nYeah, \"rebase the last $n commits\" would be a nice touch.\n\ngit rebase -i -10 --onto v1.9.0 # rebase the last 10 commits in this \nbranch etc.\n\nPhilip \n"},{"id":"235772","messageId":"1393728794-29566-1-git-send-email-pclouds@gmail.com","threadId":"35974","inReplyTo":"1393506078-7310-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 0/3] rebase's convenient options","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-02T02:53:11Z","receivedAt":"2014-03-02T02:53:11Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"A polished version from the RFC. Now you can do\n\ngit rebase -i -10 -> git rebase -i HEAD~10\ngit rebase -e XYZ -> send you to commit XYZ for editing\n\nNguyễn Thái Ngọc Duy (3):\n rev-parse: support OPT_NUMBER_CALLBACK in --parseopt\n rebase: accept - as another way of saying HEAD~\n rebase: new convenient option to edit a single commit\n\n Documentation/git-rebase.txt | 7 +++++++\n builtin/rev-parse.c | 9 +++++++--\n git-rebase--interactive.sh | 17 ++++++++++++++---\n git-rebase.sh | 19 +++++++++++++++++++\n t/t3400-rebase.sh | 6 ++++++\n 5 files changed, 53 insertions(+), 5 deletions(-)\n\n-- \n1.9.0.40.gaa8c3ea\n"},{"id":"235775","messageId":"1393728794-29566-2-git-send-email-pclouds@gmail.com","threadId":"35974","inReplyTo":"1393728794-29566-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 1/3] rev-parse: support OPT_NUMBER_CALLBACK in --parseopt","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-02T02:53:12Z","receivedAt":"2014-03-02T02:53:12Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"If the option spec is\n\n-NUM Help string\n\nthen rev-parse will accept and parse -([0-9]+) and return \"-NUM $1\"\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n builtin/rev-parse.c | 9 +++++++--\n 1 file changed, 7 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/rev-parse.c b/builtin/rev-parse.c\nindex 45901df..b37676f 100644\n--- a/builtin/rev-parse.c\n+++ b/builtin/rev-parse.c\n@@ -331,6 +331,8 @@ static int parseopt_dump(const struct option *o, const char *arg, int unset)\n \tstruct strbuf *parsed = o->value;\n \tif (unset)\n \t\tstrbuf_addf(parsed, \" --no-%s\", o->long_name);\n+\telse if (o->type == OPTION_NUMBER)\n+\t\tstrbuf_addf(parsed, \" -NUM\");\n \telse if (o->short_name && (o->long_name == NULL || !stuck_long))\n \t\tstrbuf_addf(parsed, \" -%c\", o->short_name);\n \telse\n@@ -338,7 +340,7 @@ static int parseopt_dump(const struct option *o, const char *arg, int unset)\n \tif (arg) {\n \t\tif (!stuck_long)\n \t\t\tstrbuf_addch(parsed, ' ');\n-\t\telse if (o->long_name)\n+\t\telse if (o->long_name || o->type == OPTION_NUMBER)\n \t\t\tstrbuf_addch(parsed, '=');\n \t\tsq_quote_buf(parsed, arg);\n \t}\n@@ -439,7 +441,10 @@ static int cmd_parseopt(int argc, const char **argv, const char *prefix)\n \n \t\tif (s - sb.buf == 1) /* short option only */\n \t\t\to->short_name = *sb.buf;\n-\t\telse if (sb.buf[1] != ',') /* long option only */\n+\t\telse if (s - sb.buf == 4 && !strncmp(sb.buf, \"-NUM\", 4)) {\n+\t\t\to->type = OPTION_NUMBER;\n+\t\t\to->flags = PARSE_OPT_NOARG | PARSE_OPT_NONEG;\n+\t\t} else if (sb.buf[1] != ',') /* long option only */\n \t\t\to->long_name = xmemdupz(sb.buf, s - sb.buf);\n \t\telse {\n \t\t\to->short_name = *sb.buf;\n-- \n1.9.0.40.gaa8c3ea\n"},{"id":"235773","messageId":"1393728794-29566-3-git-send-email-pclouds@gmail.com","threadId":"35974","inReplyTo":"1393728794-29566-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-02T02:53:13Z","receivedAt":"2014-03-02T02:53:13Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"This is \"rev-list style\", where people can do \"git rev-list -3\" in\naddition to \"git rev-list HEAD~3\". A lot of commands are driven by the\nrevision machinery and also accept this form. This addition to rebase\nis just for convenience.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n Documentation/git-rebase.txt | 3 +++\n git-rebase.sh | 9 +++++++++\n t/t3400-rebase.sh | 6 ++++++\n 3 files changed, 18 insertions(+)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 2a93c64..52c3561 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -223,6 +223,9 @@ 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+-::\n+\tSpecify as \"HEAD~\".\n+\n ::\n \tUpstream branch to compare against. May be any valid commit,\n \tnot just an existing branch name. Defaults to the configured\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 5f6732b..33face1 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -43,6 +43,7 @@ continue! continue\n abort! abort and check out the original branch\n skip! skip current patch and continue\n edit-todo! edit the todo list during an interactive rebase\n+-NUM equivalent of HEAD~\n \"\n . git-sh-setup\n . git-sh-i18n\n@@ -335,6 +336,9 @@ do\n \t--gpg-sign=*)\n \t\tgpg_sign_opt=\"-S${1#--gpg-sign=}\"\n \t\t;;\n+\t-NUM=*)\n+\t\tNUM=\"${1#-NUM=}\"\n+\t\t;;\n \t--)\n \t\tshift\n \t\tbreak\n@@ -342,6 +346,11 @@ do\n \tesac\n \tshift\n done\n+if [ -n \"$NUM\" ]\n+then\n+\ttest $# -gt 0 && usage\n+\tset -- \"$@\" \"HEAD~$NUM\"\n+fi\n test $# -gt 2 && usage\n \n if test -n \"$cmd\" &&\ndiff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh\nindex 6d94b1f..11db7ea 100755\n--- a/t/t3400-rebase.sh\n+++ b/t/t3400-rebase.sh\n@@ -215,4 +215,10 @@ test_expect_success 'rebase commit with an ancient timestamp' '\n \tgrep \"author .* 34567 +0600$\" actual\n '\n \n+test_expect_success 'rebase -' '\n+\tgit reset --hard &&\n+\ttest_must_fail git rebase -2 HEAD^^ &&\n+\tgit rebase -2\n+'\n+\n test_done\n-- \n1.9.0.40.gaa8c3ea\n"},{"id":"235774","messageId":"1393728794-29566-4-git-send-email-pclouds@gmail.com","threadId":"35974","inReplyTo":"1393728794-29566-1-git-send-email-pclouds@gmail.com","subject":"[PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-02T02:53:14Z","receivedAt":"2014-03-02T02:53:14Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"\"git rebase -e XYZ\" is basically the same as\n\nEDITOR=\"sed -i '1s/pick XYZ/edit XYZ/' $@\" \\\ngit rebase -i XYZ^\n\nIn English, it prepares the todo list for you to edit only commit XYZ\nto save your time. The time saving is only significant when you edit a\nlot of commits separately.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n Documentation/git-rebase.txt | 4 ++++\n git-rebase--interactive.sh | 17 ++++++++++++++---\n git-rebase.sh | 10 ++++++++++\n 3 files changed, 28 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 52c3561..b8c263d 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -359,6 +359,10 @@ unless the `--fork-point` option is specified.\n \tuser edit that list before rebasing. This mode can also be used to\n \tsplit commits (see SPLITTING COMMITS below).\n \n+-e::\n+--edit-one::\n+\tPrepare the todo list to edit only the commit at \n+\n -p::\n --preserve-merges::\n \tInstead of ignoring merges, try to recreate them.\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex a1adae8..4762d57 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -1040,9 +1040,20 @@ fi\n has_action \"$todo\" ||\n \tdie_abort \"Nothing to do\"\n \n-cp \"$todo\" \"$todo\".backup\n-git_sequence_editor \"$todo\" ||\n-\tdie_abort \"Could not execute editor\"\n+if test -n \"$edit_one\"\n+then\n+\tedit_one=\"`git rev-parse --short $edit_one`\"\n+\tsed \"1s/pick $edit_one /edit $edit_one /\" \"$todo\" > \"$todo.new\" ||\n+\t\tdie_abort \"failed to update todo list\"\n+\tgrep \"^edit $edit_one \" \"$todo.new\" >/dev/null ||\n+\t\tdie_abort \"expected to find 'edit $edit_one' line but did not\"\n+\tmv \"$todo.new\" \"$todo\" ||\n+\t\tdie_abort \"failed to update todo list\"\n+else\n+\tcp \"$todo\" \"$todo\".backup\n+\tgit_sequence_editor \"$todo\" ||\n+\t\tdie_abort \"Could not execute editor\"\n+fi\n \n has_action \"$todo\" ||\n \tdie_abort \"Nothing to do\"\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 33face1..b8b6aa9 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -32,6 +32,7 @@ verify allow pre-rebase hook to run\n rerere-autoupdate allow rerere to update index with resolved conflicts\n root! rebase all reachable commits up to the root(s)\n autosquash move commits that begin with squash!/fixup! under -i\n+e,edit-one! generate todo list to edit this commit\n committer-date-is-author-date! passed to 'git am'\n ignore-date! passed to 'git am'\n whitespace=! passed to 'git apply'\n@@ -339,6 +340,10 @@ do\n \t-NUM=*)\n \t\tNUM=\"${1#-NUM=}\"\n \t\t;;\n+\t--edit-one)\n+\t\tinteractive_rebase=explicit\n+\t\tedit_one=t\n+\t\t;;\n \t--)\n \t\tshift\n \t\tbreak\n@@ -463,6 +468,11 @@ then\n \t\t;;\n \t*)\tupstream_name=\"$1\"\n \t\tshift\n+\t\tif test -n \"$edit_one\"\n+\t\tthen\n+\t\t\tedit_one=\"$upstream_name\"\n+\t\t\tupstream_name=\"$upstream_name^\"\n+\t\tfi\n \t\t;;\n \tesac\n \tupstream=$(peel_committish \"${upstream_name}\") ||\n-- \n1.9.0.40.gaa8c3ea\n"},{"id":"235790","messageId":"CAPig+cTj1hBOFDLA5LecXwrVN4FG6pAzSDTAyLchHQbOkoEnEA@mail.gmail.com","threadId":"35974","inReplyTo":"1393728794-29566-3-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2014-03-02T08:37:45Z","receivedAt":"2014-03-02T08:37:45Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n> This is \"rev-list style\", where people can do \"git rev-list -3\" in\n> addition to \"git rev-list HEAD~3\". A lot of commands are driven by the\n> revision machinery and also accept this form. This addition to rebase\n> is just for convenience.\n>\n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> diff --git a/git-rebase.sh b/git-rebase.sh\n> index 5f6732b..33face1 100755\n> --- a/git-rebase.sh\n> +++ b/git-rebase.sh\n> @@ -342,6 +346,11 @@ do\n> esac\n> shift\n> done\n> +if [ -n \"$NUM\" ]\n\nWith the exception of one errant \"if [...]\", git-rebase.sh uniformly\nuses \"if test ...\".\n\n> +then\n> + test $# -gt 0 && usage\n> + set -- \"$@\" \"HEAD~$NUM\"\n> +fi\n> test $# -gt 2 && usage\n>\n> if test -n \"$cmd\" &&\n> diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh\n> index 6d94b1f..11db7ea 100755\n> --- a/t/t3400-rebase.sh\n> +++ b/t/t3400-rebase.sh\n> @@ -215,4 +215,10 @@ test_expect_success 'rebase commit with an ancient timestamp' '\n> grep \"author .* 34567 +0600$\" actual\n> '\n>\n> +test_expect_success 'rebase -' '\n> + git reset --hard &&\n> + test_must_fail git rebase -2 HEAD^^ &&\n> + git rebase -2\n> +'\n> +\n> test_done\n> --\n> 1.9.0.40.gaa8c3ea\n"},{"id":"235791","messageId":"CACsJy8DCpisoq698infq3X7Z1o8L_+zd1ai4-NCBXUpThvGcTQ@mail.gmail.com","threadId":"35974","inReplyTo":"CAPig+cTj1hBOFDLA5LecXwrVN4FG6pAzSDTAyLchHQbOkoEnEA@mail.gmail.com","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-02T08:45:25Z","receivedAt":"2014-03-02T08:45:25Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Sun, Mar 2, 2014 at 3:37 PM, Eric Sunshine wrote:\n> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n>> This is \"rev-list style\", where people can do \"git rev-list -3\" in\n>> addition to \"git rev-list HEAD~3\". A lot of commands are driven by the\n>> revision machinery and also accept this form. This addition to rebase\n>> is just for convenience.\n>>\n>> Signed-off-by: Nguyễn Thái Ngọc Duy \n>> ---\n>> diff --git a/git-rebase.sh b/git-rebase.sh\n>> index 5f6732b..33face1 100755\n>> --- a/git-rebase.sh\n>> +++ b/git-rebase.sh\n>> @@ -342,6 +346,11 @@ do\n>> esac\n>> shift\n>> done\n>> +if [ -n \"$NUM\" ]\n>\n> With the exception of one errant \"if [...]\", git-rebase.sh uniformly\n> uses \"if test ...\".\n\nBesides that and three more \"if [...]\" in git-rebase--interactive.sh,\ngit-rebase*.sh uses \"if test...\" only. Will reroll with a cleanup\npatch to make them all \"if test..\"\n-- \nDuy\n"},{"id":"235792","messageId":"CAPig+cSPKSsVG_yqaQfOCswaENKdUGrWt_YcQ3yZCpgG5jQ+JQ@mail.gmail.com","threadId":"35974","inReplyTo":"1393728794-29566-3-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2014-03-02T08:53:12Z","receivedAt":"2014-03-02T08:53:12Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n> This is \"rev-list style\", where people can do \"git rev-list -3\" in\n> addition to \"git rev-list HEAD~3\". A lot of commands are driven by the\n> revision machinery and also accept this form. This addition to rebase\n> is just for convenience.\n\nI'm seeing some pretty strange results with this. If I use -1, -2, or\n-3 then it rebases the expected commits, however, -4 gives me 9\ncommits, and -5 rebases 35 commits. Am I misunderstanding how this\nworks?\n\nI'm testing on a branch based on master with these three patches applied.\n\n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> Documentation/git-rebase.txt | 3 +++\n> git-rebase.sh | 9 +++++++++\n> t/t3400-rebase.sh | 6 ++++++\n> 3 files changed, 18 insertions(+)\n>\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 2a93c64..52c3561 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -223,6 +223,9 @@ 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> +-::\n> + Specify as \"HEAD~\".\n> +\n> ::\n> Upstream branch to compare against. May be any valid commit,\n> not just an existing branch name. Defaults to the configured\n> diff --git a/git-rebase.sh b/git-rebase.sh\n> index 5f6732b..33face1 100755\n> --- a/git-rebase.sh\n> +++ b/git-rebase.sh\n> @@ -43,6 +43,7 @@ continue! continue\n> abort! abort and check out the original branch\n> skip! skip current patch and continue\n> edit-todo! edit the todo list during an interactive rebase\n> +-NUM equivalent of HEAD~\n> \"\n> . git-sh-setup\n> . git-sh-i18n\n> @@ -335,6 +336,9 @@ do\n> --gpg-sign=*)\n> gpg_sign_opt=\"-S${1#--gpg-sign=}\"\n> ;;\n> + -NUM=*)\n> + NUM=\"${1#-NUM=}\"\n> + ;;\n> --)\n> shift\n> break\n> @@ -342,6 +346,11 @@ do\n> esac\n> shift\n> done\n> +if [ -n \"$NUM\" ]\n> +then\n> + test $# -gt 0 && usage\n> + set -- \"$@\" \"HEAD~$NUM\"\n> +fi\n> test $# -gt 2 && usage\n>\n> if test -n \"$cmd\" &&\n> diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh\n> index 6d94b1f..11db7ea 100755\n> --- a/t/t3400-rebase.sh\n> +++ b/t/t3400-rebase.sh\n> @@ -215,4 +215,10 @@ test_expect_success 'rebase commit with an ancient timestamp' '\n> grep \"author .* 34567 +0600$\" actual\n> '\n>\n> +test_expect_success 'rebase -' '\n> + git reset --hard &&\n> + test_must_fail git rebase -2 HEAD^^ &&\n> + git rebase -2\n> +'\n> +\n> test_done\n> --\n> 1.9.0.40.gaa8c3ea\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"235793","messageId":"CAPig+cSFWT6kwZUFFUE3=TcfHRUJnx54+fcZCzJwmOSJKFsYeA@mail.gmail.com","threadId":"35974","inReplyTo":"CAPig+cSPKSsVG_yqaQfOCswaENKdUGrWt_YcQ3yZCpgG5jQ+JQ@mail.gmail.com","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2014-03-02T08:55:01Z","receivedAt":"2014-03-02T08:55:01Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Mar 2, 2014 at 3:53 AM, Eric Sunshine wrote:\n> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n>> This is \"rev-list style\", where people can do \"git rev-list -3\" in\n>> addition to \"git rev-list HEAD~3\". A lot of commands are driven by the\n>> revision machinery and also accept this form. This addition to rebase\n>> is just for convenience.\n>\n> I'm seeing some pretty strange results with this. If I use -1, -2, or\n> -3 then it rebases the expected commits, however, -4 gives me 9\n> commits, and -5 rebases 35 commits. Am I misunderstanding how this\n> works?\n\nNevermind. I wasn't paying attention to the fact that I was attempting\nto rebase merges.\n"},{"id":"235794","messageId":"CAPig+cQ7pd4mQTTsT2Kq3KL-erUdncBsYmFjt8aFWB5THE6Srw@mail.gmail.com","threadId":"35974","inReplyTo":"1393728794-29566-4-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2014-03-02T09:04:47Z","receivedAt":"2014-03-02T09:04:47Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n> \"git rebase -e XYZ\" is basically the same as\n>\n> EDITOR=\"sed -i '1s/pick XYZ/edit XYZ/' $@\" \\\n> git rebase -i XYZ^\n>\n> In English, it prepares the todo list for you to edit only commit XYZ\n> to save your time. The time saving is only significant when you edit a\n> lot of commits separately.\n\nShould this accept multiple -e arguments? Based upon the above\njustification, it sounds like it should, and I think that would be the\nintuitive expectation (at least for me).\n\nThe current implementation, however, is broken with multiple -e arguments. With:\n\n git rebase -i -e older -e newer\n\n'newer' is ignored entirely. However, with:\n\n git rebase -i -e newer -e older\n\nit errors out when rewriting the todo list:\n\n \"expected to find 'edit older' line but did not\"\n\nAn implementation supporting multiple -e arguments would need to\nensure that the todo list extends to the \"oldest\" rev specified by any\n-e argument.\n\n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> Documentation/git-rebase.txt | 4 ++++\n> git-rebase--interactive.sh | 17 ++++++++++++++---\n> git-rebase.sh | 10 ++++++++++\n> 3 files changed, 28 insertions(+), 3 deletions(-)\n>\n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 52c3561..b8c263d 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -359,6 +359,10 @@ unless the `--fork-point` option is specified.\n> user edit that list before rebasing. This mode can also be used to\n> split commits (see SPLITTING COMMITS below).\n>\n> +-e::\n> +--edit-one::\n> + Prepare the todo list to edit only the commit at \n> +\n> -p::\n> --preserve-merges::\n> Instead of ignoring merges, try to recreate them.\n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index a1adae8..4762d57 100644\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -1040,9 +1040,20 @@ fi\n> has_action \"$todo\" ||\n> die_abort \"Nothing to do\"\n>\n> -cp \"$todo\" \"$todo\".backup\n> -git_sequence_editor \"$todo\" ||\n> - die_abort \"Could not execute editor\"\n> +if test -n \"$edit_one\"\n> +then\n> + edit_one=\"`git rev-parse --short $edit_one`\"\n> + sed \"1s/pick $edit_one /edit $edit_one /\" \"$todo\" > \"$todo.new\" ||\n> + die_abort \"failed to update todo list\"\n> + grep \"^edit $edit_one \" \"$todo.new\" >/dev/null ||\n> + die_abort \"expected to find 'edit $edit_one' line but did not\"\n> + mv \"$todo.new\" \"$todo\" ||\n> + die_abort \"failed to update todo list\"\n> +else\n> + cp \"$todo\" \"$todo\".backup\n> + git_sequence_editor \"$todo\" ||\n> + die_abort \"Could not execute editor\"\n> +fi\n>\n> has_action \"$todo\" ||\n> die_abort \"Nothing to do\"\n> diff --git a/git-rebase.sh b/git-rebase.sh\n> index 33face1..b8b6aa9 100755\n> --- a/git-rebase.sh\n> +++ b/git-rebase.sh\n> @@ -32,6 +32,7 @@ verify allow pre-rebase hook to run\n> rerere-autoupdate allow rerere to update index with resolved conflicts\n> root! rebase all reachable commits up to the root(s)\n> autosquash move commits that begin with squash!/fixup! under -i\n> +e,edit-one! generate todo list to edit this commit\n> committer-date-is-author-date! passed to 'git am'\n> ignore-date! passed to 'git am'\n> whitespace=! passed to 'git apply'\n> @@ -339,6 +340,10 @@ do\n> -NUM=*)\n> NUM=\"${1#-NUM=}\"\n> ;;\n> + --edit-one)\n> + interactive_rebase=explicit\n> + edit_one=t\n> + ;;\n> --)\n> shift\n> break\n> @@ -463,6 +468,11 @@ then\n> ;;\n> *) upstream_name=\"$1\"\n> shift\n> + if test -n \"$edit_one\"\n> + then\n> + edit_one=\"$upstream_name\"\n> + upstream_name=\"$upstream_name^\"\n> + fi\n> ;;\n> esac\n> upstream=$(peel_committish \"${upstream_name}\") ||\n> --\n> 1.9.0.40.gaa8c3ea\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n"},{"id":"235795","messageId":"CAPig+cS8XRf8LzajSJL7LVxVKb_cqLviwSimYyYXRWL46dh9QA@mail.gmail.com","threadId":"35974","inReplyTo":"CAPig+cQ7pd4mQTTsT2Kq3KL-erUdncBsYmFjt8aFWB5THE6Srw@mail.gmail.com","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2014-03-02T09:09:38Z","receivedAt":"2014-03-02T09:09:38Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sun, Mar 2, 2014 at 4:04 AM, Eric Sunshine wrote:\n> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n>> \"git rebase -e XYZ\" is basically the same as\n>>\n>> EDITOR=\"sed -i '1s/pick XYZ/edit XYZ/' $@\" \\\n>> git rebase -i XYZ^\n>>\n>> In English, it prepares the todo list for you to edit only commit XYZ\n>> to save your time. The time saving is only significant when you edit a\n>> lot of commits separately.\n>\n> Should this accept multiple -e arguments? Based upon the above\n> justification, it sounds like it should, and I think that would be the\n> intuitive expectation (at least for me).\n>\n> The current implementation, however, is broken with multiple -e arguments. With:\n>\n> git rebase -i -e older -e newer\n>\n> 'newer' is ignored entirely. However, with:\n>\n> git rebase -i -e newer -e older\n>\n> it errors out when rewriting the todo list:\n>\n> \"expected to find 'edit older' line but did not\"\n>\n> An implementation supporting multiple -e arguments would need to\n> ensure that the todo list extends to the \"oldest\" rev specified by any\n> -e argument.\n\nOf course, I'm misreading and abusing the intention of -e as if it is\n\"-e \".\n"},{"id":"235801","messageId":"vpqlhwsr3ww.fsf@anie.imag.fr","threadId":"35974","inReplyTo":"CAPig+cSFWT6kwZUFFUE3=TcfHRUJnx54+fcZCzJwmOSJKFsYeA@mail.gmail.com","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-03-02T15:55:27Z","receivedAt":"2014-03-02T15:55:27Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Eric Sunshine writes:\n\n> On Sun, Mar 2, 2014 at 3:53 AM, Eric Sunshine wrote:\n>> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n>>> This is \"rev-list style\", where people can do \"git rev-list -3\" in\n>>> addition to \"git rev-list HEAD~3\". A lot of commands are driven by the\n>>> revision machinery and also accept this form. This addition to rebase\n>>> is just for convenience.\n>>\n>> I'm seeing some pretty strange results with this. If I use -1, -2, or\n>> -3 then it rebases the expected commits, however, -4 gives me 9\n>> commits, and -5 rebases 35 commits. Am I misunderstanding how this\n>> works?\n>\n> Nevermind. I wasn't paying attention to the fact that I was attempting\n> to rebase merges.\n\nYour remark is actually interesting. Most (all?) Git commands taking\n- as parameters act on n commits, regardless of merges.\n\nSo, this commit creates an inconsistency between e.g. \"git log -3\" (show\nlast 3 commits) and \"git rebase -3\" (rebase up to HEAD~3, but there may\nbe more commits in case there are merges).\n\nI don't have a better proposal, but at least the inconsistancy should be\ndocumented (e.g. \"note that this is different from what other commands\nlike 'git log' do when used with a - option since ...\" in the\nmanpage).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235853","messageId":"53144881.6090702@alum.mit.edu","threadId":"35974","inReplyTo":"vpqlhwsr3ww.fsf@anie.imag.fr","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-03-03T09:16:49Z","receivedAt":"2014-03-03T09:16:49Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/02/2014 04:55 PM, Matthieu Moy wrote:\n> Eric Sunshine writes:\n> \n>> On Sun, Mar 2, 2014 at 3:53 AM, Eric Sunshine wrote:\n>>> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n>>>> This is \"rev-list style\", where people can do \"git rev-list -3\" in\n>>>> addition to \"git rev-list HEAD~3\". A lot of commands are driven by the\n>>>> revision machinery and also accept this form. This addition to rebase\n>>>> is just for convenience.\n>>>\n>>> I'm seeing some pretty strange results with this. If I use -1, -2, or\n>>> -3 then it rebases the expected commits, however, -4 gives me 9\n>>> commits, and -5 rebases 35 commits. Am I misunderstanding how this\n>>> works?\n>>\n>> Nevermind. I wasn't paying attention to the fact that I was attempting\n>> to rebase merges.\n> \n> Your remark is actually interesting. Most (all?) Git commands taking\n> - as parameters act on n commits, regardless of merges.\n> \n> So, this commit creates an inconsistency between e.g. \"git log -3\" (show\n> last 3 commits) and \"git rebase -3\" (rebase up to HEAD~3, but there may\n> be more commits in case there are merges).\n> \n> I don't have a better proposal, but at least the inconsistancy should be\n> documented (e.g. \"note that this is different from what other commands\n> like 'git log' do when used with a - option since ...\" in the\n> manpage).\n\nThis might be a reason that \"-NUM\" is a bad idea.\n\nOr perhaps \"-NUM\" should fail with an error message if any of the last\nNUM commits are merges. In that restricted scenario (which probably\naccounts for 99% of rebases), \"-NUM\" is equivalent to \"HEAD~NUM\".\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235856","messageId":"vpq7g8bfws8.fsf@anie.imag.fr","threadId":"35974","inReplyTo":"53144881.6090702@alum.mit.edu","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-03-03T09:37:11Z","receivedAt":"2014-03-03T09:37:11Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Michael Haggerty writes:\n\n> Or perhaps \"-NUM\" should fail with an error message if any of the last\n> NUM commits are merges. In that restricted scenario (which probably\n> accounts for 99% of rebases), \"-NUM\" is equivalent to \"HEAD~NUM\".\n\nMakes sense to me. So, -NUM would actually mean \"rebase the last NUM\ncommits\" (as well as being an alias for HEAD~NUM), but would fail when\nit does not make sense (with an error message explaining the situation\nand pointing the user to HEAD~N if this is what he wanted).\n\nThis would actually be a feature for me: I often want to rebase \"recent\nenough\" history, and when my @{upstream} isn't well positionned, I\nrandomly type HEAD~N without remembering what N should be. When N is too\nsmall, the rebase doesn't reach the interesting commit, and when N is\ntoo big, it reaches a merge commit and I get a bunch of commits I'm not\nallowed to edit in my todo-list. Then I have to abort the commit\nmanually. With -N failing on merge commits, the rebase would abort\nitself automatically.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235859","messageId":"CACsJy8CPhTQxpnY70PxD9zFSipaJCTQPBsmReD8E9tmEgsvTRg@mail.gmail.com","threadId":"35974","inReplyTo":"vpq7g8bfws8.fsf@anie.imag.fr","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-03T10:04:27Z","receivedAt":"2014-03-03T10:04:27Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Mar 3, 2014 at 4:37 PM, Matthieu Moy\n wrote:\n> Michael Haggerty writes:\n>\n>> Or perhaps \"-NUM\" should fail with an error message if any of the last\n>> NUM commits are merges. In that restricted scenario (which probably\n>> accounts for 99% of rebases), \"-NUM\" is equivalent to \"HEAD~NUM\".\n>\n> Makes sense to me. So, -NUM would actually mean \"rebase the last NUM\n> commits\" (as well as being an alias for HEAD~NUM), but would fail when\n> it does not make sense (with an error message explaining the situation\n> and pointing the user to HEAD~N if this is what he wanted).\n\nAgreed, but..\n\n> This would actually be a feature for me: I often want to rebase \"recent\n> enough\" history, and when my @{upstream} isn't well positionned, I\n> randomly type HEAD~N without remembering what N should be. When N is too\n> small, the rebase doesn't reach the interesting commit, and when N is\n> too big, it reaches a merge commit and I get a bunch of commits I'm not\n> allowed to edit in my todo-list. Then I have to abort the commit\n> manually. With -N failing on merge commits, the rebase would abort\n> itself automatically.\n\nwould \"git rebase -i --fork-point\" be what you need instead? It's a\nnew thing, but may be what we actually should use, not this -NUM..\n-- \nDuy\n"},{"id":"235860","messageId":"53145523.7020900@alum.mit.edu","threadId":"35974","inReplyTo":"CAPig+cS8XRf8LzajSJL7LVxVKb_cqLviwSimYyYXRWL46dh9QA@mail.gmail.com","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-03-03T10:10:43Z","receivedAt":"2014-03-03T10:10:43Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/02/2014 10:09 AM, Eric Sunshine wrote:\n> On Sun, Mar 2, 2014 at 4:04 AM, Eric Sunshine wrote:\n>> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n>>> \"git rebase -e XYZ\" is basically the same as\n>>>\n>>> EDITOR=\"sed -i '1s/pick XYZ/edit XYZ/' $@\" \\\n>>> git rebase -i XYZ^\n>>>\n>>> In English, it prepares the todo list for you to edit only commit XYZ\n>>> to save your time. The time saving is only significant when you edit a\n>>> lot of commits separately.\n>>\n>> Should this accept multiple -e arguments? Based upon the above\n>> justification, it sounds like it should, and I think that would be the\n>> intuitive expectation (at least for me).\n>>\n>> The current implementation, however, is broken with multiple -e arguments. With:\n>>\n>> git rebase -i -e older -e newer\n>>\n>> 'newer' is ignored entirely. However, with:\n>>\n>> git rebase -i -e newer -e older\n>>\n>> it errors out when rewriting the todo list:\n>>\n>> \"expected to find 'edit older' line but did not\"\n>>\n>> An implementation supporting multiple -e arguments would need to\n>> ensure that the todo list extends to the \"oldest\" rev specified by any\n>> -e argument.\n> \n> Of course, I'm misreading and abusing the intention of -e as if it is\n> \"-e \".\n\nI think that your misreading is more consistent than the feature as\nimplemented.\n\n git rebase -e OLDER\n\ndoes not mean \"do 'git rebase -i OLDER' and oh, by the way, also set up\ncommit OLDER to be edited\". It means \"do 'git rebase -i OLDER^' ...\"\n(note: \"OLDER^\" and not \"OLDER\"). So it is confusing to think as \"-e\"\nas a modifier on an otherwise normal \"git rebase -i\" invocation.\nRather, it seems to me that \"-e\" and \"-i\" should be mutually exclusive\n(and consider it an implementation detail that the former is implemented\nusing the latter).\n\nAnd if that is our point of view, then is perfectly logical to allow it\nto be specified multiple times. OTOH there is no reason that v1 has to\nallow multiple \"-e\", as long as it properly rejects that usage.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235867","messageId":"87y50rlhgt.fsf@fencepost.gnu.org","threadId":"35974","inReplyTo":"CACsJy8CPhTQxpnY70PxD9zFSipaJCTQPBsmReD8E9tmEgsvTRg@mail.gmail.com","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-03-03T10:11:30Z","receivedAt":"2014-03-03T10:11:30Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Duy Nguyen writes:\n\n> On Mon, Mar 3, 2014 at 4:37 PM, Matthieu Moy\n> wrote:\n>> Michael Haggerty writes:\n>>\n>>> Or perhaps \"-NUM\" should fail with an error message if any of the last\n>>> NUM commits are merges. In that restricted scenario (which probably\n>>> accounts for 99% of rebases), \"-NUM\" is equivalent to \"HEAD~NUM\".\n>>\n>> Makes sense to me. So, -NUM would actually mean \"rebase the last NUM\n>> commits\" (as well as being an alias for HEAD~NUM), but would fail when\n>> it does not make sense (with an error message explaining the situation\n>> and pointing the user to HEAD~N if this is what he wanted).\n>\n> Agreed, but..\n>\n>> This would actually be a feature for me: I often want to rebase \"recent\n>> enough\" history, and when my @{upstream} isn't well positionned, I\n>> randomly type HEAD~N without remembering what N should be. When N is too\n>> small, the rebase doesn't reach the interesting commit, and when N is\n>> too big, it reaches a merge commit and I get a bunch of commits I'm not\n>> allowed to edit in my todo-list. Then I have to abort the commit\n>> manually. With -N failing on merge commits, the rebase would abort\n>> itself automatically.\n>\n> would \"git rebase -i --fork-point\" be what you need instead? It's a\n> new thing, but may be what we actually should use, not this -NUM..\n\n-0 might be a good mnemonic for --fork-point, though.\n\nOf course, when using --preserve-merges explicitly it would appear that\n-NUM should not error out.\n\n-- \nDavid Kastrup\n"},{"id":"235861","messageId":"vpqvbvvegli.fsf@anie.imag.fr","threadId":"35974","inReplyTo":"CACsJy8CPhTQxpnY70PxD9zFSipaJCTQPBsmReD8E9tmEgsvTRg@mail.gmail.com","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-03-03T10:12:09Z","receivedAt":"2014-03-03T10:12:09Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Duy Nguyen writes:\n\n> On Mon, Mar 3, 2014 at 4:37 PM, Matthieu Moy\n>\n>> This would actually be a feature for me: I often want to rebase \"recent\n>> enough\" history, and when my @{upstream} isn't well positionned, I\n>> randomly type HEAD~N without remembering what N should be. When N is too\n>> small, the rebase doesn't reach the interesting commit, and when N is\n>> too big, it reaches a merge commit and I get a bunch of commits I'm not\n>> allowed to edit in my todo-list. Then I have to abort the commit\n>> manually. With -N failing on merge commits, the rebase would abort\n>> itself automatically.\n>\n> would \"git rebase -i --fork-point\" be what you need instead?\n\nI don't think so. My use case is when I did a manual merge, so\n@{upstream} is helpless or even not positionned. There is for sure an\naccurate command (remember the branch I just merged and put it on the\ncommand-line), but my fingers prefer typing quick and dirty commands and\nhope I won't get too many trial and error cycles ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235862","messageId":"20140303101303.GA23977@sigill.intra.peff.net","threadId":"35974","inReplyTo":"vpq7g8bfws8.fsf@anie.imag.fr","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-03-03T10:13:03Z","receivedAt":"2014-03-03T10:13:03Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 03, 2014 at 10:37:11AM +0100, Matthieu Moy wrote:\n\n> Michael Haggerty writes:\n> \n> > Or perhaps \"-NUM\" should fail with an error message if any of the last\n> > NUM commits are merges. In that restricted scenario (which probably\n> > accounts for 99% of rebases), \"-NUM\" is equivalent to \"HEAD~NUM\".\n> \n> Makes sense to me. So, -NUM would actually mean \"rebase the last NUM\n> commits\" (as well as being an alias for HEAD~NUM), but would fail when\n> it does not make sense (with an error message explaining the situation\n> and pointing the user to HEAD~N if this is what he wanted).\n\nYeah, I agree with this. I think \"-NUM\" is only useful for linear\nstring-of-pearls history. With merges, it either means:\n\n - linearize history (a la git-log), go back NUM commits, and treat the\n result as the upstream. This is useless, because it's difficult to\n predict where you're going to end up. Using explicit \"~\" and \"^\"\n relative-commit operators to specify the upstream is more flexible\n if you really want to do this (but I don't know why you would).\n\n - do not use an UNINTERESTING upstream as the cutoff, but instead\n try to rebase exactly NUM commits. In the face of non-linear\n history, I'm not even sure what this would mean, or how we would\n implement it.\n\nNeither of those is useful, so I don't think erroring out on them is a\nbad thing. And by erroring out (rather than documenting some weird and\nuseless behavior), we don't have to worry about backwards compatibility\nif we later _do_ come up with a useful behavior (the best I can think of\nis that \"--first-parent -3\" might have a use, but I think that should\nalready be covered, as the results of --first-parent are by-definition\nlinear).\n\n> This would actually be a feature for me: I often want to rebase \"recent\n> enough\" history, and when my @{upstream} isn't well positionned, I\n> randomly type HEAD~N without remembering what N should be. When N is too\n> small, the rebase doesn't reach the interesting commit, and when N is\n> too big, it reaches a merge commit and I get a bunch of commits I'm not\n> allowed to edit in my todo-list. Then I have to abort the commit\n> manually. With -N failing on merge commits, the rebase would abort\n> itself automatically.\n\nI do the same thing.\n\n-Peff\n"},{"id":"235863","messageId":"CACsJy8DQz-74QJCOq8O7pZG3BwsyzoLhayxmALv6LjaFYWP4YQ@mail.gmail.com","threadId":"35974","inReplyTo":"53145523.7020900@alum.mit.edu","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-03T10:15:46Z","receivedAt":"2014-03-03T10:15:46Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Mon, Mar 3, 2014 at 5:10 PM, Michael Haggerty wrote:\n> On 03/02/2014 10:09 AM, Eric Sunshine wrote:\n>> On Sun, Mar 2, 2014 at 4:04 AM, Eric Sunshine wrote:\n>>> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n>>>> \"git rebase -e XYZ\" is basically the same as\n>>>>\n>>>> EDITOR=\"sed -i '1s/pick XYZ/edit XYZ/' $@\" \\\n>>>> git rebase -i XYZ^\n>>>>\n>>>> In English, it prepares the todo list for you to edit only commit XYZ\n>>>> to save your time. The time saving is only significant when you edit a\n>>>> lot of commits separately.\n>>>\n>>> Should this accept multiple -e arguments? Based upon the above\n>>> justification, it sounds like it should, and I think that would be the\n>>> intuitive expectation (at least for me).\n>>>\n>>> The current implementation, however, is broken with multiple -e arguments. With:\n>>>\n>>> git rebase -i -e older -e newer\n>>>\n>>> 'newer' is ignored entirely. However, with:\n>>>\n>>> git rebase -i -e newer -e older\n>>>\n>>> it errors out when rewriting the todo list:\n>>>\n>>> \"expected to find 'edit older' line but did not\"\n>>>\n>>> An implementation supporting multiple -e arguments would need to\n>>> ensure that the todo list extends to the \"oldest\" rev specified by any\n>>> -e argument.\n>>\n>> Of course, I'm misreading and abusing the intention of -e as if it is\n>> \"-e \".\n>\n> I think that your misreading is more consistent than the feature as\n> implemented.\n>\n> git rebase -e OLDER\n>\n> does not mean \"do 'git rebase -i OLDER' and oh, by the way, also set up\n> commit OLDER to be edited\". It means \"do 'git rebase -i OLDER^' ...\"\n> (note: \"OLDER^\" and not \"OLDER\"). So it is confusing to think as \"-e\"\n> as a modifier on an otherwise normal \"git rebase -i\" invocation.\n> Rather, it seems to me that \"-e\" and \"-i\" should be mutually exclusive\n> (and consider it an implementation detail that the former is implemented\n> using the latter).\n>\n> And if that is our point of view, then is perfectly logical to allow it\n> to be specified multiple times.\n\nLogically, yes. Practically, no. If you have to put multiple -e and\nsome hashes in one line, wouldn't editing to-do list in your favorite\neditor be faster?\n\n> OTOH there is no reason that v1 has to\n> allow multiple \"-e\", as long as it properly rejects that usage.\n-- \nDuy\n"},{"id":"235868","messageId":"87ppm3lg8t.fsf@fencepost.gnu.org","threadId":"35974","inReplyTo":"CACsJy8DQz-74QJCOq8O7pZG3BwsyzoLhayxmALv6LjaFYWP4YQ@mail.gmail.com","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2014-03-03T10:37:54Z","receivedAt":"2014-03-03T10:37:54Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Duy Nguyen writes:\n\n> Logically, yes. Practically, no. If you have to put multiple -e and\n> some hashes in one line, wouldn't editing to-do list in your favorite\n> editor be faster?\n\nAn editor is the last resort when the card puncher is broken.\n\n-- \nDavid Kastrup\n"},{"id":"235917","messageId":"CAPig+cTn-YcWHsGRKUZWqACJ5ZspWoB+f4i7hNj09_4Ci6odiw@mail.gmail.com","threadId":"35974","inReplyTo":"1393728794-29566-4-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2014-03-03T20:28:52Z","receivedAt":"2014-03-03T20:28:52Z","isPatch":true,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n> \"git rebase -e XYZ\" is basically the same as\n>\n> EDITOR=\"sed -i '1s/pick XYZ/edit XYZ/' $@\" \\\n> git rebase -i XYZ^\n>\n> In English, it prepares the todo list for you to edit only commit XYZ\n> to save your time. The time saving is only significant when you edit a\n> lot of commits separately.\n\nIs it correct to single out only \"edit\" for special treatment? If\nallowing \"edit\" on the command-line, then shouldn't command-line\n\"reword\" also be supported? I, for one, often need to reword a commit\nmessage (or two or three); far more frequently than I need to edit a\ncommit.\n\n(This is a genuine question about perceived favoritism of \"edit\", as\nopposed to a request to further bloat the interface.)\n"},{"id":"235924","messageId":"xmqqlhwrneje.fsf@gitster.dls.corp.google.com","threadId":"35974","inReplyTo":"53144881.6090702@alum.mit.edu","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-03T21:44:05Z","receivedAt":"2014-03-03T21:44:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> This might be a reason that \"-NUM\" is a bad idea.\n>\n> Or perhaps \"-NUM\" should fail with an error message if any of the last\n> NUM commits are merges. In that restricted scenario (which probably\n> accounts for 99% of rebases), \"-NUM\" is equivalent to \"HEAD~NUM\".\n\nThat sounds like one possible way out; the opposite would be to\nenable mode that preserges merges when we see any.\n\nIf \"rebase\" had a \"--first-parent\" mode that simply replays only the\ncommits on the first parent chain, merging the same second and later\nparents without looking at their history when dealing with merge\ncommits, and always used that mode unless \"--flatten-history\" was\ngiven, the world might have been a better place. We cannot go there\nin a single step, but we could plan such a backward incompatible\nmigration if we wanted to.\n"},{"id":"235925","messageId":"xmqqha7fnebn.fsf@gitster.dls.corp.google.com","threadId":"35974","inReplyTo":"vpq7g8bfws8.fsf@anie.imag.fr","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-03T21:48:44Z","receivedAt":"2014-03-03T21:48:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> Michael Haggerty writes:\n>\n>> Or perhaps \"-NUM\" should fail with an error message if any of the last\n>> NUM commits are merges. In that restricted scenario (which probably\n>> accounts for 99% of rebases), \"-NUM\" is equivalent to \"HEAD~NUM\".\n>\n> Makes sense to me. So, -NUM would actually mean \"rebase the last NUM\n> commits\" (as well as being an alias for HEAD~NUM), but would fail when\n> it does not make sense (with an error message explaining the situation\n> and pointing the user to HEAD~N if this is what he wanted).\n>\n> This would actually be a feature for me: I often want to rebase \"recent\n> enough\" history, and when my @{upstream} isn't well positionned,...\n\nCould you elaborate on this a bit? What does \"isn't well\npositioned\" mean? Do you mean \"the upstream has advanced but there\nis no reason for my topic to build on that---I'd rather want to make\nsure I can view 'diff @{1} HEAD' and understand what my changes\nbefore the rebase was\"? That is, what you really want is\n\n\tgit rebase -i --onto $(git merge-base @{upstream} HEAD) @{upstream}\n\nbut that is too long to type?\n\nIf it is very common (and I suspect it is), we may want to support\nsuch a short-hand---the above does not make any sense without '-i',\nbut I would say with '-i' you do not want to reBASE on an updated\nbase most of the time. \"git rebase -i @{upstream}...HEAD\" or\nsomething?\n"},{"id":"235943","messageId":"vpqlhwqc3g0.fsf@anie.imag.fr","threadId":"35974","inReplyTo":"xmqqha7fnebn.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH 2/3] rebase: accept - as another way of saying HEAD~","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-03-03T22:39:11Z","receivedAt":"2014-03-03T22:39:11Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano writes:\n\n> Matthieu Moy writes:\n>\n>> Michael Haggerty writes:\n>>\n>>> Or perhaps \"-NUM\" should fail with an error message if any of the last\n>>> NUM commits are merges. In that restricted scenario (which probably\n>>> accounts for 99% of rebases), \"-NUM\" is equivalent to \"HEAD~NUM\".\n>>\n>> Makes sense to me. So, -NUM would actually mean \"rebase the last NUM\n>> commits\" (as well as being an alias for HEAD~NUM), but would fail when\n>> it does not make sense (with an error message explaining the situation\n>> and pointing the user to HEAD~N if this is what he wanted).\n>>\n>> This would actually be a feature for me: I often want to rebase \"recent\n>> enough\" history, and when my @{upstream} isn't well positionned,...\n>\n> Could you elaborate on this a bit? What does \"isn't well\n> positioned\" mean?\n\nThe most common case is when @{upstream} is not positionned at all,\nbecause I'm on a temporary branch on which I did not configure it. The\nother case is when I did a manual merge of a branch other than upstream.\n\nAs I said in another message, there would probably be cleaner solutions,\nbut the trial and error one does not work that bad.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"235972","messageId":"CACsJy8Ct41PRb=_Ez7FLXbdiZkTU-tFYqtAxow9mCw7wYAfOhg@mail.gmail.com","threadId":"35974","inReplyTo":"CAPig+cTn-YcWHsGRKUZWqACJ5ZspWoB+f4i7hNj09_4Ci6odiw@mail.gmail.com","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-04T02:08:31Z","receivedAt":"2014-03-04T02:08:31Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 4, 2014 at 3:28 AM, Eric Sunshine wrote:\n> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n>> \"git rebase -e XYZ\" is basically the same as\n>>\n>> EDITOR=\"sed -i '1s/pick XYZ/edit XYZ/' $@\" \\\n>> git rebase -i XYZ^\n>>\n>> In English, it prepares the todo list for you to edit only commit XYZ\n>> to save your time. The time saving is only significant when you edit a\n>> lot of commits separately.\n>\n> Is it correct to single out only \"edit\" for special treatment? If\n> allowing \"edit\" on the command-line, then shouldn't command-line\n> \"reword\" also be supported? I, for one, often need to reword a commit\n> message (or two or three); far more frequently than I need to edit a\n> commit.\n>\n> (This is a genuine question about perceived favoritism of \"edit\", as\n> opposed to a request to further bloat the interface.)\n\nHeh I had the same thought yesterday. The same thing could be asked\nfor \"git commit --fixup\" to send us back to the fixed up commit so we\ncan do something about it. If we go along that line, then \"git commit\"\nmay be a better interface to reword older commits..\n-- \nDuy\n"},{"id":"235980","messageId":"53159601.8020702@alum.mit.edu","threadId":"35974","inReplyTo":"CACsJy8Ct41PRb=_Ez7FLXbdiZkTU-tFYqtAxow9mCw7wYAfOhg@mail.gmail.com","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-03-04T08:59:45Z","receivedAt":"2014-03-04T08:59:45Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/04/2014 03:08 AM, Duy Nguyen wrote:\n> On Tue, Mar 4, 2014 at 3:28 AM, Eric Sunshine wrote:\n>> On Sat, Mar 1, 2014 at 9:53 PM, Nguyễn Thái Ngọc Duy wrote:\n>>> \"git rebase -e XYZ\" is basically the same as\n>>>\n>>> EDITOR=\"sed -i '1s/pick XYZ/edit XYZ/' $@\" \\\n>>> git rebase -i XYZ^\n>>>\n>>> In English, it prepares the todo list for you to edit only commit XYZ\n>>> to save your time. The time saving is only significant when you edit a\n>>> lot of commits separately.\n>>\n>> Is it correct to single out only \"edit\" for special treatment? If\n>> allowing \"edit\" on the command-line, then shouldn't command-line\n>> \"reword\" also be supported? I, for one, often need to reword a commit\n>> message (or two or three); far more frequently than I need to edit a\n>> commit.\n>>\n>> (This is a genuine question about perceived favoritism of \"edit\", as\n>> opposed to a request to further bloat the interface.)\n> \n> Heh I had the same thought yesterday. The same thing could be asked\n> for \"git commit --fixup\" to send us back to the fixed up commit so we\n> can do something about it. If we go along that line, then \"git commit\"\n> may be a better interface to reword older commits..\n\nI disagree. \"git commit --fixup\" doesn't rewrite history. It just adds\na new commit with a special commit message that will make it easier to\nrewrite history later. I think it would be prudent to keep the\nhistory-rewriting functionality segregated in \"git rebase\", which users\nalready know they have to use with care [1].\n\nBut the next question is whether \"git rebase\" should have shortcuts for\n*most* of its line commands. All of the following seem to make sense:\n\n git rebase --edit COMMIT\n\n A long-form for the -e option we have been talking about.\n It is unfortunately that this spelling sounds like the\n \"--edit\" option on \"git commit --edit\" and \"git merge --edit\",\n so people might use it when they really mean\n \"git rebase --reword COMMIT\".\n\n git rebase --reword COMMIT\n git rebase --fixup COMMIT\n git rebase --squash COMMIT\n\n git rebase --kill COMMIT\n\n Remove the commit from history, like running \"git rebase\n --interactive\" then deleting that line.\n\nI'm quite confident that I would use all of these commands.\n\nMoreover, it would logically be reasonable to allow multiple of these\noptions, at least as long as they have distinct COMMIT arguments.\nThough, as Duy points out, it might in practice be easier to edit the\ntodo list in an editor rather than trying to do multiple \"edits\" at a\ntime via the command line.\n\nSome thought would have to go into the question of if/how these commands\nshould interact with \"git rebase --autosquash\" (which, don't forget, can\nalso be requested via rebase.autosquash).\n\nMichael\n\n[1] OK, granted, there is \"git commit --amend\", which rewrites history\ntoo. But it rewrites only the last commit, which is less likely to be\nproblematic.\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"235986","messageId":"CACsJy8CSaAnVrFnhxRd=jPmXCat5AObNRLKzCesbdx3JS83PnA@mail.gmail.com","threadId":"35974","inReplyTo":"53159601.8020702@alum.mit.edu","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-04T10:24:49Z","receivedAt":"2014-03-04T10:24:49Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Mar 4, 2014 at 3:59 PM, Michael Haggerty wrote:\n>> On Tue, Mar 4, 2014 at 3:28 AM, Eric Sunshine wrote:\n>>> Is it correct to single out only \"edit\" for special treatment? If\n>>> allowing \"edit\" on the command-line, then shouldn't command-line\n>>> \"reword\" also be supported? I, for one, often need to reword a commit\n>>> message (or two or three); far more frequently than I need to edit a\n>>> commit.\n>>>\n>>> (This is a genuine question about perceived favoritism of \"edit\", as\n>>> opposed to a request to further bloat the interface.)\n>>\n>> Heh I had the same thought yesterday. The same thing could be asked\n>> for \"git commit --fixup\" to send us back to the fixed up commit so we\n>> can do something about it. If we go along that line, then \"git commit\"\n>> may be a better interface to reword older commits..\n>\n> I disagree. \"git commit --fixup\" doesn't rewrite history. It just adds\n> a new commit with a special commit message that will make it easier to\n> rewrite history later. I think it would be prudent to keep the\n> history-rewriting functionality segregated in \"git rebase\", which users\n> already know they have to use with care [1].\n\nJust to be clear I didn't mean to modify --fixup behavior. It could be\n--amend-old-commit or something like that. It's actually --amend that\nmade me want to put the UI in \"git commit\". But it's a bad idea\n(besides what you pointed out) because after you're done, you still\nneed to do \"git rebase --continue\".\n\n> But the next question is whether \"git rebase\" should have shortcuts for\n> *most* of its line commands. All of the following seem to make sense:\n>\n> git rebase --edit COMMIT\n>\n> A long-form for the -e option we have been talking about.\n> It is unfortunately that this spelling sounds like the\n> \"--edit\" option on \"git commit --edit\" and \"git merge --edit\",\n> so people might use it when they really mean\n> \"git rebase --reword COMMIT\".\n>\n> git rebase --reword COMMIT\n\nSounds good.\n\n> git rebase --fixup COMMIT\n> git rebase --squash COMMIT\n\nThis is not interactive (except when merge conflicts occur), is it?\n\nA bit off topic. I sometimes want to fix up a commit and make it stop\nthere for me to test it again but there is no such command, is there?\nMaybe we could add support for \"fixup/edit\" (or \"fe\" for short) and\n\"squash/edit\" (\"se\"). Not really familiar with the code base to do\nthat myself quickly though.\n\n> git rebase --kill COMMIT\n>\n> Remove the commit from history, like running \"git rebase\n> --interactive\" then deleting that line.\n\nYes! Done this sometimes (not so often) but a definitely nice thing to\nhave. I'd go with --remove or --delete though.\n-- \nDuy\n"},{"id":"235990","messageId":"5315D0E9.4070408@alum.mit.edu","threadId":"35974","inReplyTo":"CACsJy8CSaAnVrFnhxRd=jPmXCat5AObNRLKzCesbdx3JS83PnA@mail.gmail.com","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-03-04T13:11:05Z","receivedAt":"2014-03-04T13:11:05Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/04/2014 11:24 AM, Duy Nguyen wrote:\n> On Tue, Mar 4, 2014 at 3:59 PM, Michael Haggerty wrote:\n>> git rebase --fixup COMMIT\n>> git rebase --squash COMMIT\n> \n> This is not interactive (except when merge conflicts occur), is it?\n\n--fixup would not be interactive (is that a problem?), but --squash does\nopen an editor to allow you to merge the commit messages.\n\n> A bit off topic. I sometimes want to fix up a commit and make it stop\n> there for me to test it again but there is no such command, is there?\n> Maybe we could add support for \"fixup/edit\" (or \"fe\" for short) and\n> \"squash/edit\" (\"se\"). Not really familiar with the code base to do\n> that myself quickly though.\n\nMaybe we should allow \"edit\" to appear on a line by itself, without a\nSHA-1, in which case it would stop after all previous lines had been\nprocessed. Then you could change one line to \"fixup\" or \"squash\", and\nthen add a blank \"edit\" line after it. Though there is no really\nobvious way to do this using the hypothetical new command line options\nthat we have been discussing.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"236016","messageId":"xmqqiortlsxl.fsf@gitster.dls.corp.google.com","threadId":"35974","inReplyTo":"1393728794-29566-2-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH 1/3] rev-parse: support OPT_NUMBER_CALLBACK in --parseopt","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-04T18:28:22Z","receivedAt":"2014-03-04T18:28:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> If the option spec is\n>\n> -NUM Help string\n>\n> then rev-parse will accept and parse -([0-9]+) and return \"-NUM $1\"\n\nEven though the hardcoded \"NUM\" token initially gave me a knee-jerk\n\"Yuck\" reaction, that literal option name is very unlikely to be\ndesired by scripts/commands for their real option names, and being\nin all uppercase it is very clear that it is magic convention\nbetween the parsing mechanism and the script it uses.\n\nIt however felt funny to me without a matching (possibly hidden)\nmechanism to allow parse-options machinery to consume such an output\nas its input. In a script that uses this mechanism to parse out the\nnumeric option \"-NUM 3\" out of \"git script -3\" and uses that \"three\"\nto drive an underlying command (e.g. \"git grep -3\"), wouldn't it be\nmore natural if that underlying command can be told to accept the\nsame notation (i.e. \"git grep -NUM 3\")? For that to be consistent\nwith the rest of the system, \"-NUM\" would not be a good token; being\nit multi-character, it must be \"--NUM\" or something with double-dash\nprefix.\n\nI kind of like the basic idea, the capability it tries to give\nscripted Porcelain implementations. But my impression is that\n\"rebase -i -4\", which this mechanism was invented for, is not\nprogressing, so perhaps we should wait until the real user of this\nfeature appears.\n\nThanks.\n\n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> builtin/rev-parse.c | 9 +++++++--\n> 1 file changed, 7 insertions(+), 2 deletions(-)\n>\n> diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c\n> index 45901df..b37676f 100644\n> --- a/builtin/rev-parse.c\n> +++ b/builtin/rev-parse.c\n> @@ -331,6 +331,8 @@ static int parseopt_dump(const struct option *o, const char *arg, int unset)\n> \tstruct strbuf *parsed = o->value;\n> \tif (unset)\n> \t\tstrbuf_addf(parsed, \" --no-%s\", o->long_name);\n> +\telse if (o->type == OPTION_NUMBER)\n> +\t\tstrbuf_addf(parsed, \" -NUM\");\n> \telse if (o->short_name && (o->long_name == NULL || !stuck_long))\n> \t\tstrbuf_addf(parsed, \" -%c\", o->short_name);\n> \telse\n> @@ -338,7 +340,7 @@ static int parseopt_dump(const struct option *o, const char *arg, int unset)\n> \tif (arg) {\n> \t\tif (!stuck_long)\n> \t\t\tstrbuf_addch(parsed, ' ');\n> -\t\telse if (o->long_name)\n> +\t\telse if (o->long_name || o->type == OPTION_NUMBER)\n> \t\t\tstrbuf_addch(parsed, '=');\n> \t\tsq_quote_buf(parsed, arg);\n> \t}\n> @@ -439,7 +441,10 @@ static int cmd_parseopt(int argc, const char **argv, const char *prefix)\n> \n> \t\tif (s - sb.buf == 1) /* short option only */\n> \t\t\to->short_name = *sb.buf;\n> -\t\telse if (sb.buf[1] != ',') /* long option only */\n> +\t\telse if (s - sb.buf == 4 && !strncmp(sb.buf, \"-NUM\", 4)) {\n> +\t\t\to->type = OPTION_NUMBER;\n> +\t\t\to->flags = PARSE_OPT_NOARG | PARSE_OPT_NONEG;\n> +\t\t} else if (sb.buf[1] != ',') /* long option only */\n> \t\t\to->long_name = xmemdupz(sb.buf, s - sb.buf);\n> \t\telse {\n> \t\t\to->short_name = *sb.buf;\n"},{"id":"236017","messageId":"xmqqeh2hlsiu.fsf@gitster.dls.corp.google.com","threadId":"35974","inReplyTo":"53159601.8020702@alum.mit.edu","subject":"Re: [PATCH 3/3] rebase: new convenient option to edit a single commit","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-03-04T18:37:13Z","receivedAt":"2014-03-04T18:37:13Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> ... All of the following seem to make sense:\n>\n> git rebase --edit COMMIT\n>\n> A long-form for the -e option we have been talking about.\n> It is unfortunately that this spelling sounds like the\n> \"--edit\" option on \"git commit --edit\" and \"git merge --edit\",\n> so people might use it when they really mean\n> \"git rebase --reword COMMIT\".\n\nI agree, so the \"--edit\" does *not* make sense as it invites confusion.\n\n> git rebase --reword COMMIT\n\nYes, that would make sense.\n\n> git rebase --fixup COMMIT\n> git rebase --squash COMMIT\n\nI am not sure about these. What does it even mean to \"--fixup\" (or\n\"--squash\" for that matter) a single commit without specifying what\nit is squashed into? Or are you assuming that all of these is only\nto affect pre-populated rebase-i insn sheet that is to be further\nedited before the actual rebasing starts? I somehow had an impression\nthat the reason to have these new options is to skip the editing of\nthe insn sheet in the editor altogether.\n\n> git rebase --kill COMMIT\n\nThis _does_ make sense under my assumption: \"remove this commit from\nthe insn-sheet and go ahead with it, without bothering me to edit\nthe insn-sheet further\".\n\n> I'm quite confident that I would use all of these commands.\n\nIf \"--kill\" takes only one, I would probably do \"rebase --onto\"\nwithout bothering with \"-i\" at all, but if it lets me drop multiple\nnon-consecutive commits, by accepting more than one \"--kill\", I see\nhow I would be using it myself. I can see how \"--reword\"/\"--amend\"\nwould be useful even when dealing with only a single commit.\n\nI do not know about --fixup/--squash though.\n"},{"id":"236331","messageId":"1394333354-16257-1-git-send-email-pclouds@gmail.com","threadId":"35974","inReplyTo":"53159601.8020702@alum.mit.edu","subject":"[PATCH/RFC] rebase: new convenient option to edit/reword/delete a single commit","fromName":"Nguyễn Thái Ngọc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2014-03-09T02:49:14Z","receivedAt":"2014-03-09T02:49:14Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"Prepare the todo list for you to edit/reword/delete the given commit.\n\nSigned-off-by: Nguyễn Thái Ngọc Duy \n---\n Allowing multiple actions is a bit too much for my shell skills. I\n don't really need it so I won't push it, but if somebody gives me a\n sketch, I'll try to polish it.\n\n --squash and --fixup would require two commits, making it a bit\n awkward in option handling. Or is the fixup/squash always HEAD?\n\n Documentation/git-rebase.txt | 11 +++++++++++\n git-rebase--interactive.sh | 17 ++++++++++++++---\n git-rebase.sh | 22 +++++++++++++++++++++-\n 3 files changed, 46 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 2a93c64..becb749 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -13,6 +13,7 @@ SYNOPSIS\n 'git rebase' [-i | --interactive] [options] [--exec ] [--onto ]\n \t--root []\n 'git rebase' --continue | --skip | --abort | --edit-todo\n+'git rebase' [--edit | -E | --reword | -R | --delete | -D ] \n \n DESCRIPTION\n -----------\n@@ -356,6 +357,16 @@ unless the `--fork-point` option is specified.\n \tuser edit that list before rebasing. This mode can also be used to\n \tsplit commits (see SPLITTING COMMITS below).\n \n+-E=::\n+--edit=::\n+-R=::\n+--reword=::\n+-D=::\n+--delete=::\n+\tPrepare the todo list to edit or reword or delete the\n+\tspecified commit. Configuration variable `rebase.autostash` is\n+\tignored.\n+\n -p::\n --preserve-merges::\n \tInstead of ignoring merges, try to recreate them.\ndiff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\nindex a1adae8..3ded4c7 100644\n--- a/git-rebase--interactive.sh\n+++ b/git-rebase--interactive.sh\n@@ -1040,9 +1040,20 @@ fi\n has_action \"$todo\" ||\n \tdie_abort \"Nothing to do\"\n \n-cp \"$todo\" \"$todo\".backup\n-git_sequence_editor \"$todo\" ||\n-\tdie_abort \"Could not execute editor\"\n+if test -n \"$one_action\"\n+then\n+\tcommit=\"`git rev-parse --short $one_commit`\"\n+\tsed \"1s/pick $commit /$one_action $commit /\" \"$todo\" > \"$todo.new\" ||\n+\t\tdie_abort \"failed to update todo list\"\n+\tgrep \"^$one_action $commit \" \"$todo.new\" >/dev/null ||\n+\t\tdie_abort \"expected to find '$one_action $commit' line but did not\"\n+\tmv \"$todo.new\" \"$todo\" ||\n+\t\tdie_abort \"failed to update todo list\"\n+else\n+\tcp \"$todo\" \"$todo\".backup\n+\tgit_sequence_editor \"$todo\" ||\n+\t\tdie_abort \"Could not execute editor\"\n+fi\n \n has_action \"$todo\" ||\n \tdie_abort \"Nothing to do\"\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 5f6732b..2acffb4 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -32,6 +32,9 @@ verify allow pre-rebase hook to run\n rerere-autoupdate allow rerere to update index with resolved conflicts\n root! rebase all reachable commits up to the root(s)\n autosquash move commits that begin with squash!/fixup! under -i\n+E,edit=! generate todo list to edit this commit\n+R,reword=! generate todo list to reword this commit's message\n+D,delete=! generate todo list to delete this commit\n committer-date-is-author-date! passed to 'git am'\n ignore-date! passed to 'git am'\n whitespace=! passed to 'git apply'\n@@ -228,6 +231,7 @@ then\n fi\n test -n \"$type\" && in_progress=t\n \n+one_action=\n total_argc=$#\n while test $# != 0\n do\n@@ -290,6 +294,7 @@ do\n \t\t;;\n \t--autostash)\n \t\tautostash=true\n+\t\texplicit_autosquash=t\n \t\t;;\n \t--verbose)\n \t\tverbose=t\n@@ -335,6 +340,13 @@ do\n \t--gpg-sign=*)\n \t\tgpg_sign_opt=\"-S${1#--gpg-sign=}\"\n \t\t;;\n+\t--edit=*|--reword=*|--delete=*)\n+\t\ttest -n \"$one_action\" && die \"$(gettext \"--edit, --reword or --delete cannot be used multiple times\")\"\n+\t\tinteractive_rebase=explicit\n+\t\tone_action=\"${1%=*}\"\n+\t\tone_action=\"${one_action#--}\"\n+\t\tone_commit=\"${1#--*=}\"\n+\t\t;;\n \t--)\n \t\tshift\n \t\tbreak\n@@ -342,6 +354,7 @@ do\n \tesac\n \tshift\n done\n+test -n \"$one_action\" && test $# -gt 0 && usage\n test $# -gt 2 && usage\n \n if test -n \"$cmd\" &&\n@@ -438,7 +451,14 @@ else\n \tstate_dir=\"$apply_dir\"\n fi\n \n-if test -z \"$rebase_root\"\n+if test -n \"$one_action\"\n+then\n+\tupstream_name=\"$one_commit^\"\n+\tupstream=$(peel_committish \"${upstream_name}\") ||\n+\tdie \"$(eval_gettext \"invalid upstream \\$upstream_name\")\"\n+\tupstream_arg=\"$upstream_name\"\n+\ttest -n \"$explicit_autosquash\" || autosquash=\n+elif test -z \"$rebase_root\"\n then\n \tcase \"$#\" in\n \t0)\n-- \n1.9.0.40.gaa8c3ea\n"},{"id":"236341","messageId":"vpqeh2bl4gv.fsf@anie.imag.fr","threadId":"35974","inReplyTo":"1394333354-16257-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH/RFC] rebase: new convenient option to edit/reword/delete a single commit","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-03-09T16:30:24Z","receivedAt":"2014-03-09T16:30:24Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Nguyễn Thái Ngọc Duy writes:\n\n> Documentation/git-rebase.txt | 11 +++++++++++\n> git-rebase--interactive.sh | 17 ++++++++++++++---\n> git-rebase.sh | 22 +++++++++++++++++++++-\n> 3 files changed, 46 insertions(+), 4 deletions(-)\n\nThis would deserve a few tests ...\n\n> 'git rebase' --continue | --skip | --abort | --edit-todo\n> +'git rebase' [--edit | -E | --reword | -R | --delete | -D ] \n[...]\n> +-E=::\n> +--edit=::\n> +-R=::\n> +--reword=::\n> +-D=::\n> +--delete=::\n\nI first thought the two versions were inconsistant, but they're\ntechnically correct since the current patch allows only one instance of\nthe option. I find it a bit weird to have two different descriptions,\nbut that may be just me.\n\n> +\tConfiguration variable `rebase.autostash` is\n> +\tignored.\n\nI first found it really strange, and then understood it's a typo.\n\ns/autostash/autosquash/\n\n;-)\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"236356","messageId":"531D7820.1090403@alum.mit.edu","threadId":"35974","inReplyTo":"1394333354-16257-1-git-send-email-pclouds@gmail.com","subject":"Re: [PATCH/RFC] rebase: new convenient option to edit/reword/delete a single commit","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2014-03-10T08:30:24Z","receivedAt":"2014-03-10T08:30:24Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 03/09/2014 03:49 AM, Nguyễn Thái Ngọc Duy wrote:\n> Prepare the todo list for you to edit/reword/delete the given commit.\n> \n> Signed-off-by: Nguyễn Thái Ngọc Duy \n> ---\n> Allowing multiple actions is a bit too much for my shell skills. I\n> don't really need it so I won't push it, but if somebody gives me a\n> sketch, I'll try to polish it.\n> \n> --squash and --fixup would require two commits, making it a bit\n> awkward in option handling. Or is the fixup/squash always HEAD?\n\nThese commands always squash/fixup the indicated commit with the\nprevious one. I think the same approach that you use below should work\nfor these commands, too.\n\n> Documentation/git-rebase.txt | 11 +++++++++++\n> git-rebase--interactive.sh | 17 ++++++++++++++---\n> git-rebase.sh | 22 +++++++++++++++++++++-\n> 3 files changed, 46 insertions(+), 4 deletions(-)\n> \n> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\n> index 2a93c64..becb749 100644\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -13,6 +13,7 @@ SYNOPSIS\n> 'git rebase' [-i | --interactive] [options] [--exec ] [--onto ]\n> \t--root []\n> 'git rebase' --continue | --skip | --abort | --edit-todo\n> +'git rebase' [--edit | -E | --reword | -R | --delete | -D ] \n> \n> DESCRIPTION\n> -----------\n> @@ -356,6 +357,16 @@ unless the `--fork-point` option is specified.\n> \tuser edit that list before rebasing. This mode can also be used to\n> \tsplit commits (see SPLITTING COMMITS below).\n> \n> +-E=::\n> +--edit=::\n> +-R=::\n> +--reword=::\n> +-D=::\n> +--delete=::\n> +\tPrepare the todo list to edit or reword or delete the\n> +\tspecified commit. Configuration variable `rebase.autostash` is\n> +\tignored.\n\nIf I understand correctly, when one of these options is used, the editor\nis not presented to the user at all. If so, then it is probably\nconfusing to emphasize \"the todo list\", because the user will never see\nit. How about\n\n Edit, reword, or delete the specified commit, replaying subsequent\n commits on top of it (like running `git rebase --interactive\n commit^` and then changing the command on the line containing\n commit). If conflicts arise when replaying the later commits,\n resolve them and run \"git rebase --continue\", as usual. The\n configuration variable `rebase.autosquash` is ignored when these\n options are used.\n\n> +\n> -p::\n> --preserve-merges::\n> \tInstead of ignoring merges, try to recreate them.\n> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh\n> index a1adae8..3ded4c7 100644\n> --- a/git-rebase--interactive.sh\n> +++ b/git-rebase--interactive.sh\n> @@ -1040,9 +1040,20 @@ fi\n> has_action \"$todo\" ||\n> \tdie_abort \"Nothing to do\"\n> \n> -cp \"$todo\" \"$todo\".backup\n> -git_sequence_editor \"$todo\" ||\n> -\tdie_abort \"Could not execute editor\"\n> +if test -n \"$one_action\"\n> +then\n> +\tcommit=\"`git rev-parse --short $one_commit`\"\n> +\tsed \"1s/pick $commit /$one_action $commit /\" \"$todo\" > \"$todo.new\" ||\n\nIt wouldn't hurt to anchor this pattern at the beginning of the line. I\nunderstand that it wouldn't help, either (assuming everything else is\nworking right), but it makes the intention clearer.\n\n> +\t\tdie_abort \"failed to update todo list\"\n> +\tgrep \"^$one_action $commit \" \"$todo.new\" >/dev/null ||\n> +\t\tdie_abort \"expected to find '$one_action $commit' line but did not\"\n\nThe die_aborts above is really an internal consistency check, right? If\nso, maybe it should start with \"internal error:\" so that the user\ndoesn't think that he has done something wrong.\n\n> +\tmv \"$todo.new\" \"$todo\" ||\n> +\t\tdie_abort \"failed to update todo list\"\n> +else\n> +\tcp \"$todo\" \"$todo\".backup\n> +\tgit_sequence_editor \"$todo\" ||\n> +\t\tdie_abort \"Could not execute editor\"\n> +fi\n> \n> has_action \"$todo\" ||\n> \tdie_abort \"Nothing to do\"\n> diff --git a/git-rebase.sh b/git-rebase.sh\n> index 5f6732b..2acffb4 100755\n> --- a/git-rebase.sh\n> +++ b/git-rebase.sh\n> @@ -32,6 +32,9 @@ verify allow pre-rebase hook to run\n> rerere-autoupdate allow rerere to update index with resolved conflicts\n> root! rebase all reachable commits up to the root(s)\n> autosquash move commits that begin with squash!/fixup! under -i\n> +E,edit=! generate todo list to edit this commit\n> +R,reword=! generate todo list to reword this commit's message\n> +D,delete=! generate todo list to delete this commit\n> committer-date-is-author-date! passed to 'git am'\n> ignore-date! passed to 'git am'\n> whitespace=! passed to 'git apply'\n> @@ -228,6 +231,7 @@ then\n> fi\n> test -n \"$type\" && in_progress=t\n> \n> +one_action=\n> total_argc=$#\n> while test $# != 0\n> do\n> @@ -290,6 +294,7 @@ do\n> \t\t;;\n> \t--autostash)\n> \t\tautostash=true\n> +\t\texplicit_autosquash=t\n\nShould that be \"explicit_autostash\"?\n\n> \t\t;;\n> \t--verbose)\n> \t\tverbose=t\n> @@ -335,6 +340,13 @@ do\n> \t--gpg-sign=*)\n> \t\tgpg_sign_opt=\"-S${1#--gpg-sign=}\"\n> \t\t;;\n> +\t--edit=*|--reword=*|--delete=*)\n> +\t\ttest -n \"$one_action\" && die \"$(gettext \"--edit, --reword or --delete cannot be used multiple times\")\"\n> +\t\tinteractive_rebase=explicit\n> +\t\tone_action=\"${1%=*}\"\n> +\t\tone_action=\"${one_action#--}\"\n> +\t\tone_commit=\"${1#--*=}\"\n> +\t\t;;\n\nIs \"delete\" a valid todo-list command? I would have thought that you\nwould change the command to \"#pick\" in the case of \"--delete\".\n\n> \t--)\n> \t\tshift\n> \t\tbreak\n> @@ -342,6 +354,7 @@ do\n> \tesac\n> \tshift\n> done\n> +test -n \"$one_action\" && test $# -gt 0 && usage\n> test $# -gt 2 && usage\n> \n> if test -n \"$cmd\" &&\n> @@ -438,7 +451,14 @@ else\n> \tstate_dir=\"$apply_dir\"\n> fi\n> \n> -if test -z \"$rebase_root\"\n> +if test -n \"$one_action\"\n> +then\n> +\tupstream_name=\"$one_commit^\"\n> +\tupstream=$(peel_committish \"${upstream_name}\") ||\n> +\tdie \"$(eval_gettext \"invalid upstream \\$upstream_name\")\"\n> +\tupstream_arg=\"$upstream_name\"\n> +\ttest -n \"$explicit_autosquash\" || autosquash=\n> +elif test -z \"$rebase_root\"\n\nIt would be nice if these options (though not --squash and --fixup)\nwould support editing the root commit. The logic would be similar to\nthe code in the \"else\" branch of this \"if\" chain.\n\n> then\n> \tcase \"$#\" in\n> \t0)\n> \n\nCheers,\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"236359","messageId":"vpqd2huh2e7.fsf@anie.imag.fr","threadId":"35974","inReplyTo":"531D7820.1090403@alum.mit.edu","subject":"Re: [PATCH/RFC] rebase: new convenient option to edit/reword/delete a single commit","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2014-03-10T08:41:04Z","receivedAt":"2014-03-10T08:41:04Z","isPatch":true,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Michael Haggerty writes:\n\n>> @@ -290,6 +294,7 @@ do\n>> \t\t;;\n>> \t--autostash)\n>> \t\tautostash=true\n>> +\t\texplicit_autosquash=t\n>\n> Should that be \"explicit_autostash\"?\n\nMy guess is: no, but it should be below the --autoquash case, not this\none.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"}]}