All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sverre Rabbelier <srabbelier@gmail.com>
To: "Git Mailinglist" <git@vger.kernel.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Eric Wong" <normalperson@yhbt.net>,
	"Shawn O. Pear
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Subject: [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f
Date: Thu, 12 Feb 2009 20:47:41 +0100	[thread overview]
Message-ID: <1234468061-29923-1-git-send-email-srabbelier@gmail.com> (raw)

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 <srabbelier@gmail.com>
---

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

             reply	other threads:[~2009-02-12 20:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-12 19:47 Sverre Rabbelier [this message]
2009-02-12 20:28 ` [RFC PATCH] Teach rebase to rebase even if upstream is up to date with -f Johannes Schindelin
2009-02-12 20:30   ` Sverre Rabbelier
2009-02-12 20:37     ` Johannes Schindelin
2009-02-12 20:44       ` Sverre Rabbelier
2009-02-12 21:34 ` Junio C Hamano
2009-02-12 21:57   ` Sverre Rabbelier
2009-02-12 23:22     ` Junio C Hamano
2009-02-12 23:24       ` Sverre Rabbelier
2009-02-13  1:32         ` Junio C Hamano
2009-02-13  6:02           ` Sverre Rabbelier
2009-02-13  6:22             ` Junio C Hamano
2009-02-13  6:51               ` Sverre Rabbelier
2009-02-13  7:15                 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1234468061-29923-1-git-send-email-srabbelier@gmail.com \
    --to=srabbelier@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=normalperson@yhbt.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.