Be more verbose when checkout takes a long time

Be more verbose when checkout takes a long time

[Linus Torvalds]

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.

This hits me when doing a large pull and the checkout takes a long time, 
or when just switching to another branch that is old and again checkout 
takes a while.

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.

So this patch changes the timeout to just one second, which makes it much 
more palatable to me.

The other thing this patch does is that "git checkout" now doesn't disable 
the "-v" flag when doing its thing, and only disables the output when 
given the -q flag. Quite frankly, I'm not really sure why it disabled 
error messages in the first place: it used to do

	merge_error=$(git read-tree .. 2>&1) || (
		case "$merge" in
		'')
			echo >&2 "$merge_error"
			exit 1 ;;
		...

which obviously meant that the "-v" flag was useless, because it was 
suppressed by the fact that any outpu just went to "merge_error" and then 
printed just once if we didn't do a merge.

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. So I just 
removed that whole "suppress error messages from git-read-tree" thing. 
People who use -m all the time probably disagree with this patch. I dunno.

Anyway, with this I no longer get that annoying pregnant pause when doing 
big branch switches.

Comments?

		Linus

---
 git-checkout.sh |    3 +--
 unpack-trees.c  |    2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/git-checkout.sh b/git-checkout.sh
index bd74d70..4b07fc4 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -210,10 +210,9 @@ 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) || (
+    git read-tree $v -m -u --exclude-per-directory=.gitignore $old $new || (
 	case "$merge" in
 	'')
-		echo >&2 "$merge_error"
 		exit 1 ;;
 	esac
 
diff --git a/unpack-trees.c b/unpack-trees.c
index ec558f9..0f62609 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -301,7 +301,7 @@ static void check_updates(struct cache_entry **src, int nr,
 		}
 
 		progress = start_progress_delay("Checking out files",
-						total, 50, 2);
+						total, 50, 1);
 		cnt = 0;
 	}
 

Re: Be more verbose when checkout takes a long time

[Junio C Hamano]

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.

Re: Be more verbose when checkout takes a long time

[Linus Torvalds]

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

> 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?

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

Re: Be more verbose when checkout takes a long time

[Junio C Hamano]

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

> On Sat, 23 Feb 2008, Junio C Hamano wrote:
>
>> 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?
>
> 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.

Ok, then.

Unfortunately it will be short-lived on 'master' as I have been
planning to merge Daniel's rewrite soon ;-)

Re: Be more verbose when checkout takes a long time

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
> ...
>> Sounds sane to me.
>
> Ok, then.
>
> Unfortunately it will be short-lived on 'master' as I have been
> planning to merge Daniel's rewrite soon ;-)

So here it is ;-)

Thanks to the unpack_trees_options.gently flag, this does not
have to say "Falling back to..." because the first "attempt to
switch normally" would silently fail.

---

 builtin-checkout.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/builtin-checkout.c b/builtin-checkout.c
index 5f176c6..283831e 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -232,6 +232,7 @@ static int merge_working_tree(struct checkout_opts *opts,
 			topts.update = 1;
 			topts.merge = 1;
 			topts.gently = opts->merge;
+			topts.verbose_update = !opts->quiet;
 			topts.fn = twoway_merge;
 			topts.dir = xcalloc(1, sizeof(*topts.dir));
 			topts.dir->show_ignored = 1;

[PATCH] checkout: error out when index is unmerged even with -m

[Junio C Hamano]

Even when -m is given to allow fallilng back to 3-way merge
while switching branches, we should refuse if the original index
is unmerged.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * I think this bug was inherited from the scripted version.
   Fixing it is much easier here.

 builtin-checkout.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/builtin-checkout.c b/builtin-checkout.c
index 283831e..e028270 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -226,8 +226,8 @@ static int merge_working_tree(struct checkout_opts *opts,
 		refresh_cache(REFRESH_QUIET);
 
 		if (unmerged_cache()) {
-			ret = opts->merge ? -1 :
-				error("you need to resolve your current index first");
+			error("you need to resolve your current index first");
+			return 1;
 		} else {
 			topts.update = 1;
 			topts.merge = 1;

Re: [PATCH] checkout: error out when index is unmerged even with -m

[Daniel Barkalow]

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

> Even when -m is given to allow fallilng back to 3-way merge
> while switching branches, we should refuse if the original index
> is unmerged.

Acked-by: Daniel Barkalow <barkalow@iabervon.org>

> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
>  * I think this bug was inherited from the scripted version.
>    Fixing it is much easier here.

I'm pretty sure it was. I wasn't clear on all the motivations for checkout 
-m behavior, so I tried to make it exactly the same.

>  builtin-checkout.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index 283831e..e028270 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -226,8 +226,8 @@ static int merge_working_tree(struct checkout_opts *opts,
>  		refresh_cache(REFRESH_QUIET);
>  
>  		if (unmerged_cache()) {
> -			ret = opts->merge ? -1 :
> -				error("you need to resolve your current index first");
> +			error("you need to resolve your current index first");
> +			return 1;
>  		} else {
>  			topts.update = 1;
>  			topts.merge = 1;

Ditch the "else" now that it's not needed? And, actually, I think you can 
ditch most of the use of "ret" when there's only one case for getting to 
needing a real merge.

	-Daniel
*This .sig left intentionally blank*