Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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.
-
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
