Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
Linus Torvalds [EMAIL PROTECTED] writes: 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/. I see this -avz incantation mentioned everytime when rsync is involved. But, is the -z part (compression) really necessary knowing that we're dealing with an already compressed tree? Doesn't it put additional strain on the rsync server without any benefit in this case? Or I might be too ignorant and not understand some internals well, but then... I would like to know the reason. :) Regards, -- Zlatko - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Wed, 20 Apr 2005, Zlatko Calusic wrote: I see this -avz incantation mentioned everytime when rsync is involved. But, is the -z part (compression) really necessary knowing that we're dealing with an already compressed tree? Doesn't it put additional strain on the rsync server without any benefit in this case? Or I might be too ignorant and not understand some internals well, but then... I would like to know the reason. :) I'm not a big rsync user, so I just copied the examples of others. You're right, for git, you should not use compression for files (I don't know if rsync compresses the directory listings by default, I assume it does). Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, 2005-04-19 at 15:00 -0700, Linus Torvalds wrote: On Tue, 19 Apr 2005, Greg KH wrote: 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). No, I think it's a bug in your domainname changes. I don't think you should do the domainname at all if the hostname has a dot in it. Most machines I have access to (and that includes machines that are professionally maintained, not just my own cruddy setup) says (none) to domainname and have the full hostname in hostname. And even the ones that use domainname tend to not have a fully qualified DNS domain there. You need to use dnsdomainname to get that, and I don't even know how to do it with standard libc. Correct me if I am wrong, but the right way to do this is to set the hostname to just that - the hostname, and add 'domain foo.com' to /etc/resolv.conf. Then you should get something like (for say www1.foo.com): $ hostname www1 $ dnsdomainname foo.com $ hostname -f www1.foo.com I know for some buggy software the workaround was to set the hostname to the FQDN, but that is really just a kludge, and the software should rather be fixed (had to patch postfix some time back for instance). -- Martin Schlemmer signature.asc Description: This is a digitally signed message part
Re: [GIT PATCH] I2C and W1 bugfixes for 2.6.12-rc2
On Tue, Apr 19, 2005 at 06:27:38PM -0400, Daniel Jacobowitz wrote: On Tue, Apr 19, 2005 at 03:00:04PM -0700, Linus Torvalds wrote: On Tue, 19 Apr 2005, Greg KH wrote: 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). No, I think it's a bug in your domainname changes. I don't think you should do the domainname at all if the hostname has a dot in it. Most machines I have access to (and that includes machines that are professionally maintained, not just my own cruddy setup) says (none) to domainname and have the full hostname in hostname. And even the ones that use domainname tend to not have a fully qualified DNS domain there. You need to use dnsdomainname to get that, and I don't even know how to do it with standard libc. So how about something like this? (Somebody who actually knows how these things should be done - please feel free to pipe up). The glibc documentation blows for this, but what getdomainname comes from uname(2), not from any DNS-related configuration. Debian only ever sets this if you're using NIS. Well, somehow Gentoo sets this up properly, and I'm not using NIS. Hm, my SuSE boxes on the other hand... There's no real great way to get the current hostname; a lot of applications do a reverse DNS lookup on the primary network interface, with appropriate handwaving to define primary. Easiest might be to punt to hostname --fqdn, or an equivalent to its algorithm - which appears to be fetch the hostname from uname, do a DNS lookup on that, and a reverse DNS lookup on the result. Ick. Let's stick with Linus's patch for now... thanks, greg k-h - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
