From: Junio C Hamano Date: Tue, 15 Jul 2008 15:22:25 GMT Subject: Re: [PATCH] git-rebase.sh: Display error output from git-checkout when detaching HEAD fails. Message-ID: <7vmykj2mvi.fsf@gitster.siamese.dyndns.org> In-Reply-To: <1096648c0807141257i76f70322p5a16c86c1c826a66@mail.gmail.com> "Rob Shearman" writes: > 2008/7/11 Junio C Hamano : > ... >> I think this very much is done deliberately by somebody who knows the >> shell to discard everything. > > Why wasn't "git checkout "$onto^0" &> /dev/null" used then? Then only > reason I can come up with would be portability,... Yes, we are quite old fashioned when it comes to shell scripting. >> ... Perhaps you can replace the line with >> >> git checkout -q "$onto^0" >> >> and be done with it. I haven't tested it, though. > > I just tested it and it solves the original issue whilst not > displaying unnecessary messages during a rebase. For reference, the > attached script reproduces the issue that I was trying to solve. > > Should I resend the patch (like the following) now that it is > effectively completely your work? Your choice. The issues you might want to consider when making that choice are: - Resending something that is trivial may seem waste of time on your part; - Bringing the issue up is more than half of solving it, and you deserve the credit. By resending with a clear commit log message you assure this; - I am handling many patches for git.git that are readily applicable immediately after I read them in my mbox, while creating a commit out of this discussion is something I need to "work on". When I get around to do some git work tonight, I may not even recall this dialogue, and the solution may be forgotten. - I am lazy and may forget to pass --author="Rob Shearman " even if I remember this conversation and when I make a commit myself; I just made a commit out of this discussion before I forget, so no need to resend for this one, but in general I'd appreciate a resend in general ;-) -- >8 -- From: Junio C Hamano Date: Mon, 14 Jul 2008 14:05:35 -0700 Subject: [PATCH] git-rebase: report checkout failure When detaching the HEAD to the base commit, the "git checkout" command could fail if, for example, upstream contains a file that would overrwrite a local, untracked file. Unconditionally discarding the standard error stream was done to squelch the progress and notices back when checkout did not have -q option, but there is no reason to keep doing it anymore. Noticed by Robert Shearman. Signed-off-by: Junio C Hamano --- git-rebase.sh | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/git-rebase.sh b/git-rebase.sh index e2d85ee..7825f88 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -376,9 +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 || - die "could not detach HEAD" -# git reset --hard "$onto^0" +git checkout -q "$onto^0" || die "could not detach HEAD" # If the $onto is a proper descendant of the tip of the branch, then # we just fast forwarded. -- 1.5.6.3.473.gc658e