{"thread":{"id":"29317","subject":"[PATCH] rebase --fix: interactive fixup mode","startedAt":"2012-01-08T21:31:34Z","lastAt":"2012-01-10T19:58:04Z","messageCount":13,"participants":["Clemens Buchacher","Jonathan Nieder","Jakub Narebski","Junio C Hamano","Nguyen Thai Ngoc Duy","Michael Haggerty","Thomas Rast","Neal Kreitzinger"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"182135","messageId":"20120108213134.GA18671@ecki.lan","threadId":"29317","inReplyTo":null,"subject":"[PATCH] rebase --fix: interactive fixup mode","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-01-08T21:31:34Z","receivedAt":"2012-01-08T21:31:34Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"Interactive rebase is frequently used not to rebase history, but to\nmanipulate recent commits. This is typically done using the following\ncommand:\n\n git rebase -i HEAD~N\n\nWhere N has to be large enough such that the the range HEAD~N..HEAD\ncontains the desired commits. At the same time, it should be small\nenough such that the range HEAD~N..HEAD does not include published\ncommits or a merge commit. Otherwise, the user may accidentally change\npublished history. Rebasing a merge commit can also have the generally\nundesirable effect of linearizing the merge history.\n\nIn order to determine a suitable range automatically, it is a reasonable\nheuristic to rebase onto the most recent merge commit. It does not\nguarantee that published commits are not included -- indeed there is no\nway to do that. But, the range is usually large enough to contain the\ndesired commits. Also, this mechanism works regardless of whether or not\nbranch tracking has been configured.\n\nSo instead of the above command, one can instead use the following:\n\n git rebase --fix\n\nBy default, the range is limited to a maximum of 20 commits. This can be\nchanged by passing a different number to --fix, e.g.:\n\n git rebase --fix=50\n\nSigned-off-by: Clemens Buchacher \n---\n\nAlso on branch cb/rebase-fix at https://github.com/drizzd/git .\n\n Documentation/git-rebase.txt | 9 +++++++++\n git-rebase.sh | 37 ++++++++++++++++++++++++++++++++++++-\n 2 files changed, 45 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex 504945c..b1eac16 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -332,6 +332,15 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).\n \tuser edit that list before rebasing. This mode can also be used to\n \tsplit commits (see SPLITTING COMMITS below).\n \n+--fix=::\n+\tSearches commit history backwards from the current commit until the\n+\tmost recent merge commit, or until a maximum of preceding commits\n+\t(default: 20), and runs rebase -i ^. The resulting range is\n+\ttypically large enough to contain recent commits which the user might\n+\twant to edit, while avoiding the usually undesirable effects of\n+\trebasing a merge commit, which obviates the need to find a suitable\n+\tbase commit manually.\n+\n -p::\n --preserve-merges::\n \tInstead of ignoring merges, try to recreate them.\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 00ca7b9..e95b57f 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -38,6 +38,7 @@ git-rebase [-i] --continue | --abort | --skip\n v,verbose! display a diffstat of what changed upstream\n q,quiet! be quiet. implies --no-stat\n onto=! rebase onto given branch instead of upstream\n+fix?! interactive rebase onto last merge commit\n p,preserve-merges! try to recreate merges instead of ignoring them\n s,strategy=! use the given merge strategy\n no-ff! cherry-pick all commits, even if unchanged\n@@ -95,6 +96,7 @@ type=\n state_dir=\n # One of {'', continue, skip, abort}, as parsed from command line\n action=\n+rebase_fix=\n preserve_merges=\n autosquash=\n test \"$(git config --bool rebase.autosquash)\" = \"true\" && autosquash=t\n@@ -178,6 +180,22 @@ run_pre_rebase_hook () {\n \tfi\n }\n \n+latest_merge_commit()\n+{\n+\tmax_nr_commits=$1\n+\n+\tlatest_merge=$(git rev-list -1 --merges HEAD)\n+\tif test -z \"$latest_merge\"\n+\tthen\n+\t\trange=HEAD\n+\telse\n+\t\trange=$latest_merge..HEAD\n+\tfi\n+\n+\trange_start=$(git rev-list -\"$max_nr_commits\" \"$range\" | tail -1)\n+\techo $(git rev-parse $range_start^)\n+}\n+\n test -f \"$apply_dir\"/applying &&\n \tdie 'It looks like git-am is in progress. Cannot rebase.'\n \n@@ -220,6 +238,20 @@ do\n \t-i)\n \t\tinteractive_rebase=explicit\n \t\t;;\n+\t--fix)\n+\t\tinteractive_rebase=explicit\n+\t\trebase_fix=20\n+\t\t# Parse optional argument.\n+\t\tif test \"${2#-}\" = \"$2\"\n+\t\tthen\n+\t\t\tif ! expr \"$2\" : \"^[0-9]\\+$\" >/dev/null\n+\t\t\tthen\n+\t\t\t\tdie \"Invalid argument to rebase --fix: $2\"\n+\t\t\tfi\n+\t\t\trebase_fix=$2\n+\t\t\tshift\n+\t\tfi\n+\t\t;;\n \t-p)\n \t\tpreserve_merges=t\n \t\ttest -z \"$interactive_rebase\" && interactive_rebase=implied\n@@ -375,7 +407,10 @@ if test -z \"$rebase_root\"\n then\n \tcase \"$#\" in\n \t0)\n-\t\tif ! upstream_name=$(git rev-parse --symbolic-full-name \\\n+\t\tif test -n \"$rebase_fix\"\n+\t\tthen\n+\t\t\tupstream_name=$(latest_merge_commit $rebase_fix)\n+\t\telif ! upstream_name=$(git rev-parse --symbolic-full-name \\\n \t\t\t--verify -q @{upstream} 2>/dev/null)\n \t\tthen\n \t\t\t. git-parse-remote\n-- \n1.7.8\n"},{"id":"182138","messageId":"m3r4z9eu36.fsf@localhost.localdomain","threadId":"29317","inReplyTo":"20120108213134.GA18671@ecki.lan","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-01-08T21:57:03Z","receivedAt":"2012-01-08T21:57:03Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Clemens Buchacher writes:\n\n[...]\n> In order to determine a suitable range automatically, it is a reasonable\n> heuristic to rebase onto the most recent merge commit.\n\nWhy not additionally / instead take into account remote-tracking\nbranches for \"push\" remotes?\n\n> It does not\n> guarantee that published commits are not included -- indeed there is no\n> way to do that. But, the range is usually large enough to contain the\n> desired commits. Also, this mechanism works regardless of whether or not\n> branch tracking has been configured.\n> \n> So instead of the above command, one can instead use the following:\n> \n> git rebase --fix\n> \n> By default, the range is limited to a maximum of 20 commits. This can be\n> changed by passing a different number to --fix, e.g.:\n> \n> git rebase --fix=50\n> \n> Signed-off-by: Clemens Buchacher \n\nNice idea!\n\n-- \nJakub Narebski\nPoland\n"},{"id":"182137","messageId":"20120108220127.GA4050@burratino","threadId":"29317","inReplyTo":"20120108213134.GA18671@ecki.lan","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-01-08T22:01:27Z","receivedAt":"2012-01-08T22:01:27Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Clemens Buchacher wrote:\n\n> --- a/Documentation/git-rebase.txt\n> +++ b/Documentation/git-rebase.txt\n> @@ -332,6 +332,15 @@ link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).\n> \tuser edit that list before rebasing. This mode can also be used to\n> \tsplit commits (see SPLITTING COMMITS below).\n> \n> +--fix=::\n> +\tSearches commit history backwards from the current commit until the\n> +\tmost recent merge commit, or until a maximum of preceding commits\n> +\t(default: 20), and runs rebase -i ^. The resulting range is\n> +\ttypically large enough to contain recent commits which the user might\n> +\twant to edit, while avoiding the usually undesirable effects of\n> +\trebasing a merge commit, which obviates the need to find a suitable\n> +\tbase commit manually.\n\nFunny. :) I wonder if this is possible to generalize, to something like\n\n\tgit rebase -i foo^{last-merge}\n\nor even something like\n\n\tgit rebase -i foo^{first:--merges}\n\n(where \"^{first:}\" would mean something like\n\"the first commit listed by \"git rev-list \").\nWhat do you think?\n"},{"id":"182139","messageId":"20120108221946.GA22680@ecki.lan","threadId":"29317","inReplyTo":"m3r4z9eu36.fsf@localhost.localdomain","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-01-08T22:19:48Z","receivedAt":"2012-01-08T22:19:48Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Sun, Jan 08, 2012 at 01:57:03PM -0800, Jakub Narebski wrote:\n> \n> > In order to determine a suitable range automatically, it is a reasonable\n> > heuristic to rebase onto the most recent merge commit.\n> \n> Why not additionally / instead take into account remote-tracking\n> branches for \"push\" remotes?\n\nFor me personally, remote-tracking does not work. I frequently branch\nlocally, and even if I do branch from a remote branch, it's often not\nfrom a public branch, but rather my own private branch that I\nsynchronize between repos and machines. So my remote-tracking\nconfiguration is usually an awful mess, and it does not feel like fixing\nit up manually would be worth the trouble.\n\nAs a result, I don't trust remote-tracking and I do not use any of the\nfeatures associated with it. For my uses of rebase --fix it would\ntherefore be counter-productive to consider remote-tracking information.\n\nWhat I did consider was adding a comment to the list of \"pick \"\nthat interactive rebase offers saying:\n\n# older commits are already contained in the current upstream branch\n\nAlso, I often rewrite commits that are also contained in other branches.\nThat typically happens when I am reworking a topic that has already been\ntested extensively. In that case I like to keep the original branch\naround for reference, even if I end up not using it eventually.\n"},{"id":"182141","messageId":"20120108222545.GB22680@ecki.lan","threadId":"29317","inReplyTo":"20120108220127.GA4050@burratino","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-01-08T22:25:47Z","receivedAt":"2012-01-08T22:25:47Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Sun, Jan 08, 2012 at 04:01:27PM -0600, Jonathan Nieder wrote:\n> \n> Funny. :) I wonder if this is possible to generalize, to something like\n> \n> \tgit rebase -i foo^{last-merge}\n> \n> What do you think?\n\nI suppose if the history has no merges, I would return the root commit?\n\nUh, and now I realize I have a bug. In a repo with only linear history:\n\n$ git rebase --fix\nfatal: ambiguous argument '4ccf67b9fa2ae247e55b86648d650cb368f286c2^': unknown revision or path not in the working tree.\nUse '--' to separate paths from revisions\nfatal: Needed a single revision\ninvalid upstream 4ccf67b9fa2ae247e55b86648d650cb368f286c2^\n"},{"id":"182142","messageId":"7vfwfpg5st.fsf@alter.siamese.dyndns.org","threadId":"29317","inReplyTo":"20120108213134.GA18671@ecki.lan","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-01-08T22:58:42Z","receivedAt":"2012-01-08T22:58:42Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Clemens Buchacher writes:\n\n> Interactive rebase is frequently used not to rebase history, but to\n> manipulate recent commits. This is typically done using the following\n> command:\n>\n> git rebase -i HEAD~N\n>\n> Where N has to be large enough such that the the range HEAD~N..HEAD\n> contains the desired commits. At the same time, it should be small\n> enough such that the range HEAD~N..HEAD does not include published\n> commits or a merge commit. Otherwise, the user may accidentally change\n> published history. Rebasing a merge commit can also have the generally\n> undesirable effect of linearizing the merge history.\n>\n> In order to determine a suitable range automatically, it is a reasonable\n> heuristic to rebase onto the most recent merge commit.\n\nI understand the problem you are trying to solve, but I am not sure if\nthis is a good idea from the UI point of view for two reasons.\n\n - \"We want to limit the extent of the operation to commits since the last\n merge\" is by itself a reasonable thing to ask, and I do not think it\n should be limited to \"rebase\". If we had an extended SHA-1 syntax to\n express it, for example, you may want to say \"I want to see what I did\n since the last merge\" and run \"git log $last_merge_before_HEAD..\".\n Perhaps HEAD~{merge} or something?\n\n - If your \"rebase --fix\" is to \"fix\" things, what is \"rebase -i\" about?\n Isn't it also about fixing? I imagine that ordinary people expect a\n \"fix\" option that takes a parameter would take a commit to be fixed,\n and drive the rebase machinery to quickly fix it; in other words,\n\n\t$ git rebase --fix=':/^reword the greeting message'\n\n may internally run \"rebase -i $(git rev-parse ':/^rewor...')^\", with\n the insn sheet already prepared to \"edit\" the first commit in it, and\n may even return the control back to the user without showing the insn\n sheet in the editor.\n\nHmm?\n\n \n"},{"id":"182145","messageId":"CACsJy8CKK0EAy79Fahi64bUw2kfr=eunegbeA7oX_XaXEBFr2g@mail.gmail.com","threadId":"29317","inReplyTo":"20120108220127.GA4050@burratino","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2012-01-09T01:44:49Z","receivedAt":"2012-01-09T01:44:49Z","isPatch":true,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"2012/1/9 Jonathan Nieder :\n> Funny. :)  I wonder if this is possible to generalize, to something like\n>\n>        git rebase -i foo^{last-merge}\n>\n> or even something like\n>\n>        git rebase -i foo^{first:--merges}\n>\n> (where \"^{first:}\" would mean something like\n> \"the first commit listed by \"git rev-list \").\n> What do you think?\n\nIs something like this over-generalized?\n\nhttp://kerneltrap.org/mailarchive/git/2010/12/24/47502\n\nA good thing I see from having a specific option for \"-i HEAD~n\" is\nthat it's potentially shorter to type. For someone who does rebase a\nlot and has CapsLock turned to Ctrl, it helps. Maybe \"rebase -I\" ==\n\"rebase -i HEAD^{last-merge}\" (or \"rebase -i\n\") and \"rebase -I \" == \"rebase -i\nHEAD~\"?\n-- \nDuy\n"},{"id":"182154","messageId":"4F0AA7E2.9010200@alum.mit.edu","threadId":"29317","inReplyTo":"20120108213134.GA18671@ecki.lan","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2012-01-09T08:40:02Z","receivedAt":"2012-01-09T08:40:02Z","isPatch":true,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"On 01/08/2012 10:31 PM, Clemens Buchacher wrote:\n> Interactive rebase is frequently used not to rebase history, but to\n> manipulate recent commits. This is typically done using the following\n> command:\n> \n> git rebase -i HEAD~N\n> \n> Where N has to be large enough such that the the range HEAD~N..HEAD\n> contains the desired commits. At the same time, it should be small\n> enough such that the range HEAD~N..HEAD does not include published\n> commits or a merge commit. Otherwise, the user may accidentally change\n> published history. Rebasing a merge commit can also have the generally\n> undesirable effect of linearizing the merge history.\n> \n> In order to determine a suitable range automatically, it is a reasonable\n> heuristic to rebase onto the most recent merge commit. It does not\n> guarantee that published commits are not included -- indeed there is no\n> way to do that. But, the range is usually large enough to contain the\n> desired commits. Also, this mechanism works regardless of whether or not\n> branch tracking has been configured.\n> \n> So instead of the above command, one can instead use the following:\n> \n> git rebase --fix\n\nTwo comments:\n\n* The name \"--fix\" might be confusing because of its similarity to the\n\"fixup\" command that can be specified in the interactive instructions file.\n\n* I agree with you that \"interactive rebase is frequently used not to\nrebase history, but to manipulate recent commits\". In fact, I use\ninteractive rebase *only* for manipulating recent commits and\nnon-interactive rebase *only* for changing commits' ancestry. I think\nit is a good idea to make these two uses more distinct. For example, it\nmakes me nervous that I might mis-type the parameter when I\nam trying to touch up commits and end up inadvertently rebasing the\ncommits onto a new parent.\n\nMichael\n\n-- \nMichael Haggerty\nmhagger@alum.mit.edu\nhttp://softwareswirl.blogspot.com/\n"},{"id":"182153","messageId":"20120109084309.GD23422@burratino","threadId":"29317","inReplyTo":"CACsJy8CKK0EAy79Fahi64bUw2kfr=eunegbeA7oX_XaXEBFr2g@mail.gmail.com","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2012-01-09T08:43:09Z","receivedAt":"2012-01-09T08:43:09Z","isPatch":true,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n\n> Is something like this over-generalized?\n>\n> http://kerneltrap.org/mailarchive/git/2010/12/24/47502\n\nYes, I suspect that at the moment (i.e., in the absence of a large\ncollection of examples to show their utility), both your ^{~custom}\nand my ^{first:rev-list args} are overengineered, and that they do\nsomething that is more clearly expressed using the shell's command\nsubstitution feature:\n\n\tgit rebase -i $(git rev-list --merges HEAD | head -1)\n\nSo why did I suggest it?\n\nI guess I was reacting to the implementation of the\nrebase-recent-commits command. I understand that it was a sketch, but\nit felt a little ad hoc. If it could be expressed as a clean\ntwo-liner, I would be more comfortable since the burden of maintaining\nit would be less.\n\nThanks for clarifying.\n\nSincerely,\nJonathan\n"},{"id":"182155","messageId":"878vlh1bnm.fsf@thomas.inf.ethz.ch","threadId":"29317","inReplyTo":"20120108213134.GA18671@ecki.lan","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2012-01-09T09:13:33Z","receivedAt":"2012-01-09T09:13:33Z","isPatch":true,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Clemens Buchacher writes:\n\n> Interactive rebase is frequently used not to rebase history, but to\n> manipulate recent commits. This is typically done using the following\n> command:\n>\n> git rebase -i HEAD~N\n>\n> Where N has to be large enough such that the the range HEAD~N..HEAD\n> contains the desired commits. At the same time, it should be small\n> enough such that the range HEAD~N..HEAD does not include published\n> commits or a merge commit.\n[...]\n> git rebase --fix\n>\n> By default, the range is limited to a maximum of 20 commits.\n\nGiven the name I would expect --fix to rebase far enough to make recent\nfixup!/squash! commits take effect. Perhaps name it --recent?\n\n(And I also think that the 20 is rather arbitrary...)\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"182178","messageId":"20120109201609.GB25269@ecki","threadId":"29317","inReplyTo":"878vlh1bnm.fsf@thomas.inf.ethz.ch","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-01-09T20:16:09Z","receivedAt":"2012-01-09T20:16:09Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Mon, Jan 09, 2012 at 10:13:33AM +0100, Thomas Rast wrote:\n> \n> Given the name I would expect --fix to rebase far enough to make recent\n> fixup!/squash! commits take effect. Perhaps name it --recent?\n\nSure, I am not particular about the name.\n\n> (And I also think that the 20 is rather arbitrary...)\n\nWell, I need some kind of limit. Otherwise we will list the entire\nhistory up to the root commit in case of repos with only linear history.\nAnd that can be rather slow.\n\nClemens\n"},{"id":"182179","messageId":"20120109203357.GC25269@ecki","threadId":"29317","inReplyTo":"7vfwfpg5st.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Clemens Buchacher","fromEmail":"drizzd@aon.at","sentAt":"2012-01-09T20:33:58Z","receivedAt":"2012-01-09T20:33:58Z","isPatch":true,"sender":{"key":"drizzd@gmx.net","avatar":"https://avatars.githubusercontent.com/u/59082?v=4"},"body":"On Sun, Jan 08, 2012 at 02:58:42PM -0800, Junio C Hamano wrote:\n> Clemens Buchacher writes:\n> >\n> > In order to determine a suitable range automatically, it is a reasonable\n> > heuristic to rebase onto the most recent merge commit.\n> \n> I understand the problem you are trying to solve, but I am not sure if\n> this is a good idea from the UI point of view for two reasons.\n> \n> - \"We want to limit the extent of the operation to commits since the last\n> merge\" is by itself a reasonable thing to ask, and I do not think it\n> should be limited to \"rebase\". If we had an extended SHA-1 syntax to\n> express it, for example, you may want to say \"I want to see what I did\n> since the last merge\" and run \"git log $last_merge_before_HEAD..\".\n> Perhaps HEAD~{merge} or something?\n\nOk, sounds reasonable.\n\nI am not sure what to do if the history has no merges, though. If it's\njust rev-parse HEAD~{merge} I suppose I could return nothing, or an\nerror. But what about the HEAD~{merge}..HEAD range? I think it would be\nuseful if that were not an error but the entire history.\n\n> - If your \"rebase --fix\" is to \"fix\" things, what is \"rebase -i\" about?\n\nI would have suggested this to be the default behavior for rebase -i\nwithout an argument, but unfortunately we already handle this\ncase using @{upstream}.\n"},{"id":"182276","messageId":"4F0C984C.8040907@gmail.com","threadId":"29317","inReplyTo":"4F0AA7E2.9010200@alum.mit.edu","subject":"Re: [PATCH] rebase --fix: interactive fixup mode","fromName":"Neal Kreitzinger","fromEmail":"nkreitzinger@gmail.com","sentAt":"2012-01-10T19:58:04Z","receivedAt":"2012-01-10T19:58:04Z","isPatch":true,"sender":{"key":"nkreitzinger@gmail.com","avatar":null},"body":"On 1/9/2012 2:40 AM, Michael Haggerty wrote:\n>\n> Two comments:\n>\n> * The name \"--fix\" might be confusing because of its similarity to the\n> \"fixup\" command that can be specified in the interactive instructions file.\n>\n> * I agree with you that \"interactive rebase is frequently used not to\n> rebase history, but to manipulate recent commits\". In fact, I use\n> interactive rebase *only* for manipulating recent commits and\n> non-interactive rebase *only* for changing commits' ancestry. I think\n> it is a good idea to make these two uses more distinct. For example, it\n> makes me nervous that I might mis-type the parameter when I\n> am trying to touch up commits and end up inadvertently rebasing the\n> commits onto a new parent.\n>\nHe could all it --touchup like you did above.\n\nv/r,\nneal\n"}]}