threads / discuss / 12275

Be more verbose when checkout takes a long time

Subject: Be more verbose when checkout takes a long time

## tl;dr

7 messages between Feb 23, 2008 and Feb 24, 2008.

replies: 6people: 3as markdown or json

Linus Torvalds· Feb 23, 2008, 21:36 UTC · lore

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;
 	}
Junio C Hamano· Feb 23, 2008, 22:20 UTC · re: Linus Torvalds · lore

Re: Be more verbose when checkout takes a long time

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?
Show 5 quoted lines
> 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.

Show 5 quoted lines
> ... 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.
Linus Torvalds· Feb 23, 2008, 22:32 UTC · re: Junio C Hamano · lore

Re: Be more verbose when checkout takes a long time

On Sat, 23 Feb 2008, Junio C Hamano wrote:
Show 7 quoted lines
> 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
Junio C Hamano· Feb 23, 2008, 22:37 UTC · re: Linus Torvalds · lore

Re: Be more verbose when checkout takes a long time

Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 29 quoted lines
> 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 ;-)

Junio C Hamano· Feb 23, 2008, 23:42 UTC · re: Junio C Hamano · lore

Re: Be more verbose when checkout takes a long time

Junio C Hamano <gitster@pobox.com> writes:
Show 8 quoted lines
> 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;
Junio C Hamano· Feb 23, 2008, 23:45 UTC · re: Junio C Hamano · lore

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

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;
Daniel Barkalow· Feb 24, 2008, 06:29 UTC · re: Junio C Hamano · lore

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

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>
Show 5 quoted lines
> 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.

Show 18 quoted lines
>  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*

← back to recent threads