[GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
elenstev at mesatop.com
Wed Apr 20 01:04:48 CEST 2005
On Tuesday 19 April 2005 04:38 pm, Linus Torvalds wrote:
> 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?
Yes, I was using a very recent version of the pasky tools,
I had created the repo this morning with git init YOUR_RSYC_URL_FOR_LINUX-2.6.
I did time git pull origin and watched the fur fly.
Then, the flurry of patching file blah messages, followed by a rather
pregnant pause after the last patching message.
I wasn't complaining about the 4 minutes, just the lack of feedback
during the majority of that time. And most of it was after the last
patching file message.
> 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
> # "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.
> 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.
OK. I may try some of this tomorrow from work, where I have a fat pipe.
I'm on dialup from home, and I suspect not very many folks want to hear
the sad tale of how long it takes to get the kernel over 56k dialup.
More information about the lm-sensors