Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tuesday 19 April 2005 05:38 pm, Linus Torvalds wrote: > > On Tue, 19 Apr 2005, Steven Cole wrote: > > > > 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. > > That should be exactly the thing that the new "read-tree -m" fixes. > > Before, when you read in a new tree (which is what you do when you update > to somebody elses version), git would throw all the cached information > away, and so you'd end up doing a "checkout-cache -f -a" that re-wrote > every single checked-out file, followed by "update-cache --refresh" that > then re-created the cache for every single file. > > With the new read-tree, the same sequence (assuming you have the "-m" > flag to tell read-tree to merge the cache information) will now only write > out and re-check the files that actually changed due to the update or > merge. > > So that last phase should go from minutes to seconds - instead of checking > 17,000+ files, you'd end up checking maybe a few hundred for most "normal" > updates. > > For example, updating all the way from the git root (ie plain 2.6.12-rc2) > to the current head, only 577 files have changed, and the rest (16,740) > should never be touched at all. > > You can see why doing just the 577 instead of the full 17,317 might speed > things up a bit ;) > > Linus Cool. Petr, I hope this works like this with your tools tomorrow. > > PS. Of course, right now it probably does make sense to waste some time > occasionally, and run "fsck-cache $(cat .git/HEAD)" every once in a while. > Just in case.. > > Sounds like a good thing to schedule for $WEEHOUR. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 19 Apr 2005, Steven Cole wrote: > > 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. That should be exactly the thing that the new "read-tree -m" fixes. Before, when you read in a new tree (which is what you do when you update to somebody elses version), git would throw all the cached information away, and so you'd end up doing a "checkout-cache -f -a" that re-wrote every single checked-out file, followed by "update-cache --refresh" that then re-created the cache for every single file. With the new read-tree, the same sequence (assuming you have the "-m" flag to tell read-tree to merge the cache information) will now only write out and re-check the files that actually changed due to the update or merge. So that last phase should go from minutes to seconds - instead of checking 17,000+ files, you'd end up checking maybe a few hundred for most "normal" updates. For example, updating all the way from the git root (ie plain 2.6.12-rc2) to the current head, only 577 files have changed, and the rest (16,740) should never be touched at all. You can see why doing just the 577 instead of the full 17,317 might speed things up a bit ;) Linus PS. Of course, right now it probably does make sense to waste some time occasionally, and run "fsck-cache $(cat .git/HEAD)" every once in a while. Just in case.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Wed, Apr 20, 2005 at 01:04:48AM CEST, I got a letter where Steven Cole <[EMAIL PROTECTED]> told me that... > 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. That must've been the update-cache. Well, you can listen to your strained disk crepitating direly. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
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. > > > > real3m54.909s > > user0m14.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 > 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. > 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. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Wed, Apr 20, 2005 at 12:38:17AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > Just say no to patches. FYI, I've - per Junio's suggestion - made git merge's fast-forward to apply show-diff output as a patch instead. This is roughly equal to doing the sanity check against local changes, except that it handles them, while at it. (Tree merge refuses to work when there are local changes.) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Wed, Apr 20, 2005 at 12:45:02AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > > "PB" == Petr Baudis <[EMAIL PROTECTED]> writes: > > PB> I'm wondering if doing > > PB> if [ "$(show-diff)" ]; then > PB> git diff | git apply > PB> else > PB> checkout-cache -f -a > PB> fi > > PB> would actually buy us some time; or, how common is it for people to have > PB> no local changes whatsoever, and whether relative slowdown of additional > PB> show-diff to git diff would actually matter. > > "show-diff -s" perhaps. Also wouldn't it be faster to pipe > show-diff output (not git diff output) to patch (not git apply)? Excellent idea, thanks. Changed git merge to do this. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Wed, 20 Apr 2005, Petr Baudis wrote: > > I will probably not buy git-export, though. (That is, it is merged, but > I won't make git frontend for it.) My "git export" already does > something different, but more importantly, "git patch" of mine already > does effectively the same thing as you do, just for a single patch; so I > will probably just extend it to do it for an (a,b] range of patches. That's fine. It was a quick hack, just to show that if somebody wants to, the data is trivially exportable. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
> "PB" == Petr Baudis <[EMAIL PROTECTED]> writes: PB> I'm wondering if doing PB> if [ "$(show-diff)" ]; then PB> git diff | git apply PB> else PB> checkout-cache -f -a PB> fi PB> would actually buy us some time; or, how common is it for people to have PB> no local changes whatsoever, and whether relative slowdown of additional PB> show-diff to git diff would actually matter. "show-diff -s" perhaps. Also wouldn't it be faster to pipe show-diff output (not git diff output) to patch (not git apply)? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Tue, Apr 19, 2005 at 10:20:47PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > Pasky? Can you check my latest git stuff, notably read-tree.c and the > changes to git-pull-script? I've made git merge to use read-tree -m, HTH. I will probably not buy git-export, though. (That is, it is merged, but I won't make git frontend for it.) My "git export" already does something different, but more importantly, "git patch" of mine already does effectively the same thing as you do, just for a single patch; so I will probably just extend it to do it for an (a,b] range of patches. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
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. > > real3m54.909s > user0m14.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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Wed, Apr 20, 2005 at 12:19:01AM CEST, I got a letter where Steven Cole <[EMAIL PROTECTED]> told me that... > Linus Torvalds wrote: > > > >On Tue, 19 Apr 2005, Greg KH wrote: > > > >>Nice, it looks like the merge of this tree, and my usb tree worked just > >>fine. > > > > > >Yup, it all seems to work out. > > [many files patched] > patching file mm/mmap.c > patching file net/bridge/br_sysfs_if.c > patching file scripts/ver_linux > --^ > Hey, that's my patch! Last...and least. > But perhaps a progress bar right about here might be > a good thing for the terminally impatient. > > real3m54.909s > user0m14.835s > sys 0m10.587s > > 4 minutes might be long enough to cause some folks to lose hope. I'm wondering if doing if [ "$(show-diff)" ]; then git diff | git apply else checkout-cache -f -a fi would actually buy us some time; or, how common is it for people to have no local changes whatsoever, and whether relative slowdown of additional show-diff to git diff would actually matter. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Linus Torvalds wrote: On Tue, 19 Apr 2005, Greg KH wrote: Nice, it looks like the merge of this tree, and my usb tree worked just fine. Yup, it all seems to work out. [many files patched] patching file mm/mmap.c patching file net/bridge/br_sysfs_if.c patching file scripts/ver_linux --^ Hey, that's my patch! Last...and least. But perhaps a progress bar right about here might be a good thing for the terminally impatient. real3m54.909s user0m14.835s sys 0m10.587s 4 minutes might be long enough to cause some folks to lose hope. Steven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, Apr 19, 2005 at 01:20:47PM -0700, Linus Torvalds wrote: > > > On Tue, 19 Apr 2005, Greg KH wrote: > > > > Ok, if you want some practice with "real" merges, feel free to merge from > > the following two trees whenever you are ready: > > kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/ > > for 11 aoe bugfix patches, and: > > kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ > > for 13 driver core, sysfs, and debugfs fixes. > > Done, pushed out. Can you verify that the end result looks sane to you? I > just cheched that the diffstat looks similar (mine claims just 108 lines > changed in aoecmd.c - possibly due to different diff formats). Looks good to me (the diffstat difference is probably because the patches were consecutive, and the sum of them are smaller (modifying same parts of the files, etc.)) The git-changes-script shows that you picked up everything from my trees successfully (assuming we trust that so far) and a raw diff looks good too. Two "odd" things in the changelog: commit cebc2380426b64aaa60a169834a7aefc956c tree 484292d57c19acbf04cf5c783e7d26181b95e96e parent 334a4e1b19f7f471594f7abd3bfead3720c1bd61 author Hugh Dickins <[EMAIL PROTECTED]> Wed, 20 Apr 2005 03:29:23 -0700 committer Linus Torvalds <[EMAIL PROTECTED](none)> Wed, 20 Apr 2005 03:29:23 -0700 It looks like your domain name isn't set up properly for your box (which is why it worked for you, but not me before, causing that patch). Also the date is in the future with the -0700, yet the time is in UTC. Oh wait, that's a 'git log' thing, the raw changeset is correct, I guess I'll wait for Pasky to fix that :) > And yes, my new merge thing seems to have kept the index-cache much better > up-to-date, allowing an optimized checkout-cache -f -a to work and only > get the new files. Very nice. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 19 Apr 2005, Greg KH wrote: > > Ok, if you want some practice with "real" merges, feel free to merge from > the following two trees whenever you are ready: > kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/ > for 11 aoe bugfix patches, and: > kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ > for 13 driver core, sysfs, and debugfs fixes. Done, pushed out. Can you verify that the end result looks sane to you? I just cheched that the diffstat looks similar (mine claims just 108 lines changed in aoecmd.c - possibly due to different diff formats). And yes, my new merge thing seems to have kept the index-cache much better up-to-date, allowing an optimized checkout-cache -f -a to work and only get the new files. Pasky? Can you check my latest git stuff, notably read-tree.c and the changes to git-pull-script? Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, Apr 19, 2005 at 12:40:44PM -0700, Linus Torvalds wrote: > I'm still working out some performance issues with merges (the actual > "merge" operation itself is very fast, but I've been trying to make the > subsequent "update the working directory tree to the right thing" be much > better). Ok, if you want some practice with "real" merges, feel free to merge from the following two trees whenever you are ready: kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/ for 11 aoe bugfix patches, and: kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ for 13 driver core, sysfs, and debugfs fixes. The diffstats are: aoe: Documentation/aoe/mkdevs.sh |1 Documentation/aoe/mkshelf.sh |1 Documentation/aoe/todo.txt| 14 Documentation/aoe/udev-install.sh |6 +- drivers/block/aoe/aoe.h | 23 +-- drivers/block/aoe/aoeblk.c|5 + drivers/block/aoe/aoecmd.c| 110 ++ drivers/block/aoe/aoedev.c|8 +- drivers/block/aoe/aoenet.c|8 +- 9 files changed, 111 insertions(+), 65 deletions(-) driver: Documentation/kref.txt| 221 +- drivers/base/class.c |2 drivers/base/core.c |3 drivers/base/firmware_class.c |3 drivers/base/platform.c |1 drivers/usb/host/hc_crisv10.c |1 fs/partitions/check.c |2 fs/sysfs/file.c | 35 ++ include/linux/debugfs.h | 14 +- include/linux/sysfs.h |7 + lib/kobject.c |7 - net/bridge/br_sysfs_if.c |2 scripts/ver_linux |2 13 files changed, 290 insertions(+), 10 deletions(-) No rush, but they should be good test for your merge speeds, as they are based off of an older HEAD than your current one :) > In other words, I want it to be at the point where people can do > > git pull > > and it will "just work", at least for people who don't have any local > changes in their tree. None of this "check out all the files again" crap. That would be very nice to have. > But how about a plan that we go "live" tomorrow - assuming nobody finds > any problems before that, of course. That's fine with me. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 19 Apr 2005, Greg KH wrote: > > Nice, it looks like the merge of this tree, and my usb tree worked just > fine. Yup, it all seems to work out. > So, what does this now mean? Is your kernel.org git tree now going to > be the "real" kernel tree that you will be working off of now? Should > we crank up the nightly snapshots and emails to the -commits list? I'm not quite ready to consider it "real", but I'm getting there. I'm still working out some performance issues with merges (the actual "merge" operation itself is very fast, but I've been trying to make the subsequent "update the working directory tree to the right thing" be much better). > Can I rely on the fact that these patches are now in your tree and I can > forget about them? :) > > Just wondering how comfortable you feel with your git tree so far. Hold off for one more day. I'm very comfortable with how well git has worked out so far, and yes, mentally I consider this "the tree", but the fact is, git isn't exactly easy on "normal users". I think my merge stuff and Pasky's scripts are getting there, but I want to make sure that we have a version of Pasky's scripts that use the new "read-tree -m" optimizations to make tracking a tree faster, and I'd like to have them _tested_ a bit first. In other words, I want it to be at the point where people can do git pull and it will "just work", at least for people who don't have any local changes in their tree. None of this "check out all the files again" crap. But how about a plan that we go "live" tomorrow - assuming nobody finds any problems before that, of course. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Mon, Apr 18, 2005 at 09:39:38PM -0700, Greg KH wrote: > Alright, let's try some small i2c and w1 patches... > > Could you merge with: > kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/ Nice, it looks like the merge of this tree, and my usb tree worked just fine. So, what does this now mean? Is your kernel.org git tree now going to be the "real" kernel tree that you will be working off of now? Should we crank up the nightly snapshots and emails to the -commits list? Can I rely on the fact that these patches are now in your tree and I can forget about them? :) Just wondering how comfortable you feel with your git tree so far. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Mon, Apr 18, 2005 at 09:39:38PM -0700, Greg KH wrote: Alright, let's try some small i2c and w1 patches... Could you merge with: kernel.org/pub/scm/linux/kernel/git/gregkh/i2c-2.6.git/ Nice, it looks like the merge of this tree, and my usb tree worked just fine. So, what does this now mean? Is your kernel.org git tree now going to be the real kernel tree that you will be working off of now? Should we crank up the nightly snapshots and emails to the -commits list? Can I rely on the fact that these patches are now in your tree and I can forget about them? :) Just wondering how comfortable you feel with your git tree so far. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 19 Apr 2005, Greg KH wrote: Nice, it looks like the merge of this tree, and my usb tree worked just fine. Yup, it all seems to work out. So, what does this now mean? Is your kernel.org git tree now going to be the real kernel tree that you will be working off of now? Should we crank up the nightly snapshots and emails to the -commits list? I'm not quite ready to consider it real, but I'm getting there. I'm still working out some performance issues with merges (the actual merge operation itself is very fast, but I've been trying to make the subsequent update the working directory tree to the right thing be much better). Can I rely on the fact that these patches are now in your tree and I can forget about them? :) Just wondering how comfortable you feel with your git tree so far. Hold off for one more day. I'm very comfortable with how well git has worked out so far, and yes, mentally I consider this the tree, but the fact is, git isn't exactly easy on normal users. I think my merge stuff and Pasky's scripts are getting there, but I want to make sure that we have a version of Pasky's scripts that use the new read-tree -m optimizations to make tracking a tree faster, and I'd like to have them _tested_ a bit first. In other words, I want it to be at the point where people can do git pull repo-address and it will just work, at least for people who don't have any local changes in their tree. None of this check out all the files again crap. But how about a plan that we go live tomorrow - assuming nobody finds any problems before that, of course. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, Apr 19, 2005 at 12:40:44PM -0700, Linus Torvalds wrote: I'm still working out some performance issues with merges (the actual merge operation itself is very fast, but I've been trying to make the subsequent update the working directory tree to the right thing be much better). Ok, if you want some practice with real merges, feel free to merge from the following two trees whenever you are ready: kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/ for 11 aoe bugfix patches, and: kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ for 13 driver core, sysfs, and debugfs fixes. The diffstats are: aoe: Documentation/aoe/mkdevs.sh |1 Documentation/aoe/mkshelf.sh |1 Documentation/aoe/todo.txt| 14 Documentation/aoe/udev-install.sh |6 +- drivers/block/aoe/aoe.h | 23 +-- drivers/block/aoe/aoeblk.c|5 + drivers/block/aoe/aoecmd.c| 110 ++ drivers/block/aoe/aoedev.c|8 +- drivers/block/aoe/aoenet.c|8 +- 9 files changed, 111 insertions(+), 65 deletions(-) driver: Documentation/kref.txt| 221 +- drivers/base/class.c |2 drivers/base/core.c |3 drivers/base/firmware_class.c |3 drivers/base/platform.c |1 drivers/usb/host/hc_crisv10.c |1 fs/partitions/check.c |2 fs/sysfs/file.c | 35 ++ include/linux/debugfs.h | 14 +- include/linux/sysfs.h |7 + lib/kobject.c |7 - net/bridge/br_sysfs_if.c |2 scripts/ver_linux |2 13 files changed, 290 insertions(+), 10 deletions(-) No rush, but they should be good test for your merge speeds, as they are based off of an older HEAD than your current one :) In other words, I want it to be at the point where people can do git pull repo-address and it will just work, at least for people who don't have any local changes in their tree. None of this check out all the files again crap. That would be very nice to have. But how about a plan that we go live tomorrow - assuming nobody finds any problems before that, of course. That's fine with me. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 19 Apr 2005, Greg KH wrote: Ok, if you want some practice with real merges, feel free to merge from the following two trees whenever you are ready: kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/ for 11 aoe bugfix patches, and: kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ for 13 driver core, sysfs, and debugfs fixes. Done, pushed out. Can you verify that the end result looks sane to you? I just cheched that the diffstat looks similar (mine claims just 108 lines changed in aoecmd.c - possibly due to different diff formats). And yes, my new merge thing seems to have kept the index-cache much better up-to-date, allowing an optimized checkout-cache -f -a to work and only get the new files. Pasky? Can you check my latest git stuff, notably read-tree.c and the changes to git-pull-script? Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, Apr 19, 2005 at 01:20:47PM -0700, Linus Torvalds wrote: On Tue, 19 Apr 2005, Greg KH wrote: Ok, if you want some practice with real merges, feel free to merge from the following two trees whenever you are ready: kernel.org/pub/scm/linux/kernel/git/gregkh/aoe-2.6.git/ for 11 aoe bugfix patches, and: kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6.git/ for 13 driver core, sysfs, and debugfs fixes. Done, pushed out. Can you verify that the end result looks sane to you? I just cheched that the diffstat looks similar (mine claims just 108 lines changed in aoecmd.c - possibly due to different diff formats). Looks good to me (the diffstat difference is probably because the patches were consecutive, and the sum of them are smaller (modifying same parts of the files, etc.)) The git-changes-script shows that you picked up everything from my trees successfully (assuming we trust that so far) and a raw diff looks good too. Two odd things in the changelog: commit cebc2380426b64aaa60a169834a7aefc956c tree 484292d57c19acbf04cf5c783e7d26181b95e96e parent 334a4e1b19f7f471594f7abd3bfead3720c1bd61 author Hugh Dickins [EMAIL PROTECTED] Wed, 20 Apr 2005 03:29:23 -0700 committer Linus Torvalds [EMAIL PROTECTED](none) Wed, 20 Apr 2005 03:29:23 -0700 It looks like your domain name isn't set up properly for your box (which is why it worked for you, but not me before, causing that patch). Also the date is in the future with the -0700, yet the time is in UTC. Oh wait, that's a 'git log' thing, the raw changeset is correct, I guess I'll wait for Pasky to fix that :) And yes, my new merge thing seems to have kept the index-cache much better up-to-date, allowing an optimized checkout-cache -f -a to work and only get the new files. Very nice. thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Linus Torvalds wrote: On Tue, 19 Apr 2005, Greg KH wrote: Nice, it looks like the merge of this tree, and my usb tree worked just fine. Yup, it all seems to work out. [many files patched] patching file mm/mmap.c patching file net/bridge/br_sysfs_if.c patching file scripts/ver_linux --^ Hey, that's my patch! Last...and least. But perhaps a progress bar right about here might be a good thing for the terminally impatient. real3m54.909s user0m14.835s sys 0m10.587s 4 minutes might be long enough to cause some folks to lose hope. Steven - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Wed, Apr 20, 2005 at 12:19:01AM CEST, I got a letter where Steven Cole [EMAIL PROTECTED] told me that... Linus Torvalds wrote: On Tue, 19 Apr 2005, Greg KH wrote: Nice, it looks like the merge of this tree, and my usb tree worked just fine. Yup, it all seems to work out. [many files patched] patching file mm/mmap.c patching file net/bridge/br_sysfs_if.c patching file scripts/ver_linux --^ Hey, that's my patch! Last...and least. But perhaps a progress bar right about here might be a good thing for the terminally impatient. real3m54.909s user0m14.835s sys 0m10.587s 4 minutes might be long enough to cause some folks to lose hope. I'm wondering if doing if [ $(show-diff) ]; then git diff | git apply else checkout-cache -f -a fi would actually buy us some time; or, how common is it for people to have no local changes whatsoever, and whether relative slowdown of additional show-diff to git diff would actually matter. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
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. real3m54.909s user0m14.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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Tue, Apr 19, 2005 at 10:20:47PM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... Pasky? Can you check my latest git stuff, notably read-tree.c and the changes to git-pull-script? I've made git merge to use read-tree -m, HTH. I will probably not buy git-export, though. (That is, it is merged, but I won't make git frontend for it.) My git export already does something different, but more importantly, git patch of mine already does effectively the same thing as you do, just for a single patch; so I will probably just extend it to do it for an (a,b] range of patches. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
PB == Petr Baudis [EMAIL PROTECTED] writes: PB I'm wondering if doing PB if [ $(show-diff) ]; then PB git diff | git apply PB else PB checkout-cache -f -a PB fi PB would actually buy us some time; or, how common is it for people to have PB no local changes whatsoever, and whether relative slowdown of additional PB show-diff to git diff would actually matter. show-diff -s perhaps. Also wouldn't it be faster to pipe show-diff output (not git diff output) to patch (not git apply)? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Wed, 20 Apr 2005, Petr Baudis wrote: I will probably not buy git-export, though. (That is, it is merged, but I won't make git frontend for it.) My git export already does something different, but more importantly, git patch of mine already does effectively the same thing as you do, just for a single patch; so I will probably just extend it to do it for an (a,b] range of patches. That's fine. It was a quick hack, just to show that if somebody wants to, the data is trivially exportable. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Wed, Apr 20, 2005 at 12:45:02AM CEST, I got a letter where Junio C Hamano [EMAIL PROTECTED] told me that... PB == Petr Baudis [EMAIL PROTECTED] writes: PB I'm wondering if doing PB if [ $(show-diff) ]; then PB git diff | git apply PB else PB checkout-cache -f -a PB fi PB would actually buy us some time; or, how common is it for people to have PB no local changes whatsoever, and whether relative slowdown of additional PB show-diff to git diff would actually matter. show-diff -s perhaps. Also wouldn't it be faster to pipe show-diff output (not git diff output) to patch (not git apply)? Excellent idea, thanks. Changed git merge to do this. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Wed, Apr 20, 2005 at 12:38:17AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... Just say no to patches. FYI, I've - per Junio's suggestion - made git merge's fast-forward to apply show-diff output as a patch instead. This is roughly equal to doing the sanity check against local changes, except that it handles them, while at it. (Tree merge refuses to work when there are local changes.) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
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. real3m54.909s user0m14.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 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. 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. Steven - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Dear diary, on Wed, Apr 20, 2005 at 01:04:48AM CEST, I got a letter where Steven Cole [EMAIL PROTECTED] told me that... 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. That must've been the update-cache. Well, you can listen to your strained disk crepitating direly. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ C++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 19 Apr 2005, Steven Cole wrote: 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. That should be exactly the thing that the new read-tree -m fixes. Before, when you read in a new tree (which is what you do when you update to somebody elses version), git would throw all the cached information away, and so you'd end up doing a checkout-cache -f -a that re-wrote every single checked-out file, followed by update-cache --refresh that then re-created the cache for every single file. With the new read-tree, the same sequence (assuming you have the -m flag to tell read-tree to merge the cache information) will now only write out and re-check the files that actually changed due to the update or merge. So that last phase should go from minutes to seconds - instead of checking 17,000+ files, you'd end up checking maybe a few hundred for most normal updates. For example, updating all the way from the git root (ie plain 2.6.12-rc2) to the current head, only 577 files have changed, and the rest (16,740) should never be touched at all. You can see why doing just the 577 instead of the full 17,317 might speed things up a bit ;) Linus PS. Of course, right now it probably does make sense to waste some time occasionally, and run fsck-cache $(cat .git/HEAD) every once in a while. Just in case.. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tuesday 19 April 2005 05:38 pm, Linus Torvalds wrote: On Tue, 19 Apr 2005, Steven Cole wrote: 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. That should be exactly the thing that the new read-tree -m fixes. Before, when you read in a new tree (which is what you do when you update to somebody elses version), git would throw all the cached information away, and so you'd end up doing a checkout-cache -f -a that re-wrote every single checked-out file, followed by update-cache --refresh that then re-created the cache for every single file. With the new read-tree, the same sequence (assuming you have the -m flag to tell read-tree to merge the cache information) will now only write out and re-check the files that actually changed due to the update or merge. So that last phase should go from minutes to seconds - instead of checking 17,000+ files, you'd end up checking maybe a few hundred for most normal updates. For example, updating all the way from the git root (ie plain 2.6.12-rc2) to the current head, only 577 files have changed, and the rest (16,740) should never be touched at all. You can see why doing just the 577 instead of the full 17,317 might speed things up a bit ;) Linus Cool. Petr, I hope this works like this with your tools tomorrow. PS. Of course, right now it probably does make sense to waste some time occasionally, and run fsck-cache $(cat .git/HEAD) every once in a while. Just in case.. Sounds like a good thing to schedule for $WEEHOUR. Steven - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
