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

Sverre Rabbelier [off-list ref] writes:

On Fri, Feb 13, 2009 at 00:22, Junio C Hamano [off-list ref] wrote:

quoted

No, because I didn't read the patch text; I don't read patches that are
larger than 20 lines during the day-job hours.

Hehe, that sounds like a fair policy.

quoted

I was only commenting on your "rebase does not work if I am up to date
with respect to origin and here is my workaround".

Ok, thanks for the comment then, I'll wait for more comment and maybe
write some tests tomorrow.

Ok, now it is past 5pm, I've read the patch.

I wonder if we can (and if so should) make this a bit more automatic
without having to say "rebase -f --whitespace=fix".

When you say "git rebase --whitespace=fix origin" from the command line,
you are explicitly saying "I want to *fix* breakages in the commits since
'origin'", and at that point, it stops mattering if origin stayed dormant
since you forked from it.  I'd say that the current behaviour is a bug
introduced by the commit that added --whitespace=fix option.

The logic is the same as "git rebase --interactive origin" that does not
refuse to work even if you are already ahead of the origin.

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.

On Fri, Feb 13, 2009 at 02:32, Junio C Hamano [off-list ref] wrote:

I wonder if we can (and if so should) make this a bit more automatic
without having to say "rebase -f --whitespace=fix".

I have been thinking of that, having whitespace=fix imply -f, but I
wasn't sure whether it makes sense for all workflows that might use
rebase together with whitespace=fix. I aliased 'fixwhitespace' to
'rebase -f --whitespace=fix origin' myself, so I figured I'd send the
patch as-is and see what people think :).

The logic is the same as "git rebase --interactive origin" that does not
refuse to work even if you are already ahead of the origin.

This makes sense, and after thinking about it some, I don't really see
any harm in running 'git rebase --whitespace=...' even if the branch
is up to date.

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?

-- 
Cheers,

Sverre Rabbelier