On Tue, 19 Apr 2005, Steven Cole wrote:

But perhaps a progress bar right about here might be
a good thing for the terminally impatient.

real    3m54.909s
user    0m14.835s
sys     0m10.587s

4 minutes might be long enough to cause some folks to lose hope.

Well, the real operations took only 15 seconds. What kind of horribe 
person are you, that you don't have all of the kernel in your disk cache 
already? Shame on you.

Or was the 4 minutes for downloading all the objest too?

Anyway, it looks like you are using pasky's scripts, and the old 
"patch-based" upgrade at that. You certainly will _not_ see the

	[many files patched]
	patching file mm/mmap.c
	..

if you use a real git merge. That's probable be the real problem here.

Real merges have no patches taking place _anywhere_. And they take about 
half a second. Doing an "update" of your tree should _literally_ boil down 
to

	#
	# "repo" needs to point to the repo we update from
	#
	rsync -avz --ignore-existing $repo/objects/. .git/objects/.
	rsync -L $repo/HEAD .git/NEW_HEAD || exit 1
	read-tree -m $(cat .git/NEW_HEAD) || exit 1
	checkout-cache -f -a
	update-cache --refresh
	mv .git/NEW_HEAD .git/HEAD

and if it does anything else, it's literally broken. Btw, the above does
need my "read-tree -m" thing which I committed today.

(CAREFUL: the above is not a good script, because it _will_ just overwrite 
all your old contents with the stuff you updated to. You should thus not 
actually use something like this, but a "git update" should literally end 
up doing the above operations in the end, and just add proper checking).

And if that takes 4 minutes, you've got problems.

Just say no to patches. 

		Linus

PS: If you want a clean tree without any old files or anything else, for
that matter, you can then do a "show-files -z --others | xargs -0 rm", but
be careful: that will blow away _anything_ that wasn't revision controlled
with git. So don't blame me if your pr0n collection is gone afterwards.