Re: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 13, 2009, 06:22 UTC
Message-ID: <7vd4dmg8k1.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <bd6139dc0902122202r25e2e320m19810097cbb54225@mail.gmail.com>

Sverre Rabbelier <srabbelier@gmail.com> writes:

Show 11 quoted lines

> On Fri, Feb 13, 2009 at 02:32, Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> So my suggestion would be to add --force (or -f) like your patch does, and
>> also detect --whitespace=$option given from the command line, and if it is
>> fix (or its synonym "strip"), automatically enable --force, perhaps as a
>> follow up patch, or in the same patch.
>
> The patch to do so would be fairly trivial I think? That is, add
> 'force_rebase=t' in the --whitespace=... part. Is that change small
> enough to be a single patch, or should it be a follow-up since the
> first patch is a-means-to-an-end for the second one?

I thought I left it up to you ;-).

I do 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.

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.