Re: Re: more git updates..
Dear diary, on Sun, Apr 10, 2005 at 07:53:40AM CEST, I got a letter where Christopher Li <[EMAIL PROTECTED]> told me that... > On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote: > > > > But I am wondering what your plans are to handle renames---or > > does git already represent them? > > > > Rename should just work. It will create a new tree object and you > will notice that in the entry that changed, the hash for the blob > object is the same. Which is of course wrong when you want to do proper merging, examine per-file history, etc. One solution which springs to my mind is to have a UUID accompany each blob and tree; that will take relatively lot of space though, and I'm not sure it is really worth it. How many renames were there in the 64k commits so far anyway? -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: more git updates..
Dear diary, on Sun, Apr 10, 2005 at 07:53:40AM CEST, I got a letter where Christopher Li [EMAIL PROTECTED] told me that... On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote: But I am wondering what your plans are to handle renames---or does git already represent them? Rename should just work. It will create a new tree object and you will notice that in the entry that changed, the hash for the blob object is the same. Which is of course wrong when you want to do proper merging, examine per-file history, etc. One solution which springs to my mind is to have a UUID accompany each blob and tree; that will take relatively lot of space though, and I'm not sure it is really worth it. How many renames were there in the 64k commits so far anyway? -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: more git updates..
Dear diary, on Sun, Apr 10, 2005 at 11:28:54AM CEST, I got a letter where Junio C Hamano [EMAIL PROTECTED] told me that... CL == Christopher Li [EMAIL PROTECTED] writes: CL On Sun, Apr 10, 2005 at 12:51:59AM -0700, Junio C Hamano wrote: But I am wondering what your plans are to handle renames---or does git already represent them? CL Rename should just work. It will create a new tree object and you CL will notice that in the entry that changed, the hash for the blob CL object is the same. Sorry, I was unclear. But doesn't that imply that a SCM built on top of git storage needs to read all the commit and tree records up to the common ancestor to show tree diffs between two forked tree? No. See diff-tree output and http://pasky.or.cz/~pasky/dev/git/gitdiff-do for how it's done. Basically, you just take the two trees and compare them linearily (do a normal diff on them, essentialy). Then the differences you spot this way are everything what needs to appear in the patch. I suspect that another problem is that noticing the move of the same SHA1 hash from one pathname to another and recognizing that as a rename would not always work in the real world, because sometimes people move files *and* make small changes at the same time. If git is meant to be an intermediate format to suck existing kernel history out of BK so that the history can be converted for the next SCM chosen for the kernel work, I would imagine that there needs to be a way to represent such a case. Maybe convert a file rename as two git trees (one tree for pure move which immediately followed by another tree for edit) if it is not a pure move? Actually, this could be possible too I think. We will have to make diff-tree two-pass, but it is already so blinding fast that I guess that doesn't hurt too much. I might try to get my hands on that. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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/
[ANNOUNCE] git-pasky-0.1
Hello, so I released git-pasky-0.1, my set of patches and scripts upon Linus' git, aimed at human usability and to an extent a SCM-like usage. You can get it at http://pasky.or.cz/~pasky/dev/git/git-pasky-base.tar.bz2 and after unpacking and building (make) do git pull pasky to get the latest changes from my branch. If you already have some git from my branch which can do pulling, you can bring yourself up to date by doing just gitpull.sh pasky (but this style of usage is deprecated now). Please see the README for some details regarding usage etc. You can find the changes from the last announcement in the ChangeLog (the previous announcement corresponds to commit id 5125d089ad862f16a306b4942155092e1dce1c2d). The most important change is probably recursive diff addition, and making git ignore the nsec of ctime and mtime, since it is totally unreliable and likes to taint random files as modified. My near future plans include especially some merge support; I think it should be rather easy, actually. I'll also add some simple tagging mechanism. I've decided to postpone the file moving detection, since there's no big demand for it now. ;-) I will also need to do more testing on the linux kernel tree. Committing patch-2.6.7 on 2.6.6 kernel and then diffing results in $ time gitdiff.sh `parent-id` `tree-id` p real5m37.434s user1m27.113s sys 2m41.036s which is pretty horrible, it seems to me. Any benchmarking help is of course welcomed, as well as any other feedback. BTW, what would be the best (most complete) source for the BK tree metadata? Should I dig it from the BKCVS gateway, or is there a better source? Where did you get the sparse git database from, Linus? (BTW, it would be nice to get sparse.git with the directories as separate.) Have fun, -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Sun, Apr 10, 2005 at 07:45:12PM CEST, I got a letter where Ingo Molnar [EMAIL PROTECTED] told me that... * Willy Tarreau [EMAIL PROTECTED] wrote: I will also need to do more testing on the linux kernel tree. Committing patch-2.6.7 on 2.6.6 kernel and then diffing results in $ time gitdiff.sh `parent-id` `tree-id` p real5m37.434s user1m27.113s sys 2m41.036s which is pretty horrible, it seems to me. Any benchmarking help is of course welcomed, as well as any other feedback. it seems from the numbers that your system doesnt have enough RAM for this and is getting IO-bound? Not the only problem, without I/O, he will go down to 4m8s (u+s) which is still in the same order of magnitude. probably not the only problem - but if we are lucky then his system was just trashing within the kernel repository and then most of the overhead is the _unnecessary_ IO that happened due to that (which causes CPU overhead just as much). The dominant system time suggests so, to a certain degree. Maybe this is wishful thinking. It turns out to be the forks for doing all the cuts and such what is bogging it down so awfully (doing diff-tree takes 0.48s ;-). I do about 15 forks per change, I guess, and for some reason cut takes a long of time on its own. I've rewritten the cuts with the use of bash arrays and other smart stuff. I somehow don't feel comfortable using this and prefer the old-fashioned ways, but it would be plain unusable without this. Now I'm down to real1m21.440s user0m32.374s sys 0m42.200s and I kinda doubt if it is possible to cut this much down. Almost no disk activity, I have almost everything cached by now, apparently. Anyway, you can git pull to get the optimized version. Thanks for the help, -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Sun, Apr 10, 2005 at 09:13:19PM CEST, I got a letter where Willy Tarreau [EMAIL PROTECTED] told me that... On Sun, Apr 10, 2005 at 08:45:22PM +0200, Petr Baudis wrote: It turns out to be the forks for doing all the cuts and such what is bogging it down so awfully (doing diff-tree takes 0.48s ;-). I do about 15 forks per change, I guess, and for some reason cut takes a long of time on its own. I've rewritten the cuts with the use of bash arrays and other smart stuff. I somehow don't feel comfortable using this and prefer the old-fashioned ways, but it would be plain unusable without this. I've encountered the same problem in a config-generation script a while ago. Fortunately, bash provides enough ways to remove most of the forks, but the result is less portable. I've downloaded your code, but it does not compile here because of the tv_nsec fields in struct stat (2.4, glibc 2.2), so I cannot use it to get the most up to date version to take a look at the script. Basically, Ok, I decided to stop this nsec madness (since it broke show-diff anyway at least on my ext3), and you get it only if you pass -DNSEC to CFLAGS now. Hope this fixes things for you. :-) BTW, I regularly update the public copy as accessible on the web. all the 'cut' and 'sed' can be removed, as well as the 'dirname'. You can also call mkdir only if the dirs don't exist. I really think you should end up with only one fork in the loop to call 'diff'. You still need to extract the file by cat-file too. ;-) And rm the files after it compares them (so that we don't fill /tmp with crap like certain awful programs like to do). But I will conditionalize the mkdir calls, thanks for the suggestion - I think that's the last bit to be squeezed from this loop (I'll yet check on the read proposal - I considered it before and turned down for some reason, can't remember why anymore, though). Thanks, -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: RE: more git updates..
Dear diary, on Mon, Apr 11, 2005 at 12:07:37AM CEST, I got a letter where Luck, Tony [EMAIL PROTECTED] told me that... ..snip.. Hey, I may end up being wrong, and yes, maybe I should have done a two-level one. The good news is that we can trivially fix it later (even dynamically - we can make the sha1 object tree layout be a per-tree config option, and there would be no real issue, so you could make small projects use a flat version and big projects use a very deep structure etc). You'd just have to script some renames to move the files around. It depends on how many eco-system shell scripts get built that need to know about the layout ... if some shell/perl libraries encode this filename layout (and people use them) ... then switching later would indeed be painless. FWIW, my short-term plans include support for monotone-like hash ID shortening - it's enough to use the shortest leading unique part of the ID to identify the revision. I will poke to the object repository for that. I also already have Randy Dunlap's git lsobj, which will list all objects of a specified type (very useful especially when looking for orphaned commits and such rather lowlevel work). -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Sun, Apr 10, 2005 at 10:38:11PM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... On Sun, 10 Apr 2005, Petr Baudis wrote: It turns out to be the forks for doing all the cuts and such what is bogging it down so awfully (doing diff-tree takes 0.48s ;-). I do about 15 forks per change, I guess, and for some reason cut takes a long of time on its own. Heh. Can you pull my current repo, which has diff-tree -R that does what the name suggests, and which should be faster than the 0.48 sec you see.. Funnily enough, now after some more cache teasing it's ~0.185. Your one still ~0.17, though. :/ (That might be because of the format changes, though, since you do less printing now.) (BTW, all those measurements are done on my AMD K6 walking on 1600MHz, 512M RAM, about 200M available for caches.) Just out of interest, did you have a look at my diff-tree -r implementation and decided that you don't like it, or you weren't aware of it? I will probably take most of your diff-tree change, but I'd prefer to do the sha1-tree mapping directly in diff_tree(). It may not matter a lot, since actually generating the diff from the file contents is what is expensive, but remember my goal: I want the expense of a diff-tree to be relative to the size of the diff, so that implies that small diffs haev to be basically instantaenous. So I care. Me too, of course. So I just tried the 2.6.7-2.6.8 diff, and for me the new recursive diff-tree can generate the _list_ of files changed in zero time: real0m0.079s user0m0.067s sys 0m0.024s but then _doing_ the diff is pretty expensive (in this case 3800+ files changed, so you have to unpack 7600+ objects - and even unpacking isn't the expensive part, the expense is literally in the diff operation itself). Me, the stuff I automate is the small steps. Doing a single checkin. So that's the case I care about going fast, when a diff-tree will likely have maybe five files or something. That's why I want the small incremental cases to go fast - it it takes me a minute to generate a diff for a _release_, that's not a big deal. I make one release every other month, but I work with lots of small patches all the time. I see. Anyway, with a fast diff-tree, you should be able to generate the list of objects for a fast merge. That's next. (And by merge, I of course mean suck. I'm talking about the old CVS three-way merge, and you have to specify the common parent explicitly and it won't handle any renames or any other crud. But it would get us to something that might actually be useful for simple things. Which is why diff-tree is important - it gives the information about what to tell merge). I currently already do a merge when you track someone's source - it will throw away your previous HEAD record though, so if you committed some local changes after the previous pull, you will get orphaned commits and the changes will turn to uncommitted ones. I have some ideas regarding how to do it properly (and do any arbitrary merging, for that matter), I hope to get to it as soon as I catch up with you. :-) BTW, the three-way merge comes from RCS. That reminds me, is there any tool which will take .rej files and throw them into the file to create rcsmerge-like conflicts? Perhaps it's fault of my bad tools, but I prefer to work with the inline rejects much more to .rej files (except to actually notice the rejects). -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: more git updates..
Dear diary, on Sun, Apr 10, 2005 at 08:42:53PM CEST, I got a letter where Christopher Li [EMAIL PROTECTED] told me that... I totally agree that odds is really really small. That is why it is not worthy to handle the case. People hit that can just add a new line or some thing to avoid it, if it happen after all. It is the little peace of mind to know for sure that did not happen. I am just paranoid. BTW, I've merged the check to git-pasky some time ago, you can disable it in the Makefile. It is by default on now, until someone convinces me it actually affects performance measurably. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: Re: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Mon, Apr 11, 2005 at 01:10:58AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... On Mon, 11 Apr 2005, Petr Baudis wrote: I currently already do a merge when you track someone's source - it will throw away your previous HEAD record though Not only that, it doesn't do what I consider a merge. A real merge should have two or more parents. The commit-tree command already allows that: just add any arbitrary number of -p x switches (well, I think I limited it to 16 parents, but that's just a totally random number, there's nothing in the file format or anything else that limits it). So while you've merged my data, but you've not actually merged my revision history in your tree. Well, that's exactly what I was (am) going to do. :-) That's also why I said that I (virtually) throw the local commits away now. Instead, if there were any local commits, I will do git merge: commit-tree $(write-tree) -p $local_head -p $tracked_tree Note that I will need to make this two-phase - first applying the changes, then doing the commit; between those two phases, the user should resolve potential conflicts and check if the merge went right. I think I will name the first phase git merge and the second phase will be just git commit, and I will store the merge information in .dircache/. (BTW, I think the directory name is pretty awful; what about .git/ ?) And the reason a real merge _has_ to show both parents properly is that unless you do that, you can never merge sanely another time without getting lots of clashes from the previous merge. So it's important that a merge really shows both trees it got data from. This is, btw, also the reason I haven't merged with your tree - I want to get to the point where I really _can_ merge without throwing away the information. In fact, at this point I'd rather not merge with your tree at all, because I consider your tree to be corrupt thanks to lacking the merge history. So you've done the data merge, but not the history merge. And because you didn't do the history merge, there's no way to automatically find out what point of my tree you merged _with_. See? And since I have no way to see what point in time you merged with me, now I can't generate a nice 3-way diff against the last common ancestor of both of our trees. So now I can't do a three-way merge with you based on any sane ancestor, unless I start guessing which ancestor of mine you merged with. Now, that guess is easy enough to do with a project like git which currently has just a few tens of commits and effectively only two parallell development trees, but the whole point is to get to a system where that isn't true.. Well, I've wanted to get the basic things working first before doing git merge. (Especially since until recently, diff-tree was PITA to work with, and before that it didn't even exist.) If you want, I can rebuild my tree with doing the merging properly, after I have git merge working. (BTW, it would be useful to have a tool which just blindly takes what you give it on input and throws it to an object of given type; I will need to construct arbitrary commits during the rebuild if I'm to keep the correct dates.) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Sun, Apr 10, 2005 at 11:39:02PM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... On Sun, 10 Apr 2005, Linus Torvalds wrote: Can you pull my current repo, which has diff-tree -R that does what the name suggests, and which should be faster than the 0.48 sec you see.. Actually, I changed things around. Everybody hated the lines, so I put a changed thing on a line of its own with a * instead. So you'd now see lines like *100644-100644 1874e031abf6631ea51cf6177b82a1e662f6183e-e8181df8499f165cacc6a0d8783be7143013d410 CREDITS which means that the CREDITS file has changed, and it shows you the mode - mode transition (that didn't change in this case) and the sha1 - sha1 transition. So now it's always just one line per change. Firthermore, the filename is always field 3, if you use spaces as delimeters, regardless of whether it's a +/-/* field. That's great, just when I finally managed to properly fix the xargs boundary case in gitdiff-do (without throwing away the NUL-termination). You know how to please people! ;-) (Not that I'd have *anything* against the change. The logic is simpler and you'll be actually able to work with diff-tree a little sanely.) BTW, it is quite handy to have the entry type in the listing (guessing that from mode in the script just doesn't feel right and doing explicit cat-file kills the performance). I would also really prefer the fields separated by tabs. It looks nicer on the screen (aligned, e.g. modes and type are varsized), and is also easier to parse (cut defaults to tabs as delimiters, for example). So let's say you want to merge two trees (dst1 and dst2) from a common parent (src), what you would do is: - get the list of files to merge: diff-tree -R dst1 dst2 | tr '\0' '\n' merge-files ...oh, I probably forgot to ask - why did you choose -R instead of -r? It looks rather alien to me; if it starts by 'diff', my hand writes -r without thinking. - Which of those were changed by src - dstX? diff-tree -R src dst1 | tr '\0' '\n' | join -j 3 - merge-files dst1-change diff-tree -R src dst2 | tr '\0' '\n' | join -j 3 - merge-files dst2-change - Which of those are common to both? Let's see what the merge list is: join dst1-change dst2-change merge-list and hopefully you'd usually be working on a very small list of files by then (everything else you'd just pick from one of the destination trees directly - you've got the name, the sha-file, everything: no need to even look at the data). Ok, this looks reasonable. (Provided that I DWYM regarding the joins.) Does this sound sane? Pasky? Wanna try a git merge thing? Starting off with the user having to tell what the common parent tree is - we can try to do the automatically find best common parent crud later. THAT may be expensive. I will definitively try git merge, but maybe not this night anymore (it's already 1:32 here now). -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Mon, Apr 11, 2005 at 01:46:50AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... On Mon, 11 Apr 2005, Petr Baudis wrote: (BTW, it would be useful to have a tool which just blindly takes what you give it on input and throws it to an object of given type; I will need to construct arbitrary commits during the rebuild if I'm to keep the correct dates.) Hah. That's what COMMITTER_NAME COMMITTER_EMAIL and COMMITTER_DATE are there for. There's two things to commits: when (and by whom) it was committed to a tree, and when the changes were really done. So set the COMMITTER_xxx things to the person/time you want to consider the _original_ one, and let commit-tree author you as the creator of the commit itself. The regular ChangeLog thing should only show the author and original time, but it's nice to see who created the commit itself. I already use those - look at my ChangeLog. (That's because for certain reasons I'm working on git in a half-broken chrooted environment.) When rebuilding the tree from scratch, I wanted like to do it transparently - that is, so that noone could notice that I rebuilt it, since it effectively still _is_ the original tree from the data standpoint, just the history flow is actually correct this time. Btw, the COMMITTER_ environment variables are very confusingly named. They actually go into the _author_ line in the commit object. I'm a total retard, and I really don't know why I called it COMMITTER_xxx instead of AUTHOR_xxx. So, who will fix it in his tree first! ;-) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: more git updates..
Dear diary, on Mon, Apr 11, 2005 at 01:14:57AM CEST, I got a letter
where Paul Jackson [EMAIL PROTECTED] told me that...
Useful explanation - thanks, Linus.
Is this picture and description accurate:
==
working directory files (foo.c)
^
^|
| upward ops|downward ops |
| --| |
| checkout-cache |update-cache |
| show-diff | v
v
current directory cache (.dircache/index)
^
^|
| upward ops|downward ops |
| --| |
| read-tree| write-tree |
||commit-tree |
| v
v
git filesystem (blobs, trees, commits: .dircache/{HEAD,objects})
Well, except that from purely technical standpoint commit-tree has
nothing to do in this picture - it creates new object in the git
filesystem based on its input data, but regardless to the directory
cache or current tree. It probably still belongs where it is from the
workflow standpoint, though.
..snip..
Minor question:
I must have an old version - I got 'git-0.03', but
it doesn't have 'checkout-cache', and its 'read-tree'
directly writes my working files.
How do I get a current version? Well, one way I see,
and that's to pick up Pasky's:
http://pasky.or.cz/~pasky/dev/git/git-pasky-base.tar.bz2
Perhaps that's the best way?
You can take mine, and do:
git pull pasky
git pull linus
cp .dircache/HEAD .dircache/HEAD.local
Now, your tree and git filesystem is up to date.
git track local
Now, when you do git pull pasky, your working tree will not be updated
automatically anymore.
git track linus
Now, you start tracking Linus' tree instead. Note that the initial
update will blow away the scripts in your current tree, so before you do
the last two steps you will probably want to clone the tree and set PATH
to the one still tracking me, so you get all the comfort. ;-)
--
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
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 license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Dear diary, on Mon, Apr 11, 2005 at 02:20:52AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... Btw, does anybody have strong opinions on the license? I didn't put in a COPYING file exactly because I was torn between GPLv2 and OSL2.1. I'm inclined to go with GPLv2 just because it's the most common one, but I was wondering if anybody really had strong opinions. For example, I'd really make it v2 by default like the kernel, since I'm sure v3 will be fine, but regardless of how sure I am, I'm _not_ a gambling man. Oh, I wanted to ask about this too. I'd mostly prefer GPLv2 (I have no problem with the version restriction, I usually do it too), it's the one I'm mostly familiar with and OSL appears to be incompatible with GPL (at least FSF says so about OSL1.0), which might create various annoying issues. I hate when licenses get in my way and prevent me to possibly include some useful code. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Sun, Apr 10, 2005 at 10:38:11PM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... ..snip.. Can you pull my current repo, which has diff-tree -R that does what the name suggests, and which should be faster than the 0.48 sec you see.. Am I just missing something, or your diff-tree doesn't handle added/removed directories? (Mine does! *hint* *hint* It also doesn't bother with dynamic allocation, but someone might consider the static path buffer ugly. Anyway, I hacked it with a plan to do a massive cleanup of the file later.) -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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/
[ANNOUNCE] git-pasky-0.2
Hello, here goes git-pasky-0.2, my set of patches and scripts upon Linus' git, aimed at human usability and to an extent a SCM-like usage. If you already have a previous git-pasky version, just git pull pasky to get it. Otherwise, you can get it from: http://pasky.or.cz/~pasky/dev/git/ Please see the README there and/or the parent post for detailed instructions. You can find the changes from the last announcement in the ChangeLog (releases have separate commits so you can find them easily; they are also tagged for purpose of diffing etc). This is release contains mostly bugfixes, performance enhancements (especially w.r.t. git diff), and some merges with Linus (except for diff-tree, where I merged only the new output format). New features are trivial - support for tagging and short SHA1 ids; you can use only the start of the SHA1 hash long enough to be unambiguous. My immediate plan is implementing git merge, which I will do tommorow, if noone will do it before that is. ;-) Any feedback/opinions/suggestions/patches (especially patches) are welcome. Have fun, -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: more git updates..
Dear diary, on Sun, Apr 10, 2005 at 01:31:10AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Sat, 9 Apr 2005, Linus Torvalds wrote: > > > > Actually, I guess I wouldn't have to change the format. I could just > > extend the existing "tree" object to be able to point to other trees, and > > that's it. > > Done, and pushed out. The current git.git repository seems to do all of > this correctly. ..snip.. Ok, so now I can dare announce it, I hope. I hacked my branch of git somewhat, kept in sync with Linus, and now I have something to show. Please see it at http://pasky.or.cz/~pasky/dev/git/ It is basically a set of (still rather crude) shell scripts upon Linus' git, which make it sanely usable by mere humans for actual version tracking. Its usage _is_ going to change, so don't get too used to it (that'd be hard anyway, I suspect), but it should be working nicely. I have described most of the interesting parts and some basic usage in the README at that page. It wraps commits, supports log retrieval and comfortable diffing between any two trees. And on top of that, it can do some basic remote repositories - it will pull (rsync) from them and it can make the local copy track them - on pull, it will be updated accordingly (and your local commits on the tracked branch will get orphaned). I didn't attach a patch against Linus since I think it's pretty much useless now. It's available as against-linus.patch on the web, and you can apply it to the latest git tree (NOT 0.03). But it's probably better idea to wget my tree. You can then watch us making progress by gitpull.sh linus gitpull.sh pasky and see where we differ by: gitdiff.sh linus pasky (This is how the against-linus.patch was generated. I'd easily generate even 0.03 patch this way, but I forgot to merge the fsck at that time, so it would suck.) (Note that the tree you wget is set up to track my branch. If you want to stop tracking it (basically necessary now if you want to do local commits), do: cp .dircache/HEAD .dircache/HEAD.local gittrack.sh The cp says that something like "I want to pick up where the tracked branch left off". Otherwise, untracking would return you to your "local" branch, which is just some ancient predecessor of the pasky branch here anyway.) Note that I didn't really test it on anything but git itself yet, so I'm not sure how will it cope especially with directories - I tried to make it aware of them though. I will do some more practical testing tomorrow. Otherwise, I will probably try to consolidate the usage and documentation now, and beautify the scripts. I might start pondering some merging too. Oh, and gitpatch.sh. :-) Have fun and please share your opinions, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: Re: Kernel SCM saga..
Dear diary, on Sun, Apr 10, 2005 at 03:01:12AM CEST, I got a letter where Phillip Lougher <[EMAIL PROTECTED]> told me that... > On Apr 9, 2005 3:53 AM, Petr Baudis <[EMAIL PROTECTED]> wrote: > > > FWIW, I made few small fixes (to prevent some trivial usage errors to > > cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and > > gitlog.sh - heavily inspired by what already went through the mailing > > list. Everything is available at http://pasky.or.cz/~pasky/dev/git/ > > (including .dircache, even though it isn't shown in the index), the > > cumulative patch can be found below. The scripts aim to provide some > > (obviously very interim) more high-level interface for git. > > I did a bit of playing about with the changelog generate script, > trying to produce a faster version. The attached version uses a > couple of improvements to be a lot faster (e.g. no recursion in the > common case of one parent). > > FWIW it is 7x faster than makechlog.sh (4.342 secs vs 34.129 secs) and > 28x faster than gitlog.sh (4.342 secs vs 2 mins 4 secs) on my > hardware. You mileage may of course vary. Wow, really impressive! Great work, I've merged it (if you don't object, of course). Wondering why I wasn't in the Cc list, BTW. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: more git updates..
Hello, Dear diary, on Sat, Apr 09, 2005 at 09:45:52PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > The good news is, the data structures/indexes haven't changed, but many of > the tools to interface with them have new (and improved!) semantics: > > In particular, I changed how "read-tree" works, so that it now mirrors > "write-tree", in that instead of actually changing the working directory, > it only updates the index file (aka "current directory cache" file from > the tree). > > To actually change the working directory, you'd first get the index file > setup, and then you do a "checkout-cache -a" to update the files in your > working directory with the files from the sha1 database. that's great. I was planning to do something with this since currently it really annoyed me. I think I will like this, even though I didn't look at the code itself yet (just on my way). > Also, I wrote the "diff-tree" thing I talked about: ..snip.. Hmm, I wonder, is this better done in C instead of a simple shell script, like my gitdiff.sh? I'd say it is more flexible and probably hardly performance-critical to have this scripted, and not difficult at all provided you have ls-tree. But maybe I'm just too fond of my script... ;-) (Ok, there's some trouble when you want to have newlines and spaces in file names, and join appears to be awfully ignorant about this... :[ ) BTW, do we care about changed modes? If so, they should probably have their place in the diff-tree output. BTW#2, I hope you will merge my ls-tree anyway, even though there is no user for it currently... I should quickly figure out some. :-) > Can you guys re-send the scripts you wrote? They probably need some > updating for the new semantics. Sorry about that ;( I'll try to merge ASAP. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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/
[PATCH] Re: Kernel SCM saga..
Dear diary, on Sat, Apr 09, 2005 at 09:08:59AM CEST, I got a letter where "Randy.Dunlap" <[EMAIL PROTECTED]> told me that... > On Sat, 9 Apr 2005 04:53:57 +0200 Petr Baudis wrote: ..snip.. > | FWIW, I made few small fixes (to prevent some trivial usage errors to > | cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and > | gitlog.sh - heavily inspired by what already went through the mailing > | list. Everything is available at http://pasky.or.cz/~pasky/dev/git/ > | (including .dircache, even though it isn't shown in the index), the > | cumulative patch can be found below. The scripts aim to provide some > | (obviously very interim) more high-level interface for git. > | > | I'm now working on tree-diff.c which will (surprise!) produce a diff > | of two trees (I'll finish it after I get some sleep, though), and then I > | will probably do some dwimmy gitdiff.sh wrapper for tree-diff and > | show-diff. At that point I might get my hand on some pull more kind to > | local changes. > > Hi, Hi, > I'll look at your scripts this weekend. I've also been > working on some, but mine are a bit more experimental (cruder) > than yours are. Anyway, here they are (attached) -- also > available at http://developer.osdl.org/rddunlap/git/ > > gitin : checkin/commit > gitwhat sha1 : what is that sha1 file (type and contents if blob or commit) > gitlist (blob, commit, tree, or all) : > list all objects with type (commit, tree, blob, or all) thanks - I had a look, but so far I borrowed only the prompt message from your gitin. ;-) I'm not sure if gitwhat would be useful for me in any way and gitlist doesn't appear too practical to me either. In the meantime, I've made some progress too. I made ls-tree, which will just convert the tree object to a human readable (and script processable) form, and wrapper gitls.sh, which will also try to guess the tree ID. parent-id will just return the commit ID(s) of the previous commit(s), practical if you want to diff against the previous commit easily etc. And finally, there is gitdiff.sh, which will produce a diff of any two trees. Everything is again available at http://pasky.or.cz/~pasky/dev/git/ and again including .dircache, even though it's invisible in the index. The cumulative patch (against 0.03) is there as well as below, generated by the ./gitdiff.sh 0af20307bb4c634722af0f9203dac7b3222c4a4f command. The empty entries are changed modes (664 vs 644), I will yet have to think about how to denote them if the content didn't change; or I might ignore them altogether...? You can obviously fetch any arbitrary change by doing the appropriate gitdiff.sh call. You can find the ids in the ChangeLog, which was generated by the plain ./gitlog.sh command. (That is for HEAD. 0af20307bb4c634722af0f9203dac7b3222c4a4f is the last commit on the Linus' branch, pass that to gitlog.sh to get his ChangeLog. ;-) Next, I will probably do some bk-style pull tool. Or perhaps first a gitpatch.sh which will verify the sha1s and do the mode changes. Linus, could you please have a look and tell me what do you think about it so far? Thanks, Petr Baudis Index: Makefile === --- 6be98a9e92a3f131a3fdf0dc3a8576fba6421569/Makefile (mode:100664 sha1:270cd4f8a8bf10cd513b489c4aaf76c14d4504a7) +++ 3f6cc0ad3e076e05281438b0de69a7d6a5522d17/Makefile (mode:100644 sha1:185ff422e68984e68da011509dec116f05fc6f8d) @@ -1,7 +1,7 @@ CFLAGS=-g -O3 -Wall CC=gcc -PROG=update-cache show-diff init-db write-tree read-tree commit-tree cat-file fsck-cache +PROG=update-cache show-diff init-db write-tree read-tree commit-tree cat-file fsck-cache ls-tree all: $(PROG) @@ -30,6 +30,9 @@ cat-file: cat-file.o read-cache.o $(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS) +ls-tree: ls-tree.o read-cache.o + $(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS) + fsck-cache: fsck-cache.o read-cache.o $(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o $(LIBS) Index: README === Index: cache.h === Index: cat-file.c === Index: commit-tree.c === Index: fsck-cache.c === Index: gitadd.sh === --- 6be98a9e92a3f131a3fdf0dc3a8576fba6421569/gitadd.sh +++ 3f6cc0ad3e076e05281438b0de69a7d6a5522d17/gitadd.sh (mode:100755 sha1:d23be758c0c9fc1cf9756bcd3ee4d7266c60a2c9) @@ -0,0 +1,13 @@ +#!/bin/sh +# +# Add new file to a GIT repository. +# Copyright (c) Petr Baudis, 20
[PATCH] Re: Kernel SCM saga..
Dear diary, on Sat, Apr 09, 2005 at 09:08:59AM CEST, I got a letter where Randy.Dunlap [EMAIL PROTECTED] told me that... On Sat, 9 Apr 2005 04:53:57 +0200 Petr Baudis wrote: ..snip.. | FWIW, I made few small fixes (to prevent some trivial usage errors to | cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and | gitlog.sh - heavily inspired by what already went through the mailing | list. Everything is available at http://pasky.or.cz/~pasky/dev/git/ | (including .dircache, even though it isn't shown in the index), the | cumulative patch can be found below. The scripts aim to provide some | (obviously very interim) more high-level interface for git. | | I'm now working on tree-diff.c which will (surprise!) produce a diff | of two trees (I'll finish it after I get some sleep, though), and then I | will probably do some dwimmy gitdiff.sh wrapper for tree-diff and | show-diff. At that point I might get my hand on some pull more kind to | local changes. Hi, Hi, I'll look at your scripts this weekend. I've also been working on some, but mine are a bit more experimental (cruder) than yours are. Anyway, here they are (attached) -- also available at http://developer.osdl.org/rddunlap/git/ gitin : checkin/commit gitwhat sha1 : what is that sha1 file (type and contents if blob or commit) gitlist (blob, commit, tree, or all) : list all objects with type (commit, tree, blob, or all) thanks - I had a look, but so far I borrowed only the prompt message from your gitin. ;-) I'm not sure if gitwhat would be useful for me in any way and gitlist doesn't appear too practical to me either. In the meantime, I've made some progress too. I made ls-tree, which will just convert the tree object to a human readable (and script processable) form, and wrapper gitls.sh, which will also try to guess the tree ID. parent-id will just return the commit ID(s) of the previous commit(s), practical if you want to diff against the previous commit easily etc. And finally, there is gitdiff.sh, which will produce a diff of any two trees. Everything is again available at http://pasky.or.cz/~pasky/dev/git/ and again including .dircache, even though it's invisible in the index. The cumulative patch (against 0.03) is there as well as below, generated by the ./gitdiff.sh 0af20307bb4c634722af0f9203dac7b3222c4a4f command. The empty entries are changed modes (664 vs 644), I will yet have to think about how to denote them if the content didn't change; or I might ignore them altogether...? You can obviously fetch any arbitrary change by doing the appropriate gitdiff.sh call. You can find the ids in the ChangeLog, which was generated by the plain ./gitlog.sh command. (That is for HEAD. 0af20307bb4c634722af0f9203dac7b3222c4a4f is the last commit on the Linus' branch, pass that to gitlog.sh to get his ChangeLog. ;-) Next, I will probably do some bk-style pull tool. Or perhaps first a gitpatch.sh which will verify the sha1s and do the mode changes. Linus, could you please have a look and tell me what do you think about it so far? Thanks, Petr Baudis Index: Makefile === --- 6be98a9e92a3f131a3fdf0dc3a8576fba6421569/Makefile (mode:100664 sha1:270cd4f8a8bf10cd513b489c4aaf76c14d4504a7) +++ 3f6cc0ad3e076e05281438b0de69a7d6a5522d17/Makefile (mode:100644 sha1:185ff422e68984e68da011509dec116f05fc6f8d) @@ -1,7 +1,7 @@ CFLAGS=-g -O3 -Wall CC=gcc -PROG=update-cache show-diff init-db write-tree read-tree commit-tree cat-file fsck-cache +PROG=update-cache show-diff init-db write-tree read-tree commit-tree cat-file fsck-cache ls-tree all: $(PROG) @@ -30,6 +30,9 @@ cat-file: cat-file.o read-cache.o $(CC) $(CFLAGS) -o cat-file cat-file.o read-cache.o $(LIBS) +ls-tree: ls-tree.o read-cache.o + $(CC) $(CFLAGS) -o ls-tree ls-tree.o read-cache.o $(LIBS) + fsck-cache: fsck-cache.o read-cache.o $(CC) $(CFLAGS) -o fsck-cache fsck-cache.o read-cache.o $(LIBS) Index: README === Index: cache.h === Index: cat-file.c === Index: commit-tree.c === Index: fsck-cache.c === Index: gitadd.sh === --- 6be98a9e92a3f131a3fdf0dc3a8576fba6421569/gitadd.sh +++ 3f6cc0ad3e076e05281438b0de69a7d6a5522d17/gitadd.sh (mode:100755 sha1:d23be758c0c9fc1cf9756bcd3ee4d7266c60a2c9) @@ -0,0 +1,13 @@ +#!/bin/sh +# +# Add new file to a GIT repository. +# Copyright (c) Petr Baudis, 2005 +# +# Takes a list of file names at the command line, and schedules them +# for addition to the GIT repository
Re: more git updates..
Hello, Dear diary, on Sat, Apr 09, 2005 at 09:45:52PM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... The good news is, the data structures/indexes haven't changed, but many of the tools to interface with them have new (and improved!) semantics: In particular, I changed how read-tree works, so that it now mirrors write-tree, in that instead of actually changing the working directory, it only updates the index file (aka current directory cache file from the tree). To actually change the working directory, you'd first get the index file setup, and then you do a checkout-cache -a to update the files in your working directory with the files from the sha1 database. that's great. I was planning to do something with this since currently it really annoyed me. I think I will like this, even though I didn't look at the code itself yet (just on my way). Also, I wrote the diff-tree thing I talked about: ..snip.. Hmm, I wonder, is this better done in C instead of a simple shell script, like my gitdiff.sh? I'd say it is more flexible and probably hardly performance-critical to have this scripted, and not difficult at all provided you have ls-tree. But maybe I'm just too fond of my script... ;-) (Ok, there's some trouble when you want to have newlines and spaces in file names, and join appears to be awfully ignorant about this... :[ ) BTW, do we care about changed modes? If so, they should probably have their place in the diff-tree output. BTW#2, I hope you will merge my ls-tree anyway, even though there is no user for it currently... I should quickly figure out some. :-) Can you guys re-send the scripts you wrote? They probably need some updating for the new semantics. Sorry about that ;( I'll try to merge ASAP. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: Re: Kernel SCM saga..
Dear diary, on Sun, Apr 10, 2005 at 03:01:12AM CEST, I got a letter where Phillip Lougher [EMAIL PROTECTED] told me that... On Apr 9, 2005 3:53 AM, Petr Baudis [EMAIL PROTECTED] wrote: FWIW, I made few small fixes (to prevent some trivial usage errors to cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and gitlog.sh - heavily inspired by what already went through the mailing list. Everything is available at http://pasky.or.cz/~pasky/dev/git/ (including .dircache, even though it isn't shown in the index), the cumulative patch can be found below. The scripts aim to provide some (obviously very interim) more high-level interface for git. I did a bit of playing about with the changelog generate script, trying to produce a faster version. The attached version uses a couple of improvements to be a lot faster (e.g. no recursion in the common case of one parent). FWIW it is 7x faster than makechlog.sh (4.342 secs vs 34.129 secs) and 28x faster than gitlog.sh (4.342 secs vs 2 mins 4 secs) on my hardware. You mileage may of course vary. Wow, really impressive! Great work, I've merged it (if you don't object, of course). Wondering why I wasn't in the Cc list, BTW. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: more git updates..
Dear diary, on Sun, Apr 10, 2005 at 01:31:10AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... On Sat, 9 Apr 2005, Linus Torvalds wrote: Actually, I guess I wouldn't have to change the format. I could just extend the existing tree object to be able to point to other trees, and that's it. Done, and pushed out. The current git.git repository seems to do all of this correctly. ..snip.. Ok, so now I can dare announce it, I hope. I hacked my branch of git somewhat, kept in sync with Linus, and now I have something to show. Please see it at http://pasky.or.cz/~pasky/dev/git/ It is basically a set of (still rather crude) shell scripts upon Linus' git, which make it sanely usable by mere humans for actual version tracking. Its usage _is_ going to change, so don't get too used to it (that'd be hard anyway, I suspect), but it should be working nicely. I have described most of the interesting parts and some basic usage in the README at that page. It wraps commits, supports log retrieval and comfortable diffing between any two trees. And on top of that, it can do some basic remote repositories - it will pull (rsync) from them and it can make the local copy track them - on pull, it will be updated accordingly (and your local commits on the tracked branch will get orphaned). I didn't attach a patch against Linus since I think it's pretty much useless now. It's available as against-linus.patch on the web, and you can apply it to the latest git tree (NOT 0.03). But it's probably better idea to wget my tree. You can then watch us making progress by gitpull.sh linus gitpull.sh pasky and see where we differ by: gitdiff.sh linus pasky (This is how the against-linus.patch was generated. I'd easily generate even 0.03 patch this way, but I forgot to merge the fsck at that time, so it would suck.) (Note that the tree you wget is set up to track my branch. If you want to stop tracking it (basically necessary now if you want to do local commits), do: cp .dircache/HEAD .dircache/HEAD.local gittrack.sh The cp says that something like I want to pick up where the tracked branch left off. Otherwise, untracking would return you to your local branch, which is just some ancient predecessor of the pasky branch here anyway.) Note that I didn't really test it on anything but git itself yet, so I'm not sure how will it cope especially with directories - I tried to make it aware of them though. I will do some more practical testing tomorrow. Otherwise, I will probably try to consolidate the usage and documentation now, and beautify the scripts. I might start pondering some merging too. Oh, and gitpatch.sh. :-) Have fun and please share your opinions, -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - 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: Re: Kernel SCM saga..
Hello,
Dear diary, on Fri, Apr 08, 2005 at 05:50:21PM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
>
>
> On Fri, 8 Apr 2005 [EMAIL PROTECTED] wrote:
> >
> > Here's a partial solution. It does depend on a modified version of
> > cat-file that behaves like cat. I found it easier to have cat-file
> > just dump the object indicated on stdout. Trivial patch for that is
> > included.
>
> Your trivial patch is trivially incorrect, though. First off, some files
> may be binary (and definitely are - the "tree" type object contains
> pathnames, and in order to avoid having to worry about special characters
> they are NUL-terminated), and your modified "cat-file" breaks that.
>
> Secondly, it doesn't check or print the tag.
FWIW, I made few small fixes (to prevent some trivial usage errors to
cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and
gitlog.sh - heavily inspired by what already went through the mailing
list. Everything is available at http://pasky.or.cz/~pasky/dev/git/
(including .dircache, even though it isn't shown in the index), the
cumulative patch can be found below. The scripts aim to provide some
(obviously very interim) more high-level interface for git.
I'm now working on tree-diff.c which will (surprise!) produce a diff
of two trees (I'll finish it after I get some sleep, though), and then I
will probably do some dwimmy gitdiff.sh wrapper for tree-diff and
show-diff. At that point I might get my hand on some pull more kind to
local changes.
Kind regards,
Petr Baudis
diff -ruN git-0.03/gitadd.sh git-devel-clean/gitadd.sh
--- git-0.03/gitadd.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitadd.sh 2005-04-09 03:17:34.220577000 +0200
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# Add new file to a GIT repository.
+# Copyright (c) Petr Baudis, 2005
+#
+# Takes a list of file names at the command line, and schedules them
+# for addition to the GIT repository at the next commit.
+#
+# FIXME: Those files are omitted from show-diff output!
+
+for file in "$@"; do
+ echo $file >>.dircache/add-queue
+done
diff -ruN git-0.03/gitcommit.sh git-devel-clean/gitcommit.sh
--- git-0.03/gitcommit.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitcommit.sh2005-04-09 03:17:34.220577000 +0200
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# Commit into a GIT repository.
+# Copyright (c) Petr Baudis, 2005
+# Based on an example script fragment sent to LKML by Linus Torvalds.
+#
+# Ignores any parameters for now, excepts changelog entry on stdin.
+#
+# FIXME: Gets it wrong for filenames containing spaces.
+
+
+if [ -r .dircache/add-queue ]; then
+ mv .dircache/add-queue .dircache/add-queue-progress
+ addedfiles=$(cat .dircache/add-queue-progress)
+else
+ addedfiles=
+fi
+changedfiles=$(show-diff -s | grep -v ': ok$' | cut -d : -f 1)
+commitfiles="$addedfiles $changedfiles"
+if [ ! "$commitfiles" ]; then
+ echo 'Nothing to commit.' >&2
+ exit
+fi
+update-cache $commitfiles
+rm -f .dircache/add-queue-progress
+
+
+oldhead=$(cat .dircache/HEAD)
+treeid=$(write-tree)
+newhead=$(commit-tree $treeid -p $oldhead)
+
+if [ "$newhead" ]; then
+ echo $newhead >.dircache/HEAD
+else
+ echo "Error during commit (oldhead $oldhead, treeid $treeid)" >&2
+fi
diff -ruN git-0.03/gitlog.sh git-devel-clean/gitlog.sh
--- git-0.03/gitlog.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitlog.sh 2005-04-09 04:28:51.227791000 +0200
@@ -0,0 +1,61 @@
+#!/bin/sh
+
+ Call this script with an object and it will produce the change
+ information for all the parents of that object
+
+ This script was originally written by Ross Vandegrift.
+# multiple parents test 1d0f4aec21e5b66c441213643426c770dc6dedc0
+# parents: ffa098b2e187b71b86a76d3cd5eb77d074a2503c
+# 6860e0d9197c7f52155466c225baf39b42d62f63
+
+# regex for parent declarations
+PARENTS="^parent [A-z0-9]{40}$"
+
+TMPCL="/tmp/gitlog.$$"
+
+# takes an object and generates the object's parent(s)
+function unpack_parents () {
+ echo "me $1"
+ echo "me $1" >>$TMPCL
+ RENTS=""
+
+ TMPCM=$(mktemp)
+ cat-file commit $1 >$TMPCM
+ while read line; do
+ if echo "$line" | egrep -q "$PARENTS"; then
+ RENTS="$RENTS "$(echo $line | sed 's/parent //g')
+ fi
+ echo $line
+ done <$TMPCM
+ rm $TMPCM
+
+ echo -e "\n--\n"
+
+ # if the last object had no parents, return
+ if [ ! "$RENTS" ]; then
+ return;
+ fi
+
+ #useful for testing
+ #echo $RENTS
+ #read
+ for
Re: Re: Kernel SCM saga..
Hello,
Dear diary, on Fri, Apr 08, 2005 at 05:50:21PM CEST, I got a letter
where Linus Torvalds [EMAIL PROTECTED] told me that...
On Fri, 8 Apr 2005 [EMAIL PROTECTED] wrote:
Here's a partial solution. It does depend on a modified version of
cat-file that behaves like cat. I found it easier to have cat-file
just dump the object indicated on stdout. Trivial patch for that is
included.
Your trivial patch is trivially incorrect, though. First off, some files
may be binary (and definitely are - the tree type object contains
pathnames, and in order to avoid having to worry about special characters
they are NUL-terminated), and your modified cat-file breaks that.
Secondly, it doesn't check or print the tag.
FWIW, I made few small fixes (to prevent some trivial usage errors to
cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and
gitlog.sh - heavily inspired by what already went through the mailing
list. Everything is available at http://pasky.or.cz/~pasky/dev/git/
(including .dircache, even though it isn't shown in the index), the
cumulative patch can be found below. The scripts aim to provide some
(obviously very interim) more high-level interface for git.
I'm now working on tree-diff.c which will (surprise!) produce a diff
of two trees (I'll finish it after I get some sleep, though), and then I
will probably do some dwimmy gitdiff.sh wrapper for tree-diff and
show-diff. At that point I might get my hand on some pull more kind to
local changes.
Kind regards,
Petr Baudis
diff -ruN git-0.03/gitadd.sh git-devel-clean/gitadd.sh
--- git-0.03/gitadd.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitadd.sh 2005-04-09 03:17:34.220577000 +0200
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# Add new file to a GIT repository.
+# Copyright (c) Petr Baudis, 2005
+#
+# Takes a list of file names at the command line, and schedules them
+# for addition to the GIT repository at the next commit.
+#
+# FIXME: Those files are omitted from show-diff output!
+
+for file in $@; do
+ echo $file .dircache/add-queue
+done
diff -ruN git-0.03/gitcommit.sh git-devel-clean/gitcommit.sh
--- git-0.03/gitcommit.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitcommit.sh2005-04-09 03:17:34.220577000 +0200
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# Commit into a GIT repository.
+# Copyright (c) Petr Baudis, 2005
+# Based on an example script fragment sent to LKML by Linus Torvalds.
+#
+# Ignores any parameters for now, excepts changelog entry on stdin.
+#
+# FIXME: Gets it wrong for filenames containing spaces.
+
+
+if [ -r .dircache/add-queue ]; then
+ mv .dircache/add-queue .dircache/add-queue-progress
+ addedfiles=$(cat .dircache/add-queue-progress)
+else
+ addedfiles=
+fi
+changedfiles=$(show-diff -s | grep -v ': ok$' | cut -d : -f 1)
+commitfiles=$addedfiles $changedfiles
+if [ ! $commitfiles ]; then
+ echo 'Nothing to commit.' 2
+ exit
+fi
+update-cache $commitfiles
+rm -f .dircache/add-queue-progress
+
+
+oldhead=$(cat .dircache/HEAD)
+treeid=$(write-tree)
+newhead=$(commit-tree $treeid -p $oldhead)
+
+if [ $newhead ]; then
+ echo $newhead .dircache/HEAD
+else
+ echo Error during commit (oldhead $oldhead, treeid $treeid) 2
+fi
diff -ruN git-0.03/gitlog.sh git-devel-clean/gitlog.sh
--- git-0.03/gitlog.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitlog.sh 2005-04-09 04:28:51.227791000 +0200
@@ -0,0 +1,61 @@
+#!/bin/sh
+
+ Call this script with an object and it will produce the change
+ information for all the parents of that object
+
+ This script was originally written by Ross Vandegrift.
+# multiple parents test 1d0f4aec21e5b66c441213643426c770dc6dedc0
+# parents: ffa098b2e187b71b86a76d3cd5eb77d074a2503c
+# 6860e0d9197c7f52155466c225baf39b42d62f63
+
+# regex for parent declarations
+PARENTS=^parent [A-z0-9]{40}$
+
+TMPCL=/tmp/gitlog.$$
+
+# takes an object and generates the object's parent(s)
+function unpack_parents () {
+ echo me $1
+ echo me $1 $TMPCL
+ RENTS=
+
+ TMPCM=$(mktemp)
+ cat-file commit $1 $TMPCM
+ while read line; do
+ if echo $line | egrep -q $PARENTS; then
+ RENTS=$RENTS $(echo $line | sed 's/parent //g')
+ fi
+ echo $line
+ done $TMPCM
+ rm $TMPCM
+
+ echo -e \n--\n
+
+ # if the last object had no parents, return
+ if [ ! $RENTS ]; then
+ return;
+ fi
+
+ #useful for testing
+ #echo $RENTS
+ #read
+ for i in `echo $RENTS`; do
+ # break cycles
+ if grep -q me $i $TMPCL; then
+ echo Already visited $i 2
+ continue
+ else
+ unpack_parents $i
+ fi
+ done
+}
+
+base=$1
+if [ ! $base ]; then
+ base=$(cat
Re: bug database braindump from the kernel summit
> Why not have the /proc/config option but instead of being plain text, > make it binary with a userspace app that can interpret it? [snip] > You'd have > 2.4.3-pre3:110101 . . . . . > I think this is against UNIX/Linux philosophy... Why we wouldn't just providing all the interface through sysctl stuff and abadon all the /proc? Cause we want to provide human-readable interface, which could be parsed really simply... We should just mean 'cat' as 'userspace app' primarily i think. At least currently we does. Also you have a big problem with forward compatibility etc. But anyway i would vote for the .config file somewhere in /boot directory. If one have a kernel from some linux distribution, it is propably actually obsolete, so it is proximity the bug is actually fixed anyway. And if he will get the newest kernel, it should do something like cp .config /boot/config. -- Peter "Pasky" Baudis Whoever coded that patch should be taken out and shot, hung, drawn and quartered then forced to write COBOL for the rest of their natural life. -- Keith Owens <[EMAIL PROTECTED]> in linux-kernel My public PGP key is on: http://pasky.ji.cz/~pasky/pubkey.txt -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++:++ a--- C+++ UL$ P+ L+++ E--- W+ N !o K- w-- !O M- !V PS+ !PE Y+ PGP+>++ t+ 5 X(+) R++ tv- b+ DI(+) D+ G e-> h! r% y? --END GEEK CODE BLOCK-- - 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: bug database braindump from the kernel summit
Why not have the /proc/config option but instead of being plain text, make it binary with a userspace app that can interpret it? [snip] You'd have 2.4.3-pre3:110101 . . . . . I think this is against UNIX/Linux philosophy... Why we wouldn't just providing all the interface through sysctl stuff and abadon all the /proc? Cause we want to provide human-readable interface, which could be parsed really simply... We should just mean 'cat' as 'userspace app' primarily i think. At least currently we does. Also you have a big problem with forward compatibility etc. But anyway i would vote for the .config file somewhere in /boot directory. If one have a kernel from some linux distribution, it is propably actually obsolete, so it is proximity the bug is actually fixed anyway. And if he will get the newest kernel, it should do something like cp .config /boot/config. -- Peter "Pasky" Baudis Whoever coded that patch should be taken out and shot, hung, drawn and quartered then forced to write COBOL for the rest of their natural life. -- Keith Owens [EMAIL PROTECTED] in linux-kernel My public PGP key is on: http://pasky.ji.cz/~pasky/pubkey.txt -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++:++ a--- C+++ UL$ P+ L+++ E--- W+ N !o K- w-- !O M- !V PS+ !PE Y+ PGP+++ t+ 5 X(+) R++ tv- b+ DI(+) D+ G e- h! r% y? --END GEEK CODE BLOCK-- - 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: (BUG) 3c509b and kernel 2.4.x
> > [1.] Upon boot, the 2.4.1 kernel misconfigures one of two 3c509b NICs > > installed in my computer as "BNC" rather than "10baseT". > > > Boot messages for eth0 in kernel 2.2: > > eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 a0 24 e9 8d a1, IRQ 10. > > and in 2.4: > > eth0: 3c509 at 0x300, BNC port, address 00 a0 24 e9 8d a1, IRQ 10. > > > > i don't know why it says BNC port.. but it isn't right, it should be 10baseT > > > I have three 3com cards( 1 3c590 Vortex, 1 3c900 Cyclone, 1 3c509B) which > > have no trouble with 2.2 kernels. But when I am trying to play with 2.4.0 > > kernel, the 3c509 just can not load. > I'm getting exactly this problems too. If 3c509 is on eth1 (and maybe just eth > 0), it gets misconfigured port - i have two 3c509 and only second one doesn't work - but when i force kernel to assign it 10baseT port, it of course works fine. I wanted to examine this bug more closely, but unfortunately i have too little time now. But anyway it looks there is bug in some region manipulation... -- Peter "Pasky" Baudis Whoever coded that patch should be taken out and shot, hung, drawn and quartered then forced to write COBOL for the rest of their natural life. -- Keith Owens <[EMAIL PROTECTED]> in linux-kernel My public PGP key is on: http://pasky.ji.cz/~pasky/pubkey.txt -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++:++ a--- C+++ UL$ P+ L+++ E--- W+ N !o K- w-- !O M- !V PS+ !PE Y+ PGP+>++ t+ 5 X(+) R++ tv- b+ DI(+) D+ G e-> h! r% y? --END GEEK CODE BLOCK-- - 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: (BUG) 3c509b and kernel 2.4.x
[1.] Upon boot, the 2.4.1 kernel misconfigures one of two 3c509b NICs installed in my computer as "BNC" rather than "10baseT". Boot messages for eth0 in kernel 2.2: eth0: 3c509 at 0x300 tag 1, 10baseT port, address 00 a0 24 e9 8d a1, IRQ 10. and in 2.4: eth0: 3c509 at 0x300, BNC port, address 00 a0 24 e9 8d a1, IRQ 10. i don't know why it says BNC port.. but it isn't right, it should be 10baseT I have three 3com cards( 1 3c590 Vortex, 1 3c900 Cyclone, 1 3c509B) which have no trouble with 2.2 kernels. But when I am trying to play with 2.4.0 kernel, the 3c509 just can not load. I'm getting exactly this problems too. If 3c509 is on eth1 (and maybe just eth 0), it gets misconfigured port - i have two 3c509 and only second one doesn't work - but when i force kernel to assign it 10baseT port, it of course works fine. I wanted to examine this bug more closely, but unfortunately i have too little time now. But anyway it looks there is bug in some region manipulation... -- Peter "Pasky" Baudis Whoever coded that patch should be taken out and shot, hung, drawn and quartered then forced to write COBOL for the rest of their natural life. -- Keith Owens [EMAIL PROTECTED] in linux-kernel My public PGP key is on: http://pasky.ji.cz/~pasky/pubkey.txt -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++:++ a--- C+++ UL$ P+ L+++ E--- W+ N !o K- w-- !O M- !V PS+ !PE Y+ PGP+++ t+ 5 X(+) R++ tv- b+ DI(+) D+ G e- h! r% y? --END GEEK CODE BLOCK-- - 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: [OFFTOPIC] Re: make mrproper
> On Thu, Jan 25, 2001 at 09:00:26AM -0500, you [James Lewis Nance] claimed:
> >
> > ( mrproper == Mr. Proper )
> >
> > I saw a post from Linus once about this. It is Finnish for "Mr. Clean".
>
> Just to be sure: 'proper' does not mean anything in Finnish (nor Swedish
> for that matter AFAIK) it just the European(?) product name for 'Mr
> Clean'. Possibly it's from German ('proper' = 'clean').
In CZ, we have Mr. Proper too - it's same as Mr Clean, but 'proper' doesn't
mean anything in czech too. I think it's just an international name for
that tool, which is using everywhere.
I think we explained it totally cleanly (properly ;-) and we are going really
offtopic now ;-).
>
>
> -- v --
>
> [EMAIL PROTECTED]
--
Peter "Pasky" Baudis
Whoever coded that patch should be taken out and shot, hung, drawn and
quartered then forced to write COBOL for the rest of their natural
life.
-- Keith Owens <[EMAIL PROTECTED]> in linux-kernel
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++:++ a--- C+++ UL$ P+ L+++ E--- W+ N !o K- w-- !O M-
!V PS+ !PE Y+ PGP+>++ t+ 5 X(+) R++ tv- b+ DI(+) D+ G e-> h! r% y?
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: [OFFTOPIC] Re: make mrproper
On Thu, Jan 25, 2001 at 09:00:26AM -0500, you [James Lewis Nance] claimed:
( mrproper == Mr. Proper )
I saw a post from Linus once about this. It is Finnish for "Mr. Clean".
Just to be sure: 'proper' does not mean anything in Finnish (nor Swedish
for that matter AFAIK) it just the European(?) product name for 'Mr
Clean'. Possibly it's from German ('proper' = 'clean').
In CZ, we have Mr. Proper too - it's same as Mr Clean, but 'proper' doesn't
mean anything in czech too. I think it's just an international name for
that tool, which is using everywhere.
I think we explained it totally cleanly (properly ;-) and we are going really
offtopic now ;-).
-- v --
[EMAIL PROTECTED]
--
Peter "Pasky" Baudis
Whoever coded that patch should be taken out and shot, hung, drawn and
quartered then forced to write COBOL for the rest of their natural
life.
-- Keith Owens [EMAIL PROTECTED] in linux-kernel
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s++:++ a--- C+++ UL$ P+ L+++ E--- W+ N !o K- w-- !O M-
!V PS+ !PE Y+ PGP+++ t+ 5 X(+) R++ tv- b+ DI(+) D+ G e- h! r% y?
--END GEEK CODE BLOCK--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
