Git cancel work

Git cancel work

[Dan Weber]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 165 bytes --]


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

[-- Attachment #2: Fast Cancel --]
[-- Type: TEXT/PLAIN, Size: 1420 bytes --]

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
+

Re: Git cancel work

[Petr Baudis]

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

Re: Git cancel work

[Dan Weber]

Why does it take so ridiculously long then?

Dan

On Sun, 24 Apr 2005, Petr Baudis wrote:

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

Re: Git cancel work

[Petr Baudis]

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

Re: Git cancel work

[Dan Weber]

On Sun, 24 Apr 2005, Petr Baudis wrote:

> 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
> -- 
> 				Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor
>

Re: Git cancel work

[Dan Holmsand]

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