On Fri, Feb 13, 2009 at 07:22, Junio C Hamano <gitster@xxxxxxxxx> wrote: > I thought I left it up to you ;-). Ah, I failed to notice that, my bad. > I can not think of a practical purpose of "git rebase -f" without other > options that actively modify the tree each commit records (e.g. the "fix > whitespace" option), perhaps other than to pretend that you committed them > later than you actually did. A patch that implements --force alone is > harder to justify, because it is unclear what good it does. It is > especially true if you make --whitespace=fix imply that behaviour. Agreed, thanks for the explanation. > One more thing. I kept saying "detect --whitespace=fix (or its synonym > strip)" because people can have "apply.whitespace = fix" in their > configuration file for use with "git am", and countermand the > configuration with "git rebase --whitespace=warn". Such a usage should > not imply --force. Ok, so having 'apply.whitespace = fix' in your config _should_ imply -f, and '--whitespace=[no]warn' as commandline option should not affect '-f'. This does mean though that anyone with 'apply.whitespace = fix' in their git config that does a rebase on an up-to-date branch will automagically have the whitespace fixed. Then again, that behavior is probably desired for those with 'apply.whitespace = fix' set. I'll look into making --whitespace=fix/strip imply -f then, and this time add some tests :). -- Cheers, Sverre Rabbelier -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
