[PATCH] rebase: Squelch the "fatal: Not an error." message

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



When `git rebase --onto newbase upstream` is executed with
upstream being equal to the current commit, `git rebase` will
call `git format-patch` with "upstream..upstream" as the commits
to generate patches for. This causes a spurious error message to
be thrown which should be squelched.

Signed-off-by: Kevin Ballard <kevin@xxxxxx>
---
This patch was inspired by a common error encountered when using `git pull --rebase`, particularly in the case where there are no local commits that need rebasing and the fetched head was a force-pushed history modification (e.g. from git filter-branch). The error itself is actually caused by running `git rebase --onto newbase upstream` where upstream is the same commit as HEAD. This causes `git format-patch` to be called with "upstream..upstream" as the range and it complains. My solution was to squelch all errors from `git format-patch`, though I am unsure if the "fatal: Not a range." error is the only error that can be raised in this situation.

git-rebase.sh |    2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-rebase.sh b/git-rebase.sh
index e0eb956..8868dee 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -544,7 +544,7 @@ fi
 if test -z "$do_merge"
 then
 	git format-patch -k --stdout --full-index --ignore-if-in-upstream \
-		$root_flag "$revisions" |
+		$root_flag "$revisions" 2>/dev/null |
 	git am $git_am_opt --rebasing --resolvemsg="$RESOLVEMSG" &&
 	move_to_original_branch
 	ret=$?

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]