Re: Be more verbose when checkout takes a long time

Linus Torvalds [off-list ref] 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.

On Sat, 23 Feb 2008, Junio C Hamano wrote:

Linus Torvalds [off-list ref] writes:

quoted

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?

I mean that "long time" starts at a point that is less than two seconds.

Anything over a second is a long time for me.

Geez you are impatient ;-).

I like to call it "discerning in my time usage".

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

I did think that 50% was a bit low, and considered upping it to 75, but 
with the one-second thing it wasn't as much of a deal any more. 

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:

Sounds sane to me.

		Linus