Robert Shearman <robertshearman@xxxxxxxxx> writes: > The "git checkout" command executed could fail if, for example, upstream contains a file that would overrwrite a local, untracked file. The output redirection didn't work as stderr was redirected to /dev/null, as was stdout. This appears to be not what was intended so the order of redirections is fixed so that stderr is redirected to stdout instead. Very long lines, lacks sign-off. > --- > git-rebase.sh | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/git-rebase.sh b/git-rebase.sh > index e2d85ee..0da2210 100755 > --- a/git-rebase.sh > +++ b/git-rebase.sh > @@ -376,7 +376,7 @@ fi > > # Detach HEAD and reset the tree > echo "First, rewinding head to replay your work on top of it..." > -git checkout "$onto^0" >/dev/null 2>&1 || I think this very much is done deliberately by somebody who knows the shell to discard everything. > +git checkout "$onto^0" 2>&1 >/dev/null || And if it is beneficial to show the error, you just do not touch fd #2, like this: git checkout "$onto^0" >/dev/null As I do not see any reason to send the error message to stdout like you did. I also suspect that this part of the script predates 6124aee (add a quiet option to git-checkout, 2007-02-01) where the command learned to be more quiet during the normal operation. Perhaps you can replace the line with git checkout -q "$onto^0" and be done with it. I haven't tested it, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
