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

Normally, if the current branch is up to date, the rebase is aborted.
However, it may be desirable to allow rebasing even if the current
branch is up to date, when using '-f' in combination with the
'--whitespace=fix' option for example.

Signed-off-by: Sverre Rabbelier <redacted>
---

Say I have a bunch of new commits ready to submit to origin, but I want to fix
some whitespace damage, I could do something like this:

$ git checkout master
$ git branch -b rebase-me
$ git reset --hard origin/master
$ git commit --allow-empty "force rebase"
$ git checkout rebase-me
$ git rebase --whitespace=fix master
$ git rebase -i master # kick out the 'force rebase' commit
$ git checkout master
$ git reset --hard rebase-me
$ git branch -d rebase-me

The result would be that all commits in origin/master..master have any
whitespace errors fixed, but it seems a bit clumsy. That is, the need to create
a commit on master so that 'git rebase' won't bail out early makes the whole
process a lot more involved. This patch addresses simplifies the above process
to the following:

$ git rebase -f --whitespace=fix origin/master

That's a reduction of 9 commands, not too bad at all.

No tests included yet, will add them if there is any interest in the patch
from the list, otherwise I'll just keep it around locally :).

 git-rebase.sh |   19 ++++++++++++++-----
 1 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index 6d3eddb..55d0f63 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh

@@ -3,7 +3,7 @@
 # Copyright (c) 2005 Junio C Hamano.
 #
 
-USAGE='[--interactive | -i] [-v] [--onto <newbase>] [<upstream>|--root] [<branch>]'
+USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--onto <newbase>] [<upstream>|--root] [<branch>]'
 LONG_USAGE='git-rebase replaces <branch> with a new branch of the
 same name.  When the --onto option is provided the new branch starts
 out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>

@@ -48,6 +48,7 @@ prec=4
 verbose=
 git_am_opt=
 rebase_root=
+force_rebase=
 
 continue_merge () {
 	test -n "$prev_head" || die "prev_head must be defined"

@@ -300,6 +301,9 @@ do
 		;;
 	--root)
 		rebase_root=t
+    ;;
+  -f|--f|--fo|--for|--forc|force|--force-r|--force-re|--force-reb|--force-reba|--force_rebas|--force-rebase)
+    force_rebase=t
 		;;
 	-*)
 		usage

@@ -419,10 +423,15 @@ if test "$upstream" = "$onto" && test "$mb" = "$onto" &&
 	# linear history?
 	! (git rev-list --parents "$onto".."$branch" | grep " .* ") > /dev/null
 then
-	# Lazily switch to the target branch if needed...
-	test -z "$switch_to" || git checkout "$switch_to"
-	echo >&2 "Current branch $branch_name is up to date."
-	exit 0
+	if test -z "$force_rebase"
+	then
+		# Lazily switch to the target branch if needed...
+		test -z "$switch_to" || git checkout "$switch_to"
+		echo >&2 "Current branch $branch_name is up to date."
+		exit 0
+	else
+		echo "Current branch $branch_name is up to date, rebase forced."
+  fi
 fi
 
 if test -n "$verbose"

-- 
1.6.2.rc0.205.g53b19b.dirty

Hi,

On Thu, 12 Feb 2009, Sverre Rabbelier wrote:

The result would be that all commits in origin/master..master have any
whitespace errors fixed, but it seems a bit clumsy.

FWIW I typically use 'git rebase --whitespace=fix $(git merge-base 
origin/master master)' for that, but that only works when there is a 
single merge base.

Ciao,
Dscho

Heya,

On Thu, Feb 12, 2009 at 21:28, Johannes Schindelin
[off-list ref] wrote:

FWIW I typically use 'git rebase --whitespace=fix $(git merge-base
origin/master master)' for that, but that only works when there is a
single merge base.

Hehe, shouldof known there is an easier way to do it currently. Why
does that work though? Also, any comments on the patch? ;)

-- 
Cheers,

Sverre Rabbelier

Hi,

On Thu, 12 Feb 2009, Sverre Rabbelier wrote:

On Thu, Feb 12, 2009 at 21:28, Johannes Schindelin
[off-list ref] wrote:

quoted

FWIW I typically use 'git rebase --whitespace=fix $(git merge-base
origin/master master)' for that, but that only works when there is a
single merge base.

Hehe, shouldof known there is an easier way to do it currently. Why
does that work though?

It works because you are not rebasing onto 'master', but the merge base of 
'master' and your current branch.

So in contrast to the other situation, there are commits left to be 
rebased :-)

Also, any comments on the patch? ;)

There is probably a thinko in it: if "master" already has your patches, 
then you cannot apply them on top of "master".  That should conflict 
rather horribly, and not change the commits that are already upstream.

Or I misunderstand something here.  Quite possible, I am pretty tired.

Ciao,
Dscho

On Thu, Feb 12, 2009 at 21:37, Johannes Schindelin
[off-list ref] wrote:

So in contrast to the other situation, there are commits left to be
rebased :-)

Ah, I see, funky hack :).

quoted

Also, any comments on the patch? ;)

There is probably a thinko in it: if "master" already has your patches,
then you cannot apply them on top of "master".  That should conflict
rather horribly, and not change the commits that are already upstream.

Hmmm, afaik there are two cases in which 'git rebase' will abort with
'already up to date':
1. onto == current
2. onto == current + some extra patches

A quick demo of 1:

$ git rebase origin/master
Current branch master is up to date.
$ git rebase -f origin/master
Current branch master is up to date, rebase forced.
First, rewinding head to replay your work on top of it...
Fast-forwarded master to origin/master.


A quick demo of 2:

$ git rebase origin/master
Current branch master is up to date.
$ git rebase -f origin/master
Current branch master is up to date, rebase forced.
First, rewinding head to replay your work on top of it...
Applying: Do not attempt to render a field if it is disabled
Applying: Add ToS agreement to org_admin application related forms.
Applying: Added mentor ToS

Or I misunderstand something here.  Quite possible, I am pretty tired.

I hope that's the case, in my manual tests everything worked as
expected, but perhaps I didn't understand your concern correctly.

-- 
Cheers,

Sverre Rabbelier