# [PATCH] rebase: Squelch the "fatal: Not an error." message 6 messages from 2010-03-24 to 2010-03-30. Participants: Kevin Ballard, Junio C Hamano. Thread: https://gitlist.dev/t/23157 ## Kevin Ballard, 2010-03-24 00:03 Subject: [PATCH] rebase: Squelch the "fatal: Not an error." message Message-ID: URL: https://gitlist.dev/e/C07F26A5-6BAD-433D-B1FF-A08DC8E0EA74%40sb.org ``` 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 --- 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=$? ``` ## Kevin Ballard, 2010-03-25 21:24 Subject: Re: [PATCH] rebase: Squelch the "fatal: Not an error." message Message-ID: URL: https://gitlist.dev/e/AB91AF2A-E6ED-4C4F-8B99-4A9CFA591C29%40sb.org In-Reply-To: ``` 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 > --- > 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> ``` ## Junio C Hamano, 2010-03-26 19:25 Subject: Re: [PATCH] rebase: Squelch the "fatal: Not an error." message Message-ID: <7vy6helwbq.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7vy6helwbq.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Kevin Ballard writes: > ... 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. Hmm, since "git format-patch HEAD" simply exits with success, I am inclined to think that we should fix "format-patch HEAD..HEAD" to do the same instead. I didn't check how involved such a change might be, though. > > 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=$? ``` ## Kevin Ballard, 2010-03-26 23:31 Subject: Re: [PATCH] rebase: Squelch the "fatal: Not an error." message Message-ID: URL: https://gitlist.dev/e/F8E395F5-C248-4A95-B2EF-A36E941FFDCF%40sb.org In-Reply-To: <7vy6helwbq.fsf@alter.siamese.dyndns.org> ``` On Mar 26, 2010, at 12:25 PM, Junio C Hamano wrote: > Hmm, since "git format-patch HEAD" simply exits with success, I am > inclined to think that we should fix "format-patch HEAD..HEAD" to do the > same instead. I didn't check how involved such a change might be, > though. Actually it doesn't. The line `git format-patch --ignore-if-in-upstream HEAD` gives the same error (the flag seems to be necessary to get the error in the first place). In any case, I'll see if I can't figure out why it's giving that error. -Kevin Ballard -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com ``` ## Kevin Ballard, 2010-03-27 00:08 Subject: Re: [PATCH] rebase: Squelch the "fatal: Not an error." message Message-ID: <46BEF37C-3E3F-4490-9CE6-C0109438C181@sb.org> URL: https://gitlist.dev/e/46BEF37C-3E3F-4490-9CE6-C0109438C181%40sb.org In-Reply-To: ``` On Mar 26, 2010, at 4:31 PM, Kevin Ballard wrote: > On Mar 26, 2010, at 12:25 PM, Junio C Hamano wrote: > >> Hmm, since "git format-patch HEAD" simply exits with success, I am >> inclined to think that we should fix "format-patch HEAD..HEAD" to do the >> same instead. I didn't check how involved such a change might be, >> though. > > Actually it doesn't. The line `git format-patch --ignore-if-in-upstream HEAD` gives the same error (the flag seems to be necessary to get the error in the first place). In any case, I'll see if I can't figure out why it's giving that error. Hmm, it seems like the easiest fix is just to comment out the following block in log.c (in get_patch_ids, line 645 on current next): if ((flags1 & UNINTERESTING) == (flags2 & UNINTERESTING)) die("Not a range."); Without that line, `git format-patch --ignore-if-in-upstream HEAD` returns the expected empty output. I also ran the complete test suite (excluding SVN tests) and there were no breakages. However I don't understand the purpose behind that assertion in the first place (as I am not familiar with the workings of rev_info or patch_ids) so I don't know if this change is really appropriate (though I would assume that if it wasn't, a test somewhere would break). -Kevin Ballard -- Kevin Ballard http://kevin.sb.org kevin@sb.org http://www.tildesoft.com ``` ## Kevin Ballard, 2010-03-30 02:46 Subject: [PATCH] format-patch: Squelch 'fatal: Not a range." error Message-ID: <1269917198-58320-1-git-send-email-kevin@sb.org> URL: https://gitlist.dev/e/1269917198-58320-1-git-send-email-kevin%40sb.org In-Reply-To: <46BEF37C-3E3F-4490-9CE6-C0109438C181@sb.org> ``` Don't output an error on `git format-patch --ignore-if-in-upstream HEAD`. This matches the behavior of `git format-patch HEAD`. Signed-off-by: Kevin Ballard --- This seems like a safer change than just deleting the die("Not a range."). The conditional here is copied from cmd_cherry(). builtin/log.c | 9 ++++++++- t/t4014-format-patch.sh | 4 ++++ 2 files changed, 12 insertions(+), 1 deletions(-) diff --git a/builtin/log.c b/builtin/log.c index 0cb4d5a..362dd42 100644 --- a/builtin/log.c +++ b/builtin/log.c @@ -1179,8 +1179,15 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix) return 0; } - if (ignore_if_in_upstream) + if (ignore_if_in_upstream) { + /* Don't say anything if head and upstream are the same. */ + if (rev.pending.nr == 2) { + struct object_array_entry *o = rev.pending.objects; + if (hashcmp(o[0].item->sha1, o[1].item->sha1) == 0) + return 0; + } get_patch_ids(&rev, &ids, prefix); + } if (!use_stdout) realstdout = xfdopen(xdup(1), "w"); diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh index c7b6256..d21c37f 100755 --- a/t/t4014-format-patch.sh +++ b/t/t4014-format-patch.sh @@ -609,4 +609,8 @@ test_expect_success 'format-patch -- ' ' ! grep "Use .--" error ' +test_expect_success 'format-patch --ignore-if-in-upstream HEAD' ' + git format-patch --ignore-if-in-upstream HEAD +' + test_done -- 1.7.0.3.436.g3ff98 ```