[PATCH] git-status-script was missed during the conversion from N -> A
git-status-script was missed during the conversion from "N" to "A" as
the new-file marker flag.
Signed-off-by: Ryan Anderson <[EMAIL PROTECTED]>
---
git-status-script |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
10d81954c415dc46287f9d135e2b94302d4d7e84
diff --git a/git-status-script b/git-status-script
--- a/git-status-script
+++ b/git-status-script
@@ -18,7 +18,7 @@ report () {
T ) echo "#typechange: $name";;
C*) echo "#copied: $name -> $newname";;
R*) echo "#renamed: $name -> $newname";;
-N*) echo "#new file: $name";;
+A*) echo "#new file: $name";;
U ) echo "#unmerged: $name";;
esac
done
--
Ryan Anderson
sometimes Pug Majere
-
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
[PATCH/RFC] "Recursive Make considered harmful"
Convert build process from recurse Make to a single Make The old Makefiles in Documentation/ and tools/ still exist until we feel confident that I didn't miss anything on this conversion. Most of this patch is fixing up the main Makefile to avoid overlapping target names. Signed-off-by: Ryan Anderson <[EMAIL PROTECTED]> --- Documentation/Makefile.inc | 50 Makefile | 24 ++--- tools/Makefile.inc | 12 +++ 3 files changed, 78 insertions(+), 8 deletions(-) create mode 100644 Documentation/Makefile.inc create mode 100644 tools/Makefile.inc 003afd3ed1f83b4533b628182fa16c9ab0dc0467 diff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc new file mode 100644 --- /dev/null +++ b/Documentation/Makefile.inc @@ -0,0 +1,50 @@ +MAN1_TXT=$(wildcard Documentation/git-*.txt) +MAN7_TXT=Documentation/git.txt + +DOC_HTML=$(patsubst %.txt,%.html,$(MAN1_TXT) $(MAN7_TXT)) + +DOC_MAN1=$(patsubst %.txt,%.1,$(MAN1_TXT)) +DOC_MAN7=$(patsubst %.txt,%.7,$(MAN7_TXT)) + +mandir=$(prefix)/man +man1=$(mandir)/man1 +man7=$(mandir)/man7 + +# +# Please note that there is a minor bug in asciidoc. +# The version after 6.0.3 _will_ include the patch found here: +# http://marc.theaimsgroup.com/?l=git&m=111558757202243&w=2 +# +# Until that version is released you may have to apply the patch +# yourself - yes, all 6 characters of it! +# + +all-doc: html man + +html: $(DOC_HTML) + + +man: man1 man7 +man1: $(DOC_MAN1) +man7: $(DOC_MAN7) + +install-doc: + $(INSTALL) -m755 -d $(dest)/$(man1) $(dest)/$(man7) + $(INSTALL) $(DOC_MAN1) $(dest)/$(man1) + $(INSTALL) $(DOC_MAN7) $(dest)/$(man7) + +# 'include' dependencies +Documentation/git-diff-%.txt: Documentation/diff-format.txt Documentation/diff-options.txt + touch $@ + +clean-doc: + rm -f Documentation/*.xml Documentation/*.html Documentation/*.1 Documentation/*.7 + +%.html : %.txt + asciidoc -b xhtml11 -d manpage $< + +%.1 %.7 : %.xml + xmlto -o Documentation/ man $< + +%.xml : %.txt + asciidoc -b docbook -d manpage $< diff --git a/Makefile b/Makefile --- a/Makefile +++ b/Makefile @@ -54,9 +54,17 @@ PROG= git-update-cache git-diff-files git-show-index git-daemon git-var git-peek-remote \ git-update-server-info git-show-rev-cache git-build-rev-cache -all: $(PROG) +include Documentation/Makefile.inc +include tools/Makefile.inc -install: $(PROG) $(SCRIPTS) +all: all-bin all-doc +all-bin: $(PROG) +#all-tools + +install: install-bin install-doc +#install-tools + +install-bin: $(PROG) $(SCRIPTS) $(INSTALL) -m755 -d $(dest)$(bin) $(INSTALL) $(PROG) $(SCRIPTS) $(dest)$(bin) @@ -204,20 +212,20 @@ rpm: dist test: all $(MAKE) -C t/ all -doc: - $(MAKE) -C Documentation all +doc: all-doc +# $(MAKE) -C Documentation all -install-tools: +install-toolsxx: $(MAKE) -C tools install -install-doc: +install-docxx: $(MAKE) -C Documentation install -clean: +clean: clean-doc clean-tools rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE) rm -f git-core-*.tar.gz git-core.spec $(MAKE) -C tools/ clean - $(MAKE) -C Documentation/ clean backup: clean cd .. ; tar czvf dircache.tar.gz dir-cache + diff --git a/tools/Makefile.inc b/tools/Makefile.inc new file mode 100644 --- /dev/null +++ b/tools/Makefile.inc @@ -0,0 +1,12 @@ +# +# Make Linus git-tools +# + +PROG += $(addprefix tools/,git-mailsplit git-mailinfo) +SCRIPTS += $(addprefix tools/,git-applymbox git-applypatch) + +tools/git-%: tools/%.c + $(CC) $(CFLAGS) -o $@ $(filter %.c,$^) + +clean-tools: + rm -f tools/*.o -- Ryan Anderson sometimes Pug Majere - 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
Git 1.0 Synopis (Draft v2)
[This is still a draft, but I think I incorporated the suggestons from the last attempt.] Source Code Management with Git Git, sometimes called "global information tracker", is a "directory content manager". Git has been designed to handle absolutely massive projects with speed and efficiency, and the release of the 2.6.12 and (soon) the 2.6.13 version of the Linux kernel would indicate that it does this task well. Git falls into the category of distributed source code management tools, similar to Arch or Darcs (or, in the commercial world, BitKeeper). Every Git working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access to a central server. Git uses the SHA1 hash algorithm to provide a content-addressable pseudo filesystem, complete with its own version of fsck. o Speed of use, both for the project maintainer, and the end-users, is a key development principle. o The history is stored as a directed acyclic graph, making long-lived branches and repeated merging simple. o A collection of related projects are building on the core Git project, either to provide an easier to use interface on top (StGit, Cogito, qgit, gitk, gitweb), or to take some of the underlying concepts and reimplement them directly into another system (Arch 2.0, Darcs-git). o Two, interchangeable, on-disk formats are used: o An efficient, packed format that saves spaced and network bandwidth. o An unpacked format, optimized for fast writes and incremental work. To get a copy of Git: Daily snapshots are available at: http://www.codemonkey.org.uk/projects/git-snapshots/git/ (Thanks to Dave Jones) Source tarballs and RPMs at: http://www.kernel.org/pub/software/scm/git/ Deb packages at: Or via Git itself: git clone http://www.kernel.org/pub/scm/git/git.git/ git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ (rsync is generally faster for an initial pull) Git distributions contain a tutorial in the Documentation subdirectory. Additionally, the Kernel-Hacker's Git Tutorial at http://linux.yyz.us/git-howto.html may be useful. (Thanks to Jeff Garzik for that document) Git development takes place on the Git mailing list. To subscribe, send an email with just "subscribe git" in the body to [EMAIL PROTECTED] Mailing list archives are available at http://marc.theaimsgroup.com/?l=git Git results from the inspiration and frustration of Linus Torvalds, and the enthusiastic help of over 300 participants on the development mailing list.[1] It is maintained by Junio C Hamano <[EMAIL PROTECTED]>. 1 - Generated with the following, in a maildir folder: find . -type f | xargs grep -h "^From:" | perl -ne \ 'tr#A-Z#a-z#; m#<(.*)># && print $1,"\n";' | sort -u | wc -l (This summary written by Ryan Anderson <[EMAIL PROTECTED]>. Please bug him with any corrections or complaints.) -- Ryan Anderson sometimes Pug Majere - 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: Linux BKCVS kernel history git import..
On Tue, 2005-07-26 at 11:57 -0700, Linus Torvalds wrote: > If somebody adds some logic to "parse_commit()" to do the "fake parent" > thing, you can stitch the histories together and see the end result as one > big tree. Even without that, you can already do things like > > git diff v2.6.10..v2.6.12 That's a bit of a hack which really doesn't belong in the git tools. It's not particularly hard to reparent the tree for real -- I'd much rather see a tool added to git which can _actually_ change the 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 commit to have a parent of 0bcc493c633d78373d3fcf9efc29d6a710637519, and ripple the corresponding SHA1 changes up to the current HEAD. Note that the latter commit ID I gave there was actually the 2.6.12-rc2 commit in Thomas' history import, not your own. Thomas has done a lot of work on it, and it has the full names extracted from the shortlog script, full timestamps, branch/merge history and consistent character sets in the commit logs. I'd definitely suggest that you use that instead of the import from bkcvs. http://www.kernel.org/git/?p=linux/kernel/git/tglx/history.git;a=summary -- dwmw2 - 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
How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Hi, if I clone a remote head other than master via Cogito with cg-clone host:path#remoteHead, work on this branch, and try to push back my changes with cg-push, I get the error "pushing to a different head not supported yet". As far as I can see, there is no support in core GIT to make this ever work (at least with get-send-packs), as "git-send-pack" only updates a set of heads with the same name both locally and remote. I suppose the best would be to always keep the same head names in cloned repositories - it seems to be easier to handle for users. Perhaps the only exception would be "master", as one probably would like to pull masters of different remote repositories into a local one (without really working on them). Thus, what about the following: Each time a remote head other than master is cloned, a head with the same name is created locally which is an alias to the local master. This way, cg-push almost works out of the box. Following patch implements this behavior. Josef diff --git a/cg-clone b/cg-clone --- a/cg-clone +++ b/cg-clone @@ -69,5 +69,12 @@ cp $_git/refs/heads/origin $_git/refs/he git-read-tree HEAD git-checkout-cache -a git-update-cache --refresh echo "Cloned to $dir/ (origin $location available as branch \"origin\")" + +if echo "$location" | grep -q "#" ; then + rembranch=$(echo "$location" | sed -e "s/.*#//") + (cd $_git/refs/heads; ln -s master "$rembranch") + echo "Remote head \"$rbranch\" locally available as alias for \"master\"" +fi + diff --git a/cg-push b/cg-push --- a/cg-push +++ b/cg-push @@ -28,17 +28,18 @@ uri=$(cat "$_git/branches/$name" 2>/dev/ rembranch=master if echo "$uri" | grep -q '#'; then rembranch=$(echo $uri | cut -d '#' -f 2) uri=$(echo $uri | cut -d '#' -f 1) - die "pushing to a different head not supported yet" +[ -s $_git/refs/heads/$rembranch ] || (cd $_git/refs/heads;ln -s master $rembranch) +[ $(readlink $_git/refs/heads/$rembranch) = "master" ] || \ + die "can not push to remote head \"$rembranch\"" fi if echo "$uri" | grep -q "^http://";; then die "pushing over HTTP not supported yet" elif echo "$uri" | grep -q "^git+ssh://"; then git-send-pack "$(echo "$uri" | sed 's#^git+ssh://\([^/]*\)\(/.*\)$#\1:\2#')" $rembranch -elif echo "$uri" | grep -q ":"; then +elif echo "$uri" | grep -q "^rsync://"; then die "pushing over rsync not supported" else git-send-pack "$uri" $rembranch fi - 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: [PATCH/RFC] "Recursive Make considered harmful"
Ryan Anderson wrote: Convert build process from recurse Make to a single Make Please explain the rational for this. - 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: [PATCH/RFC] "Recursive Make considered harmful"
On Wed, Jul 27, 2005 at 10:25:10AM -0400, A Large Angry SCM wrote: > Ryan Anderson wrote: > >Convert build process from recurse Make to a single Make > > > > Please explain the rational for this. I'm new to the list, but given the subject, I'm fairly confident it's this. http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html I'm a convert. I converted a fairly large code base at work, and it was a huge boon for productivity. Build times dropped dramatically (from 40 seconds to 2-5 for a single file change). He used the exact wording just about everyone dones when referring to it conceptually. It's easy to google for support and rebuttal: http://www.google.com/search?hl=en&q=Recursive+Make+considered+harmful&btnG=Google+Search Thanks, Kirby - 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: [PATCH/RFC] "Recursive Make considered harmful"
Kirby C. Bohling wrote: On Wed, Jul 27, 2005 at 10:25:10AM -0400, A Large Angry SCM wrote: Ryan Anderson wrote: Convert build process from recurse Make to a single Make Please explain the rational for this. I'm new to the list, but given the subject, I'm fairly confident it's this. http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html ... He used the exact wording just about everyone dones when referring to it conceptually. It's easy to google for support and rebuttal: http://www.google.com/search?hl=en&q=Recursive+Make+considered+harmful&btnG=Google+Search Thanks for the references. A quick read of the paper and some of the rebuttals make me think that either way (recursive/non-recursive): * require about the same amount of makefile/dependency maintenance work from developers. * allow developers to be lazy in different ways with makefiles/dependencies. * achieves the same end. The non-recursive make method may have a small advantage for developers using Git for their SCM because the Git operations are also performed at the top level due to Git's design. - 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: Linux BKCVS kernel history git import..
On Wed, 27 Jul 2005, David Woodhouse wrote:
> On Tue, 2005-07-26 at 11:57 -0700, Linus Torvalds wrote:
> > If somebody adds some logic to "parse_commit()" to do the "fake parent"
> > thing, you can stitch the histories together and see the end result as one
> > big tree. Even without that, you can already do things like
> >
> > git diff v2.6.10..v2.6.12
>
> That's a bit of a hack which really doesn't belong in the git tools.
Actually, it's not a hack at all. It's very fundamentally how git works:
you give it two trees that it knows about, and it will show the
differences between them - regardless of whether they share any common
ancestry or not.
> It's not particularly hard to reparent the tree for real -- I'd much
> rather see a tool added to git which can _actually_ change the
> 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 commit to have a parent of
> 0bcc493c633d78373d3fcf9efc29d6a710637519, and ripple the corresponding
> SHA1 changes up to the current HEAD.
I used to think I wanted to, but these days I really don't. One of the
reasons is that I expect to try to pretty up the old bkcvs conversion some
time: use the name translation from the old "shortlog" scripts etc, and
see if I can do some other improvements on the conversion (I think I'll
remove the BK files - "ChangeSet" etc).
And it's really much easier and more general to have a "graft" facility.
It's something that git can do trivially (literally a hook in
"parse_commit" to add a special parent), and it's actually a generic
mechanism exactly for issues like this ("project had old history in some
other format").
Somebody already asked for having the import history for old historic
patches - which we _do_ actually have as patches, but which obviously
don't have any changelogs except for the version information. Most people
may not want that, but the thing is, with a "graft" facility, the people
who _do_ want that can easily see it all, and it is totally seamless.
So it's not even a one-time hack - it's a real feature that just in the
kernel would have several cases we'd be able to use it for, and the same
is likely true for almost any other project that wasn't started purely
from git..
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: Linux BKCVS kernel history git import..
On Wed, 27 Jul 2005, David Woodhouse wrote: > > Hm, OK. That works and can also be used for the "fake _absence_ of > parent" thing -- if I'm space-constrained and want only the history back > to some relatively recent point like 2.6.0, I can do that by turning the > 2.6.0 commit into an orphan instead of also using all the rest of the > history back to 2.4.0. Yes. The grafting really should work pretty well for various things like this, and at the same time I don't think it's ever going to be a huge problem: people may have a couple of graft-points (if you want to drop history, you may well have more than one point you need to "cauterize": you may not be able to just cut it off at 2.6.0, since there may be merges furhter back in history), but I don't think it's going to explode and become unwieldly. I just don't see people having more than a few trees that they might want to graft together, and while the "drop history" thing might cause more issues, even that is bounded by the amount of development parallellism, so while it probably causes more graft-points than the "join trees" usage, it should still be just a small handful of points. 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: Linux BKCVS kernel history git import..
On Wed, 2005-07-27 at 08:29 -0700, Linus Torvalds wrote:
> I used to think I wanted to, but these days I really don't. One of the
> reasons is that I expect to try to pretty up the old bkcvs conversion some
> time: use the name translation from the old "shortlog" scripts etc, and
> see if I can do some other improvements on the conversion (I think I'll
> remove the BK files - "ChangeSet" etc).
Thomas has done all that; it's on kernel.org already.
> And it's really much easier and more general to have a "graft" facility.
> It's something that git can do trivially (literally a hook in
> "parse_commit" to add a special parent), and it's actually a generic
> mechanism exactly for issues like this ("project had old history in some
> other format").
Hm, OK. That works and can also be used for the "fake _absence_ of
parent" thing -- if I'm space-constrained and want only the history back
to some relatively recent point like 2.6.0, I can do that by turning the
2.6.0 commit into an orphan instead of also using all the rest of the
history back to 2.4.0.
--
dwmw2
-
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: [PATCH/RFC] "Recursive Make considered harmful"
Ryan Anderson <[EMAIL PROTECTED]> writes: > 003afd3ed1f83b4533b628182fa16c9ab0dc0467 > diff --git a/Documentation/Makefile.inc b/Documentation/Makefile.inc > new file mode 100644 > --- /dev/null > +++ b/Documentation/Makefile.inc > @@ -0,0 +1,50 @@ > +MAN1_TXT=$(wildcard Documentation/git-*.txt) > +MAN7_TXT=Documentation/git.txt > + >... While I do not have strong objections to make the build process go faster, it is somewhat disturbing that the Makefile pieces maintained in subdirectories need to name things they touch using paths that include the subdirectory names. I do not have a better alternative to suggest, though... I'd keep it in the proposed updates branch for now and wait for a bit until discussions on the list die out. - 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: [PATCH] git-status-script was missed during the conversion from N -> A
Ryan Anderson <[EMAIL PROTECTED]> writes: > git-status-script was missed during the conversion from "N" to "A" as > the new-file marker flag. Thanks. Applied and pushed out. - 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: Stacked GIT 0.4
On Tue, 2005-07-12 at 07:05 -0400, Bryan Larsen wrote: > Here's my wishlist. Hopefully I'll be able to dig in and help out. > > import: the complement to export A first implementation of 'import' is available in the tonight's snapshot (and in the StGIT git repository mirror). > template files for the "series" output of export, to put it into a > format that "sendpatchset" understands. As you noticed, I implemented the 'mail' command. Once the current snapshot gets a bit more testing, I will release the 0.5 version. After that, I will focus more on a tutorial and the file compatibility with Cogito. -- Catalin - 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: [PATCH/RFC] "Recursive Make considered harmful"
Junio C Hamano wrote: While I do not have strong objections to make the build process go faster, it is somewhat disturbing that the Makefile pieces maintained in subdirectories need to name things they touch using paths that include the subdirectory names. I do not have a better alternative to suggest, though... For a project the size of Git, is there any real benefit to this change? Besides pathing issues, you also have to aware that all identifiers in the included makefile fragments will be global. I don't object to the change but I see it as trading one maintenance issue for another. - 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 1.0 Synopis (Draft v2)
Ryan Anderson <[EMAIL PROTECTED]> writes: > Source Code Management with Git Thanks for doing this. Generally looks excellent. > o Two, interchangeable, on-disk formats are used: > o An efficient, packed format that saves spaced and network > bandwidth. ??? "spaced" ??? > Or via Git itself: > git clone http://www.kernel.org/pub/scm/git/git.git/ > git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ > (rsync is generally faster for an initial pull) These need a target directory name to create, like this: git clone rsync://rsync.kernel.org/pub/scm/git/git.git/ $new_dir git clone http://www.kernel.org/pub/scm/git/git.git/ $new_dir > Git results from the inspiration and frustration of Linus Torvalds, and > the enthusiastic help of over 300 participants on the development > mailing list.[1] It is maintained by Junio C Hamano <[EMAIL PROTECTED]>. Please drop the e-mail address here; you mention nobody else's. Well, dropping "the current maintainer" information altogether might be even better; the above to a casual reader sounds like Linus was frustrated and I wrote it for him, which is definitely not what we would like to say. I suspect it still has more code by Linus than anybody else (I stopped counting some time ago). - 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
Handover, Make
First, congratulations Junio, on taking over this stuff, and all the best. Second, the killer argument, in the 'Recursive Make ... harmful' is the basic one that Recursive Makes breaks up the dependancy graph, and almost guarentees that it is wrong unless you do a lot of work to fix that artifact. Now git is small enough that make clean; make won't take too long but git is also a basis for other layers, so there is good reason to try to get it right. -- mit freundlichen Grüßen, Brian. - 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: How is working on arbitrary remote heads supposed to work in Cogito (+ PATCH)?
Josef Weidendorfer <[EMAIL PROTECTED]> writes: > As far as I can see, there is no support in core GIT to make this ever work > (at least with get-send-packs), as "git-send-pack" only updates a set of > heads with the same name both locally and remote. Yes, it is my understanding that "clone" means to literally clone, not "pull into an empty repository with renamed head names", to the core GIT. I do not speak for Pasky, but Cogito's "clone" seems to have a bit different semantics (which I suspect is more friendly to the users in many situations). Similarly, "push" to the core GIT (that is what git-send-pack is about) means performing a subset of "clone" in reverse. This is primarily to synchronise two repositories owned by a single person. - 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
