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

STALE3736d

2 messages, 1 author, 2016-06-15 · open the first message on its own page

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

From: Kevin Ballard <hidden>
Date: 2016-06-15 22:48:29

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 <redacted>
---
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(-)

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

From: Kevin Ballard <hidden>
Date: 2016-06-15 22:48:30

Aww crud, I just realized I titled this patch wrong. It was supposed to be

rebase: Squelch the "fatal: Not a range." error

Should I send out a new patch?

-Kevin Ballard

On Mar 23, 2010, at 5:03 PM, Kevin Ballard wrote:
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 <redacted>
---
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(-)

<0001-rebase-Squelch-the-fatal-Not-an-error.-message.patch>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help