{"thread":{"id":"17759","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","startedAt":"2009-02-12T19:47:41Z","lastAt":"2009-02-13T07:15:10Z","messageCount":14,"participants":["Johannes Schindelin","Sverre Rabbelier","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"104416","messageId":"1234468061-29923-1-git-send-email-srabbelier@gmail.com","threadId":"17759","inReplyTo":null,"subject":"[RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-02-12T19:47:41Z","receivedAt":"2009-02-12T19:47:41Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Normally, if the current branch is up to date, the rebase is aborted.\nHowever, it may be desirable to allow rebasing even if the current\nbranch is up to date, when using '-f' in combination with the\n'--whitespace=fix' option for example.\n\nSigned-off-by: Sverre Rabbelier <srabbelier@gmail.com>\n---\n\nSay I have a bunch of new commits ready to submit to origin, but I want to fix\nsome whitespace damage, I could do something like this:\n\n$ git checkout master\n$ git branch -b rebase-me\n$ git reset --hard origin/master\n$ git commit --allow-empty \"force rebase\"\n$ git checkout rebase-me\n$ git rebase --whitespace=fix master\n$ git rebase -i master # kick out the 'force rebase' commit\n$ git checkout master\n$ git reset --hard rebase-me\n$ git branch -d rebase-me\n\nThe result would be that all commits in origin/master..master have any\nwhitespace errors fixed, but it seems a bit clumsy. That is, the need to create\na commit on master so that 'git rebase' won't bail out early makes the whole\nprocess a lot more involved. This patch addresses simplifies the above process\nto the following:\n\n$ git rebase -f --whitespace=fix origin/master\n\nThat's a reduction of 9 commands, not too bad at all.\n\nNo tests included yet, will add them if there is any interest in the patch\nfrom the list, otherwise I'll just keep it around locally :).\n\n git-rebase.sh |   19 ++++++++++++++-----\n 1 files changed, 14 insertions(+), 5 deletions(-)\n\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 6d3eddb..55d0f63 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -3,7 +3,7 @@\n # Copyright (c) 2005 Junio C Hamano.\n #\n \n-USAGE='[--interactive | -i] [-v] [--onto <newbase>] [<upstream>|--root] [<branch>]'\n+USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--onto <newbase>] [<upstream>|--root] [<branch>]'\n LONG_USAGE='git-rebase replaces <branch> with a new branch of the\n same name.  When the --onto option is provided the new branch starts\n out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>\n@@ -48,6 +48,7 @@ prec=4\n verbose=\n git_am_opt=\n rebase_root=\n+force_rebase=\n \n continue_merge () {\n \ttest -n \"$prev_head\" || die \"prev_head must be defined\"\n@@ -300,6 +301,9 @@ do\n \t\t;;\n \t--root)\n \t\trebase_root=t\n+    ;;\n+  -f|--f|--fo|--for|--forc|force|--force-r|--force-re|--force-reb|--force-reba|--force_rebas|--force-rebase)\n+    force_rebase=t\n \t\t;;\n \t-*)\n \t\tusage\n@@ -419,10 +423,15 @@ if test \"$upstream\" = \"$onto\" && test \"$mb\" = \"$onto\" &&\n \t# linear history?\n \t! (git rev-list --parents \"$onto\"..\"$branch\" | grep \" .* \") > /dev/null\n then\n-\t# Lazily switch to the target branch if needed...\n-\ttest -z \"$switch_to\" || git checkout \"$switch_to\"\n-\techo >&2 \"Current branch $branch_name is up to date.\"\n-\texit 0\n+\tif test -z \"$force_rebase\"\n+\tthen\n+\t\t# Lazily switch to the target branch if needed...\n+\t\ttest -z \"$switch_to\" || git checkout \"$switch_to\"\n+\t\techo >&2 \"Current branch $branch_name is up to date.\"\n+\t\texit 0\n+\telse\n+\t\techo \"Current branch $branch_name is up to date, rebase forced.\"\n+  fi\n fi\n \n if test -n \"$verbose\"\n-- \n1.6.2.rc0.205.g53b19b.dirty\n"},{"id":"104408","messageId":"alpine.DEB.1.00.0902122126460.10279@pacific.mpi-cbg.de","threadId":"17759","inReplyTo":"1234468061-29923-1-git-send-email-srabbelier@gmail.com","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-12T20:28:03Z","receivedAt":"2009-02-12T20:28:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 12 Feb 2009, Sverre Rabbelier wrote:\n\n> The result would be that all commits in origin/master..master have any\n> whitespace errors fixed, but it seems a bit clumsy.\n\nFWIW I typically use 'git rebase --whitespace=fix $(git merge-base \norigin/master master)' for that, but that only works when there is a \nsingle merge base.\n\nCiao,\nDscho\n"},{"id":"104410","messageId":"bd6139dc0902121230w1b9fec28sae4e14bdda58a50b@mail.gmail.com","threadId":"17759","inReplyTo":"alpine.DEB.1.00.0902122126460.10279@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-02-12T20:30:34Z","receivedAt":"2009-02-12T20:30:34Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Thu, Feb 12, 2009 at 21:28, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> FWIW I typically use 'git rebase --whitespace=fix $(git merge-base\n> origin/master master)' for that, but that only works when there is a\n> single merge base.\n\nHehe, shouldof known there is an easier way to do it currently. Why\ndoes that work though? Also, any comments on the patch? ;)\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"104411","messageId":"alpine.DEB.1.00.0902122134500.10279@pacific.mpi-cbg.de","threadId":"17759","inReplyTo":"bd6139dc0902121230w1b9fec28sae4e14bdda58a50b@mail.gmail.com","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-02-12T20:37:38Z","receivedAt":"2009-02-12T20:37:38Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 12 Feb 2009, Sverre Rabbelier wrote:\n\n> On Thu, Feb 12, 2009 at 21:28, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> > FWIW I typically use 'git rebase --whitespace=fix $(git merge-base\n> > origin/master master)' for that, but that only works when there is a\n> > single merge base.\n> \n> Hehe, shouldof known there is an easier way to do it currently. Why\n> does that work though?\n\nIt works because you are not rebasing onto 'master', but the merge base of \n'master' and your current branch.\n\nSo in contrast to the other situation, there are commits left to be \nrebased :-)\n\n> Also, any comments on the patch? ;)\n\nThere is probably a thinko in it: if \"master\" already has your patches, \nthen you cannot apply them on top of \"master\".  That should conflict \nrather horribly, and not change the commits that are already upstream.\n\nOr I misunderstand something here.  Quite possible, I am pretty tired.\n\nCiao,\nDscho\n"},{"id":"104415","messageId":"bd6139dc0902121244i4f894209m37f6c80716cbc397@mail.gmail.com","threadId":"17759","inReplyTo":"alpine.DEB.1.00.0902122134500.10279@pacific.mpi-cbg.de","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-02-12T20:44:14Z","receivedAt":"2009-02-12T20:44:14Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Feb 12, 2009 at 21:37, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> So in contrast to the other situation, there are commits left to be\n> rebased :-)\n\nAh, I see, funky hack :).\n\n>> Also, any comments on the patch? ;)\n>\n> There is probably a thinko in it: if \"master\" already has your patches,\n> then you cannot apply them on top of \"master\".  That should conflict\n> rather horribly, and not change the commits that are already upstream.\n\nHmmm, afaik there are two cases in which 'git rebase' will abort with\n'already up to date':\n1. onto == current\n2. onto == current + some extra patches\n\nA quick demo of 1:\n\n$ git rebase origin/master\nCurrent branch master is up to date.\n$ git rebase -f origin/master\nCurrent branch master is up to date, rebase forced.\nFirst, rewinding head to replay your work on top of it...\nFast-forwarded master to origin/master.\n\n\nA quick demo of 2:\n\n$ git rebase origin/master\nCurrent branch master is up to date.\n$ git rebase -f origin/master\nCurrent branch master is up to date, rebase forced.\nFirst, rewinding head to replay your work on top of it...\nApplying: Do not attempt to render a field if it is disabled\nApplying: Add ToS agreement to org_admin application related forms.\nApplying: Added mentor ToS\n\n> Or I misunderstand something here.  Quite possible, I am pretty tired.\n\nI hope that's the case, in my manual tests everything worked as\nexpected, but perhaps I didn't understand your concern correctly.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"104431","messageId":"7vbpt7jq4c.fsf@gitster.siamese.dyndns.org","threadId":"17759","inReplyTo":"1234468061-29923-1-git-send-email-srabbelier@gmail.com","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-12T21:34:59Z","receivedAt":"2009-02-12T21:34:59Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> Say I have a bunch of new commits ready to submit to origin, but I want to fix\n> some whitespace damage, I could do something like this:\n>\n> $ git checkout master\n> $ git branch -b rebase-me\n> $ git reset --hard origin/master\n> $ git commit --allow-empty \"force rebase\"\n> $ git checkout rebase-me\n> $ git rebase --whitespace=fix master\n> $ git rebase -i master # kick out the 'force rebase' commit\n> $ git checkout master\n> $ git reset --hard rebase-me\n> $ git branch -d rebase-me\n\nFor that, I would prefer to see:\n\n\tgit format-patch --stdout origin >my.mbox\n\tgit fetch origin\n        git checkout origin             ;# yes, detach\n        git am --whitespace=fix my.mbox\n        make test\n        git format-patch -o to-send-out origin\n\tgit send-email ..options.. to-send-out\n\nfor two reasons.\n\nIt fixes whitespace breakages, but more importantly, the procedure makes\nsure that what you will be sending out will apply cleanly to the origin\nthat may have progressed since you last looked at it.\n"},{"id":"104437","messageId":"bd6139dc0902121357l1eea7b8xe890513b756e97c2@mail.gmail.com","threadId":"17759","inReplyTo":"7vbpt7jq4c.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-02-12T21:57:17Z","receivedAt":"2009-02-12T21:57:17Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Thu, Feb 12, 2009 at 22:34, Junio C Hamano <gitster@pobox.com> wrote:\n> For that, I would prefer to see:\n>  (1)   git format-patch --stdout origin >my.mbox\n>  (2)   git fetch origin\n>  (3)   git checkout origin             ;# yes, detach\n>  (4)   git am --whitespace=fix my.mbox\n>  (5)   make test\n>  (6)   git format-patch -o to-send-out origin\n>  (7)   git send-email ..options.. to-send-out\n\nIf I understand things correctly 'git rebase -f --whitespace=fix\norigin' does only 1 and 4, yes? In my workflow I do 2 and 5 as 'git\npull --rebase' before I push anything, and since I push rather then\nsend-email, I never use 6 and 7. That leaves 3, which I guess is\nspecific to your workflow? I am guessing you detach to make it easier\nto easily test many different topic branches.\n\n> It fixes whitespace breakages, but more importantly, the procedure makes\n> sure that what you will be sending out will apply cleanly to the origin\n> that may have progressed since you last looked at it.\n\nMhhh, would 'git fetch && git rebase -f whitespace=fix orgin' do the\nsame? Do you see any other problems with the patch?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"104448","messageId":"7viqnfi6la.fsf@gitster.siamese.dyndns.org","threadId":"17759","inReplyTo":"bd6139dc0902121357l1eea7b8xe890513b756e97c2@mail.gmail.com","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-12T23:22:09Z","receivedAt":"2009-02-12T23:22:09Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> On Thu, Feb 12, 2009 at 22:34, Junio C Hamano <gitster@pobox.com> wrote:\n>> For that, I would prefer to see:\n>>  (1)   git format-patch --stdout origin >my.mbox\n>>  (2)   git fetch origin\n>>  (3)   git checkout origin             ;# yes, detach\n>>  (4)   git am --whitespace=fix my.mbox\n>>  (5)   make test\n>>  (6)   git format-patch -o to-send-out origin\n>>  (7)   git send-email ..options.. to-send-out\n>\n> If I understand things correctly 'git rebase -f --whitespace=fix\n> origin' does only 1 and 4, yes? In my workflow I do 2 and 5 as 'git\n> pull --rebase' before I push anything, and since I push rather then\n> send-email, I never use 6 and 7. That leaves 3, which I guess is\n> specific to your workflow? I am guessing you detach to make it easier\n> to easily test many different topic branches.\n>\n>> It fixes whitespace breakages, but more importantly, the procedure makes\n>> sure that what you will be sending out will apply cleanly to the origin\n>> that may have progressed since you last looked at it.\n>\n> Mhhh, would 'git fetch && git rebase -f whitespace=fix orgin' do the\n> same? Do you see any other problems with the patch?\n\nNo, because I didn't read the patch text; I don't read patches that are\nlarger than 20 lines during the day-job hours.\n\nI was only commenting on your \"rebase does not work if I am up to date\nwith respect to origin and here is my workaround\".\n\nObviously neither the \"fetch origin and reapply\" nor \"pull --rebase\" would\nmake any difference if you were indeed up to date.\n"},{"id":"104449","messageId":"bd6139dc0902121524o776703bdw1bb199caecbc9c21@mail.gmail.com","threadId":"17759","inReplyTo":"7viqnfi6la.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-02-12T23:24:14Z","receivedAt":"2009-02-12T23:24:14Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Fri, Feb 13, 2009 at 00:22, Junio C Hamano <gitster@pobox.com> wrote:\n> No, because I didn't read the patch text; I don't read patches that are\n> larger than 20 lines during the day-job hours.\n\nHehe, that sounds like a fair policy.\n\n> I was only commenting on your \"rebase does not work if I am up to date\n> with respect to origin and here is my workaround\".\n\nOk, thanks for the comment then, I'll wait for more comment and maybe\nwrite some tests tomorrow.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"104467","messageId":"7vhc2zglz4.fsf@gitster.siamese.dyndns.org","threadId":"17759","inReplyTo":"bd6139dc0902121524o776703bdw1bb199caecbc9c21@mail.gmail.com","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-13T01:32:47Z","receivedAt":"2009-02-13T01:32:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> On Fri, Feb 13, 2009 at 00:22, Junio C Hamano <gitster@pobox.com> wrote:\n>> No, because I didn't read the patch text; I don't read patches that are\n>> larger than 20 lines during the day-job hours.\n>\n> Hehe, that sounds like a fair policy.\n>\n>> I was only commenting on your \"rebase does not work if I am up to date\n>> with respect to origin and here is my workaround\".\n>\n> Ok, thanks for the comment then, I'll wait for more comment and maybe\n> write some tests tomorrow.\n\nOk, now it is past 5pm, I've read the patch.\n\nI wonder if we can (and if so should) make this a bit more automatic\nwithout having to say \"rebase -f --whitespace=fix\".\n\nWhen you say \"git rebase --whitespace=fix origin\" from the command line,\nyou are explicitly saying \"I want to *fix* breakages in the commits since\n'origin'\", and at that point, it stops mattering if origin stayed dormant\nsince you forked from it.  I'd say that the current behaviour is a bug\nintroduced by the commit that added --whitespace=fix option.\n\nThe logic is the same as \"git rebase --interactive origin\" that does not\nrefuse to work even if you are already ahead of the origin.\n\nSo my suggestion would be to add --force (or -f) like your patch does, and\nalso detect --whitespace=$option given from the command line, and if it is\nfix (or its synonym \"strip\"), automatically enable --force, perhaps as a\nfollow up patch, or in the same patch.\n"},{"id":"104477","messageId":"bd6139dc0902122202r25e2e320m19810097cbb54225@mail.gmail.com","threadId":"17759","inReplyTo":"7vhc2zglz4.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-02-13T06:02:10Z","receivedAt":"2009-02-13T06:02:10Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Fri, Feb 13, 2009 at 02:32, Junio C Hamano <gitster@pobox.com> wrote:\n> I wonder if we can (and if so should) make this a bit more automatic\n> without having to say \"rebase -f --whitespace=fix\".\n\nI have been thinking of that, having whitespace=fix imply -f, but I\nwasn't sure whether it makes sense for all workflows that might use\nrebase together with whitespace=fix. I aliased 'fixwhitespace' to\n'rebase -f --whitespace=fix origin' myself, so I figured I'd send the\npatch as-is and see what people think :).\n\n> The logic is the same as \"git rebase --interactive origin\" that does not\n> refuse to work even if you are already ahead of the origin.\n\nThis makes sense, and after thinking about it some, I don't really see\nany harm in running 'git rebase --whitespace=...' even if the branch\nis up to date.\n\n> So my suggestion would be to add --force (or -f) like your patch does, and\n> also detect --whitespace=$option given from the command line, and if it is\n> fix (or its synonym \"strip\"), automatically enable --force, perhaps as a\n> follow up patch, or in the same patch.\n\nThe patch to do so would be fairly trivial I think? That is, add\n'force_rebase=t' in the --whitespace=... part. Is that change small\nenough to be a single patch, or should it be a follow-up since the\nfirst patch is a-means-to-an-end for the second one?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"104478","messageId":"7vd4dmg8k1.fsf@gitster.siamese.dyndns.org","threadId":"17759","inReplyTo":"bd6139dc0902122202r25e2e320m19810097cbb54225@mail.gmail.com","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-13T06:22:38Z","receivedAt":"2009-02-13T06:22:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> On Fri, Feb 13, 2009 at 02:32, Junio C Hamano <gitster@pobox.com> wrote:\n> ...\n>> So my suggestion would be to add --force (or -f) like your patch does, and\n>> also detect --whitespace=$option given from the command line, and if it is\n>> fix (or its synonym \"strip\"), automatically enable --force, perhaps as a\n>> follow up patch, or in the same patch.\n>\n> The patch to do so would be fairly trivial I think? That is, add\n> 'force_rebase=t' in the --whitespace=... part. Is that change small\n> enough to be a single patch, or should it be a follow-up since the\n> first patch is a-means-to-an-end for the second one?\n\nI thought I left it up to you ;-).\n\nI do not think of a practical purpose of \"git rebase -f\" without other\noptions that actively modify the tree each commit records (e.g. the \"fix\nwhitespace\" option), perhaps other than to pretend that you committed them\nlater than you actually did.  A patch that implements --force alone is\nharder to justify, because it is unclear what good it does.  It is\nespecially true if you make --whitespace=fix imply that behaviour.\n\nOne more thing.  I kept saying \"detect --whitespace=fix (or its synonym\nstrip)\" because people can have \"apply.whitespace = fix\" in their\nconfiguration file for use with \"git am\", and countermand the\nconfiguration with \"git rebase --whitespace=warn\".  Such a usage should\nnot imply --force.\n"},{"id":"104483","messageId":"bd6139dc0902122251j24696806xb89de3e338d49cb@mail.gmail.com","threadId":"17759","inReplyTo":"7vd4dmg8k1.fsf@gitster.siamese.dyndns.org","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-02-13T06:51:17Z","receivedAt":"2009-02-13T06:51:17Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"On Fri, Feb 13, 2009 at 07:22, Junio C Hamano <gitster@pobox.com> wrote:\n> I thought I left it up to you ;-).\n\nAh, I failed to notice that, my bad.\n\n> I can not think of a practical purpose of \"git rebase -f\" without other\n> options that actively modify the tree each commit records (e.g. the \"fix\n> whitespace\" option), perhaps other than to pretend that you committed them\n> later than you actually did.  A patch that implements --force alone is\n> harder to justify, because it is unclear what good it does.  It is\n> especially true if you make --whitespace=fix imply that behaviour.\n\nAgreed, thanks for the explanation.\n\n> One more thing.  I kept saying \"detect --whitespace=fix (or its synonym\n> strip)\" because people can have \"apply.whitespace = fix\" in their\n> configuration file for use with \"git am\", and countermand the\n> configuration with \"git rebase --whitespace=warn\".  Such a usage should\n> not imply --force.\n\nOk, so having 'apply.whitespace = fix' in your config _should_ imply\n-f, and '--whitespace=[no]warn' as commandline option should not\naffect '-f'. This does mean though that anyone with 'apply.whitespace\n= fix' in their git config that does a rebase on an up-to-date branch\nwill automagically have the whitespace fixed. Then again, that\nbehavior is probably desired for those with 'apply.whitespace = fix'\nset.\n\nI'll look into making --whitespace=fix/strip imply -f then, and this\ntime add some tests :).\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"104485","messageId":"7v1vu2g64h.fsf@gitster.siamese.dyndns.org","threadId":"17759","inReplyTo":"bd6139dc0902122251j24696806xb89de3e338d49cb@mail.gmail.com","subject":"Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-02-13T07:15:10Z","receivedAt":"2009-02-13T07:15:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier <srabbelier@gmail.com> writes:\n\n> On Fri, Feb 13, 2009 at 07:22, Junio C Hamano <gitster@pobox.com> wrote:\n> ...\n>> One more thing.  I kept saying \"detect --whitespace=fix (or its synonym\n>> strip)\" because people can have \"apply.whitespace = fix\" in their\n>> configuration file for use with \"git am\", and countermand the\n>> configuration with \"git rebase --whitespace=warn\".  Such a usage should\n>> not imply --force.\n>\n> Ok, so having 'apply.whitespace = fix' in your config _should_ imply\n> -f, and '--whitespace=[no]warn' as commandline option should not\n> affect '-f'.\n\nWell, that is actually not quite what I meant.\n\nThe intention of the user who runs \"git rebase\" without an explicit option\n(-f nor --whitespace) with such a config is ambiguous.\n\nBut \"git rebase --whitespace=fix\" *is* unambiguously \"I'd like to fix it\",\nwith or without a config.  It should imply --force.\n\nSimilarly \"git rebase --whitespace=warn\" *is* unambiguously \"I do not want\nthe rebasing process to touch it, just warn, if necessary\".  It should not\nimply --force.\n\nSo I think it would be the most natural to look only at command line\noption --whitespace=*, and make fix/strip imply --force, without looking\nat config.\n"}]}