threads / discuss / 283

Git cancel work

Subject: Git cancel work

## tl;dr

6 messages between Apr 24, 2005 and Apr 24, 2005.

replies: 5people: 3as markdown or json

Dan Weber· Apr 24, 2005, 04:34 UTC · lore

I noticed that git cancel was always doing a full checkout. So I figured, "what about just checking out the modified files?". Attached is a patch to do so.

Dan
Lets not do a full checkout on git cancel

--- commit 47197d9accb420ec55f6dfd63d990d4fb2537330 tree e8f3699877dd220440808087632ef87cce2288a7 parent c83b95297c2a6336c2007548f909769e0862b509 author Dan Weber <dan@mirrorlynx.com> 1114316504 -0400 committer Dan Weber <dan@mirrorlynx.com> 1114316504 -0400

Index: gitcancel.sh
===================================================================
--- 2aaf94eae20acc451553766f3c063bc46cfa75c6/gitcancel.sh  (mode:100755 sha1:26eecb50bc812211454e98d98e8818387ae97df5)
+++ e8f3699877dd220440808087632ef87cce2288a7/gitcancel.sh  (mode:100755 sha1:c836b75bb8a7c461b2d0ad536d1c3bc2d2440ab4)
@@ -2,6 +2,7 @@
 #
 # Cancels current edits in the working tree.
 # Copyright (c) Petr Baudis, 2005
+# Copyright (c) Dan Weber, 2005
 #
 # This script reverts the working tree to a consistent state before
 # any changes to it (including merges etc) were done.
@@ -26,5 +27,23 @@
 rm -f .git/blocked .git/merging .git/merging-sym .git/merge-base
 read-tree -m $(tree-id) || read-tree $(tree-id)
 
-checkout-cache -f -a
-update-cache --refresh
+general() {
+	for name in $(diff-cache -r $(tree-id)|awk '{print $4}')
+	do
+		checkout-cache -f $name
+	done
+	update-cache --refresh
+}
+
+full () {
+	checkout-cache -f -a
+	update-cache --refresh
+}
+
+
+if [ "$1" == "-a" -o "$1" == "--full" -o "$1" == "--all" ]; then
+	full
+else
+	general
+fi
+
Petr Baudis· Apr 24, 2005, 12:49 UTC · re: Dan Weber · lore

Re: Git cancel work

Dear diary, on Sun, Apr 24, 2005 at 06:34:44AM CEST, I got a letter where Dan Weber <dan@mirrorlynx.com> told me that...

> I noticed that git cancel was always doing a full checkout.  So I figured, 
> "what about just checking out the modified files?".  Attached is a patch 
> to do so.
But that is what checkout-cache -f -a does:
        if (!stat(path, &st)) {
                unsigned changed = cache_match_stat(ce, &st);
                if (!changed)
                        return 0;
in checkout_entry().
-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
Dan Weber· Apr 24, 2005, 12:59 UTC · re: Petr Baudis · lore

Re: Git cancel work

Why does it take so ridiculously long then?
Dan
On Sun, 24 Apr 2005, Petr Baudis wrote:
Show 20 quoted lines
> Dear diary, on Sun, Apr 24, 2005 at 06:34:44AM CEST, I got a letter
> where Dan Weber <dan@mirrorlynx.com> told me that...
>> I noticed that git cancel was always doing a full checkout.  So I figured,
>> "what about just checking out the modified files?".  Attached is a patch
>> to do so.
>
> But that is what checkout-cache -f -a does:
>
>        if (!stat(path, &st)) {
>                unsigned changed = cache_match_stat(ce, &st);
>                if (!changed)
>                        return 0;
>
> in checkout_entry().
>
> -- 
> 				Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
>
Petr Baudis· Apr 24, 2005, 13:00 UTC · re: Dan Weber · lore

Re: Git cancel work

Dear diary, on Sun, Apr 24, 2005 at 02:59:31PM CEST, I got a letter where Dan Weber <dan@mirrorlynx.com> told me that...

> Why does it take so ridiculously long then?
That's strange.

Could you show some time comparisons between the current and your approaches? (Please make sure the cache condition is about the same for both tests; it makes many orders of magnitude difference.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
Dan Weber· Apr 24, 2005, 13:04 UTC · re: Petr Baudis · lore

Re: Git cancel work

On Sun, 24 Apr 2005, Petr Baudis wrote:
Show 10 quoted lines
> Dear diary, on Sun, Apr 24, 2005 at 02:59:31PM CEST, I got a letter
> where Dan Weber <dan@mirrorlynx.com> told me that...
>> Why does it take so ridiculously long then?
>
> That's strange.
>
> Could you show some time comparisons between the current and your
> approaches? (Please make sure the cache condition is about the same for
> both tests; it makes many orders of magnitude difference.)
>
No need.  Go try running it on the linux kernel. The command git cancel.
Dan
Show 5 quoted lines
> -- 
> 				Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
>
Dan Holmsand· Apr 24, 2005, 13:11 UTC · re: Dan Weber · lore

Re: Git cancel work

Dan Weber wrote:
> 
> Why does it take so ridiculously long then?

Perhaps because you're using an older version of git-pasky? Newer versions use read-tree -m, which speeds up git cancel by several orders of magnitude for me.

Btw. gitdiff.sh and gitseek.sh are still using read-tree without "-m", so they are still very slow.

For exampel, try "git diff -p" on the kernel. Compare with plain "git diff".
/dan

← back to recent threads