Re: Be more verbose when checkout takes a long time

[Junio C Hamano <gitster@pobox.com>]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> So I find it irritating when git thinks for a long time without telling me 
> what's taking so long. And by "long time" I definitely mean less than two 
> seconds, which is already way too long for me.

Do you mean more than two or less than two?

> Now, git read-tree already had support for the "-v" flag that does nice 
> updates about what's going on, but it was delayed by two seconds, and if 
> the thing had already done more than half by then it would be quiet even 
> after that, so in practice it meant that we migth be quiet for up to four 
> seconds. Much too long.

Geez you are impatient ;-).

The other user of start_progress_delay uses 95% as cutoff.  and
probably 50% was too low, but that may just be bikeshedding.

> ... Quite frankly, I'm not really sure why it disabled 
> error messages in the first place: ...
> ...
> Now, I'm sure this had a good reason (for the "git checkout -m" case), but 
> it did make the common case of git-checkout really annoying.

I agree.  Perhaps we can add some message when "-m" codepath
falls back to the three-way merge to make "merge-error" less
scary.  Perhaps like:

 git-checkout.sh |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/git-checkout.sh b/git-checkout.sh
index bd74d70..5e36136 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -210,11 +210,14 @@ then
     git read-tree $v --reset -u $new
 else
     git update-index --refresh >/dev/null
-    merge_error=$(git read-tree -m -u --exclude-per-directory=.gitignore $old $new 2>&1) || (
-	case "$merge" in
-	'')
-		echo >&2 "$merge_error"
+    git read-tree -$v m -u --exclude-per-directory=.gitignore $old $new || (
+	case "$merge,$v" in
+	,*)
 		exit 1 ;;
+	1,)
+		;; # quiet
+	*)
+		echo >&2 "Falling back to 3-way merge..." ;;
 	esac
 
 	# Match the index to the working tree, and do a three-way.