Re: My Itchlist
Hi, On Fri, 5 Aug 2005, Linus Torvalds wrote: > On Fri, 5 Aug 2005, Junio C Hamano wrote: > > > > - Teach fetch-pack reference renaming. > > Well, the fetch side at least needs it less. > > Right now the renaming means that you can only really fetch _one_ head at > a time, but that's at least a fairly common and important case, and you > can do the rest from there. > > And doing only one means that git-fetch-pack can just return the result > SHA1 of the head it was asked to fetch. In fact, even that could just be > extended to returning multiple heads: just return each SHA1 in order. No > "renaming" necessary, since it's then up to the user what to do with the > results. I think that we need a method to do a push in reverse: If a central repository has several branches, I might want to pull just those branches where the local head is a strict parent of the remote side, and get complains for the others. And maybe reference naming comes as a freebie with that. Ciao, Dscho - 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] Fix ref_newer() in send-pack.
When more than two references need to be checked with
ref_newer() function, the second and later calls did not work
correctly. This was because the later calls found commits
retained by the "struct object" layer that still had smudges
made by earlier calls.
Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---
send-pack.c | 27 ++-
1 files changed, 22 insertions(+), 5 deletions(-)
51b0fca012310910783de76f2eacfd10b0f2f9fc
diff --git a/send-pack.c b/send-pack.c
--- a/send-pack.c
+++ b/send-pack.c
@@ -105,12 +105,23 @@ static int pack_objects(int fd, struct r
return 0;
}
+static void unmark_and_free(struct commit_list *list, unsigned int mark)
+{
+ while (list) {
+ struct commit_list *temp = list;
+ temp->item->object.flags &= ~mark;
+ list = temp->next;
+ free(temp);
+ }
+}
+
static int ref_newer(const unsigned char *new_sha1,
const unsigned char *old_sha1)
{
struct object *o;
struct commit *old, *new;
- struct commit_list *list;
+ struct commit_list *list, *used;
+ int found = 0;
/* Both new and old must be commit-ish and new is descendant of
* old. Otherwise we require --force.
@@ -127,14 +138,20 @@ static int ref_newer(const unsigned char
if (parse_commit(new) < 0)
return 0;
- list = NULL;
+
+ used = list = NULL;
commit_list_insert(new, &list);
while (list) {
new = pop_most_recent_commit(&list, 1);
- if (new == old)
- return 1;
+ commit_list_insert(new, &used);
+ if (new == old) {
+ found = 1;
+ break;
+ }
}
- return 0;
+ unmark_and_free(list, 1);
+ unmark_and_free(used, 1);
+ return found;
}
static struct ref *local_refs, **local_tail;
-
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] Making CFLAGS compilant with GNU Coding Standards
Hello!
Quoting GNU Coding Standards ("info standards"):
"If there are C compiler options that _must_ be used for proper
compilation of certain files, do not include them in `CFLAGS'. Users
expect to be able to specify `CFLAGS' freely themselves."
This patch renames COPTS to CFLAGS, because it's COPTS that was user
overridable. Also, -Wall is moved there because it's optional. What
was CFLAGS is now ALL_CFLAGS, which users should not override.
Defines are added to DEFINES. Since ALL_CFLAGS is recursively expanded,
it uses the final value of DEFINES.
Implicit rules are made explicit since the implicit rules use CFLAGS
rather than ALL_CFLAGS. I believe that serious projects should not rely
on implicit rules anyway. Percent rules are used because they are used
already and because they don't need the .SUFFIXES target.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -34,8 +34,8 @@
GIT_VERSION=0.99.3
-COPTS?=-g -O2
-CFLAGS+=$(COPTS) -Wall $(DEFINES)
+CFLAGS ?= -g -O2 -Wall
+ALL_CFLAGS = $(CFLAGS) $(DEFINES)
prefix=$(HOME)
bindir=$(prefix)/bin
@@ -125,7 +125,7 @@ ifndef NO_OPENSSL
LIB_OBJS += epoch.o
OPENSSL_LIBSSL=-lssl
else
- CFLAGS += '-DNO_OPENSSL'
+ DEFINES += '-DNO_OPENSSL'
MOZILLA_SHA1=1
OPENSSL_LIBSSL=
endif
@@ -146,8 +146,8 @@ endif
endif
endif
-CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
-CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT="$(etcgitdir)/templates"'
+DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)'
+DEFINES += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT="$(etcgitdir)/templates"'
@@ -156,9 +156,15 @@ CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRO
all: $(PROG)
+%.o: %.c
+ $(CC) -c $(ALL_CFLAGS) $<
+
+%.o: %.S
+ $(CC) -c $(ALL_CFLAGS) $<
+
.PRECIOUS: %.o
git-%: %.o $(LIB_FILE)
- $(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
+ $(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
git-http-pull: pull.o
git-local-pull: pull.o
@@ -185,13 +191,13 @@ test: all
$(MAKE) -C t/ all
test-date: test-date.c date.o
- $(CC) $(CFLAGS) -o $@ test-date.c date.o
+ $(CC) $(ALL_CFLAGS) -o $@ test-date.c date.o
test-delta: test-delta.c diff-delta.o patch-delta.o
- $(CC) $(CFLAGS) -o $@ $^
+ $(CC) $(ALL_CFLAGS) -o $@ $^
check:
- for i in *.c; do sparse $(CFLAGS) $(SPARSE_FLAGS) $$i; done
+ for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
--
Regards,
Pavel Roskin
-
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: gitk "hyperlinks" (was Re: Display of merges in gitk)
On Fri, Aug 05, 2005 at 07:37:41AM -0700, Linus Torvalds wrote: > > [ Also Kay Sievers, because the clickability thing sounds like a > potentially good thing for webgit too.. ] ... > For 2.6.13 we've been reverting some stuff lately, to make sure we get a > stable release. That's fine, and when I revert something I try to mention > the commit ID of the thing I revert in the message. Apparently others do > too, as indicated by a patch I just got from Petr Vandovec. So we've got > for example: > > Undo: d8c4b4195c7d664baf296818bf756775149232d3 > > Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> ... > and when I use gitk, it would be just too damn cool for words if I could > easily follow the SHA1's mentioned in the commit message. ... Damn cool? No problem. :) http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=403fe5ae57c831968c3dbbaba291ae825a1c5aaa Kay - 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: My Itchlist
On Fri, 5 Aug 2005, Junio C Hamano wrote: > > - Teach fetch-pack reference renaming. Well, the fetch side at least needs it less. Right now the renaming means that you can only really fetch _one_ head at a time, but that's at least a fairly common and important case, and you can do the rest from there. And doing only one means that git-fetch-pack can just return the result SHA1 of the head it was asked to fetch. In fact, even that could just be extended to returning multiple heads: just return each SHA1 in order. No "renaming" necessary, since it's then up to the user what to do with the results. In fact, many users don't even want to write the result to a ref _at_all_: they just use the raw name - no refs - to merge. So arguably it is _wrong_ to make git-fetch-pack write refs, because that just leads to the problem with temporary refs etc. "Local variables are good". > These are not 1.0 showstopper items but what I personally would > love to see. > > - teach mailsplit/mailinfo basic MIME (attachments and quoted-printable) > > Some people send patches in MIME quoted-printable. I could > drop them on the floor and ask the sender to resend, but I've > been being a nice guy, which currently involves manual > intervention. This really is a nasty problem. People add their own commentary etc, and the fact is, the maintainer _needs_ to edit it. Otherwise you'll have people saying "Hi there, I really like this thing, but I have this problem which this patch fixes" etc, which is all very nice, but dammit, that's simply not changelog material. Also, I definitely myself end up editing patches occasionally: fixing things up. Again, this is simply a major pain if the patch comes in as an attachment. So there are tons of reasons to just try to teach people that attachments are painful. Much better to teach people not to use them than having people use them and the tools "working" with them. > - teach git-apply "reverse" and possibly "fuzz". > > I think this might help Porcelain; currently they have to > interpret git extended diff headers themselves. Reverse would definitely be useful. "fuzz" is really pretty dangerous. I think that once a a patch doesn't apply, you really want to have helper tools like a graphical "wiggle" etc, and that really means that it's not "git-apply", it's something totally different. And quite frankly, if you have a tool that can handle unified diffs already, then extending it for the git rename stuff should be pretty easy. It's not like we haven't wanted renaming patches for at least a _decade_ already, it's just that nobody ever did them. So I'm hoping that git can act as a impetus for people to just finally have a standard way of saying "rename". EVERYBODY wants it. Anybody who ever sees a rename as a patch will always go "damn, it would be nice to have renames". And dammit, we have them, so let's try to push out the concept. And if that means that we should use rename patches and let non-git users have some pain until they say "ok, ok, it's a good idea, I'll do it. Uncle, uncle!", then maybe the world will be a better place. It's not like they can't see how git-apply does it already ;) 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
My Itchlist
Here is a short list of itches I would like to get scratched before 1.0. I may be forgetting something big, though, so if your favorite feature request is not included in the list please speak up. - Teach send-pack to use get_sha1() on the source side. In addition to a pattern that matches one reference on the source side, we should be able to use anything get_sha1() can grok. Hopefully I'll be looking into this over the weekend. - Teach fetch-pack reference renaming. On the push side, send-pack now knows updating arbitrary remote references from local references. We need something similar for fetching. I personally do not feel we need it for cloning but my cursory reading of clone-pack indicates the command is meant to work reasonably even in an already populated repository. If somebody have a good use case for it and a clean patch, I may be tempted to accept it. - Glossary documentation Johannes Schindelin is working on. I think coming up with the concensus of terms would come fairly quickly on the list. Updating docs to match the concensus may take some time. Help is greatly appreciated. - Makefile variables updates from Pasky. While I do not have objections to rename dest to DESTDIR and such Pasky proposes, I want to have a matching change to RPM and deb generation. I can speak basic debian/rules, but I am reluctant to touch RPM side of the things. Whether we do the dest/DESTDIR rename or not, we need to tweak binary packaging anyway, or stop installing the default templates. I can be talked into either way. My tentative plan is for 0.99.4 to finish send-pack, 0.99.5 to enhance fetch-pack, 0.99.6 to finish the first pass for the documentation updates and stabilizing the binary packaging. These are not 1.0 showstopper items but what I personally would love to see. - teach mailsplit/mailinfo basic MIME (attachments and quoted-printable) Some people send patches in MIME quoted-printable. I could drop them on the floor and ask the sender to resend, but I've been being a nice guy, which currently involves manual intervention. - teach git-apply "reverse" and possibly "fuzz". I think this might help Porcelain; currently they have to interpret git extended diff headers themselves. - commit template filler discussed with Pasky some time ago. - "rev-list a...b" should mean "rev-list `merge-base a b`..b" - 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: Terminology
> So what's the converse of "fetch" (to rename git-ssh-push to)? > Maybe "ship"? The opposite of "fetch" is "throw" or "toss". (Just avoid tossing cookies or off.) - 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] Use $DESTDIR instead of $dest
Petr Baudis <[EMAIL PROTECTED]> writes: > $DESTDIR is more usual during the build than $dest and is what is usually > used in the makefiles, so let's use it too. While I do not have much preference either way, I do not want to make this kind of change without making corresponding changes to the spec.in and debian/rules file in the same commit, or another commit that immediately follow it. And I wanted to do a 0.99.4 tomorrow, so I hope you would not mind if I placed this on hold... - 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: Terminology
Hi, On Fri, 5 Aug 2005, [EMAIL PROTECTED] wrote: > On Fri, 5 Aug 2005, Linus Torvalds wrote: > > > On Fri, 5 Aug 2005, Johannes Schindelin wrote: > > > > > - The files under $GIT_DIR/refs record object names, and are > > > called "refs". What is under refs/heads/ are called "heads", > > > refs/tags/ "tags". Typically, they are either object names > > > of commit objects or tag objects that resolve to commit > > > objects, but a tag can point at any object. > > > > > > The tutorial never calls them "refs", but instead "references". > > > > It might be worth saying explicitly that a reference is nothing but the > > same thing as a "object name" aka "sha1". > > Well, it's an object name stored in a file. This adds a layer of > indirection and a meaningful name. Yes. > > So I'd vote for making the suggested definition official: "fetch" means > > fetching the data, and "pull" means "fetch + merge". > > So what's the converse of "fetch" (to rename git-ssh-push to)? > Maybe "ship"? I actually like "push". You know, not everybody agrees that "push" is the opposite of "pull"... Ciao, Dscho - 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: Terminology
Hi, wow! What a long mail! But I probably deserved it, quoting that lengthy mail from Junio... On Fri, 5 Aug 2005, Linus Torvalds wrote: > On Fri, 5 Aug 2005, Johannes Schindelin wrote: > > > > Tutorial says "cache" aka "index". Though technically, a cache > > is the index file _plus_ the related objects in the object database. > > git-update-cache.txt even makes the difference between the "index" > > and the "directory cache". > > I think we should globally rename it to "index". Totally agree. The index is a central concept. But let's keep in mind -- and make future Documentation/ readers do the same -- that the index, without the referenced objects in the objects database, is only a skeleton. > The "directory cache" and later "cache" naming came from when I started > doing the work - before git was even git at all, and had no backing store > what-so-ever, I started out writing "cache.h" and "read-cache.c", and it > was really first a trial at doing a totally SCM-neutral directory cache > front-end. > > You don't even see that in the git revision history, because that was > before git was self-hosting - the project was partly started to also work > as possibly just a fast front-end to something that wasn't as fast (ie > think something like a front-end to make "monotone" work better). > > So the "directory cache" and "cache" naming comes from that historical > background: it was really started as a front-end cache, and in fact the > ".git" directory was called ".dircache" initially. You can see some of > that in the very earliest git releases: by then I had already done the > backing store, and the thing was already called "git", but the "dircache" > naming still remains in places. > > For example, here's my "backup" target in the initial checkin: > > backup: clean > cd .. ; tar czvf dircache.tar.gz dir-cache > > which shows that not only did I call the resulting tar file "dircache", > the directory I was developing stuff in was called "dir-cache" as well ;) > > The index obviously ended up doing a lot more, and especially with the > different stages it became much more than just a directory cache thing: > it's integral to how git does the fast part of a merge. So we should call > it "index" and edit out the old "cache" and "director cache" naming > entirely. I quoted this entirely, for a good reason: Linus, one day you really should write a Wikibook about all the "small" projects you started. I still remember the words "I'm doing a (free) operating system (just a hobby, won't be big...". There's so much to be learnt about good engineering. And people do want to add there anecdotes to it. > > - the directory which corresponds to the top of the hierarchy > > described in the index file; I've seen words like "working > > tree", "working directory", "work tree" used. > > > > The tutorial initially says "working tree", but then "working > > directory". Usually, a directory does not include its > > subdirectories, though. git-apply-patch-script.txt, git-apply.txt, > > git-hash-object.txt, git-read-tree.txt > > use "work tree". git-checkout-cache.txt, git-commit-tree.txt, > > git-diff-cache.txt, git-ls-tree.txt, git-update-cache.txt contain > > "working directory". git-diff-files.txt talks about a "working tree". > > I think we should use "working tree" throughout, since "working directory" > is unix-speak for "pwd" and has a totally different meaning. I hoped so much. > > - An index file can be in "merged" or "unmerged" state. The > > former is when it does not have anything but stage 0 entries, > > the latter otherwise. > > I think the "unmerged" case should be mentioned in the "cache entry" > thing, since it's really a per-entry state, exactly like "dirty/clean". > > Then, explaining a "unmerged index" as being an index file with some > entries being unmerged makes more sense. > > As it is, the above "explains" an index file as being unmerged by talking > about "stage 0 entries", which in turn haven't been explained at all. That's right. We probably should copy a bit from git-read-tree.txt, or at least reference it in the glossary. > > - A "tree object" can be recorded as a part of a "commit > > object". The tree object is said to be "associated with" the > > commit object. > > > > In diffcore.txt, "changeset" is used in place of "commit". > > We really should use "commit" throughout. ex-BK users sometimes lip into > "changeset" (which in turn is probably because BK had these per-file > commits too - deltas), but there's no point in the distinction in git. A > commit is a commit. That is, if you don't do "git-update-cache " (which is not possible with some porcelains). Apart from that: I think that it is quite important to make the distinction between a "commit" and a "commit object". Newbies (in that case, people working with CVS are newbies to the concepts of git, too) tend understand better what yo
Re: Terminology
On Fri, 5 Aug 2005, Linus Torvalds wrote: > On Fri, 5 Aug 2005, Johannes Schindelin wrote: > > > - The files under $GIT_DIR/refs record object names, and are > > called "refs". What is under refs/heads/ are called "heads", > > refs/tags/ "tags". Typically, they are either object names > > of commit objects or tag objects that resolve to commit > > objects, but a tag can point at any object. > > > > The tutorial never calls them "refs", but instead "references". > > It might be worth saying explicitly that a reference is nothing but the > same thing as a "object name" aka "sha1". Well, it's an object name stored in a file. This adds a layer of indirection and a meaningful name. > So I'd vote for making the suggested definition official: "fetch" means > fetching the data, and "pull" means "fetch + merge". So what's the converse of "fetch" (to rename git-ssh-push to)? Maybe "ship"? -Daniel *This .sig left intentionally blank* - 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: gitk "hyperlinks" (was Re: Display of merges in gitk)
On Fri, Aug 05, 2005 at 07:37:41AM -0700, Linus Torvalds wrote:
> For 2.6.13 we've been reverting some stuff lately, to make sure we get a
> stable release. That's fine, and when I revert something I try to mention
> the commit ID of the thing I revert in the message. Apparently others do
> too, as indicated by a patch I just got from Petr Vandovec. So we've got
> for example:
[snipped]
The following code worked for me on a toy commit. I'm not sure the regular
expression in linkcommits is right if the SHA1 is followed by a colon or a
comma,
as I noticed it was in your examples. If it doesn, then removing the [[:<:]]
and [[:>:]] will probably fix it.
Things that look like SHA1s are highlighted even if they don't actually exist.
There is probably a "more right" place to do the '$ctext tag bind Commit'
commands
but I didn't find it right away.
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -1753,6 +1753,11 @@ proc selectline {l} {
$ctext conf -state disabled
set commentend [$ctext index "end - 1c"]
+linkcommits $ctext 0.0 $commentend
+$ctext tag configure Commit -underline yes -foreground blue
+$ctext tag bind Commit { %W configure -cursor hand2 }
+$ctext tag bind Commit { %W configure -cursor {} }
+$ctext tag bind Commit { linkclick %W %x %y }
$cflist delete 0 end
$cflist insert end "Comments"
if {$nparents($id) == 1} {
@@ -1762,6 +1767,30 @@ proc selectline {l} {
}
}
+proc linkclick {w x y} {
+set index [$w index @$x,$y]
+set tags [$w tag names $index]
+foreach c $tags {
+if {![string match {C_*} $c]} { continue; }
+global sha1string
+set sha1string [string range $c 2 end]
+gotocommit
+}
+}
+
+proc linkcommits {w start end} {
+while {1} {
+set pos [$w search -regexp {[[:<:]][0-9a-fA-F]{40}[[:>:]]} $start $end]
+if {$pos == {}} {break}
+
+set commit [$w get $pos "$pos+40c"]
+
+$w tag add Commit $pos "$pos+40c"
+$w tag add C_$commit $pos "$pos+40c"
+set start [$w index "$pos+40c"]
+}
+}
+
proc selnextline {dir} {
global selectedline
if {![info exists selectedline]} return
pgppDwXRz0T1l.pgp
Description: PGP signature
Re: [RFC] git homepage
On Friday 05 August 2005 04:27, Petr Baudis wrote: > etc. And if you don't author any porcelain, send me updates anyway. :-) > gitk is a simple GTK GUI for browsing history of GIT repositories easily. ^^^ - Martin - --- --- index.html 2005-08-05 21:38:20.605324272 +0300 +++ index.html.new 2005-08-05 21:38:44.804645416 +0300 @@ -148,7 +148,7 @@ gitk http://ozlabs.org/~paulus/gitk/";>gitk is a simple -GTK GUI for browsing history of GIT repositories easily. +TK GUI for browsing history of GIT repositories easily. qgit http://sourceforge.net/projects/qgit";>qgit is a QT - 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: Terminology
On Fri, 5 Aug 2005, Johannes Schindelin wrote: > > Tutorial says "cache" aka "index". Though technically, a cache > is the index file _plus_ the related objects in the object database. > git-update-cache.txt even makes the difference between the "index" > and the "directory cache". I think we should globally rename it to "index". The "directory cache" and later "cache" naming came from when I started doing the work - before git was even git at all, and had no backing store what-so-ever, I started out writing "cache.h" and "read-cache.c", and it was really first a trial at doing a totally SCM-neutral directory cache front-end. You don't even see that in the git revision history, because that was before git was self-hosting - the project was partly started to also work as possibly just a fast front-end to something that wasn't as fast (ie think something like a front-end to make "monotone" work better). So the "directory cache" and "cache" naming comes from that historical background: it was really started as a front-end cache, and in fact the ".git" directory was called ".dircache" initially. You can see some of that in the very earliest git releases: by then I had already done the backing store, and the thing was already called "git", but the "dircache" naming still remains in places. For example, here's my "backup" target in the initial checkin: backup: clean cd .. ; tar czvf dircache.tar.gz dir-cache which shows that not only did I call the resulting tar file "dircache", the directory I was developing stuff in was called "dir-cache" as well ;) The index obviously ended up doing a lot more, and especially with the different stages it became much more than just a directory cache thing: it's integral to how git does the fast part of a merge. So we should call it "index" and edit out the old "cache" and "director cache" naming entirely. > - the directory which corresponds to the top of the hierarchy > described in the index file; I've seen words like "working > tree", "working directory", "work tree" used. > > The tutorial initially says "working tree", but then "working > directory". Usually, a directory does not include its > subdirectories, though. git-apply-patch-script.txt, git-apply.txt, > git-hash-object.txt, git-read-tree.txt > use "work tree". git-checkout-cache.txt, git-commit-tree.txt, > git-diff-cache.txt, git-ls-tree.txt, git-update-cache.txt contain > "working directory". git-diff-files.txt talks about a "working tree". I think we should use "working tree" throughout, since "working directory" is unix-speak for "pwd" and has a totally different meaning. > - When the stat information a cache entry records matches what > is in the work tree, the entry is called "clean" or > "up-to-date". The opposite is "dirty" or "not up-to-date". > > - An index file can be in "merged" or "unmerged" state. The > former is when it does not have anything but stage 0 entries, > the latter otherwise. I think the "unmerged" case should be mentioned in the "cache entry" thing, since it's really a per-entry state, exactly like "dirty/clean". Then, explaining a "unmerged index" as being an index file with some entries being unmerged makes more sense. As it is, the above "explains" an index file as being unmerged by talking about "stage 0 entries", which in turn haven't been explained at all. > - A "tree object" can be recorded as a part of a "commit > object". The tree object is said to be "associated with" the > commit object. > > In diffcore.txt, "changeset" is used in place of "commit". We really should use "commit" throughout. ex-BK users sometimes lip into "changeset" (which in turn is probably because BK had these per-file commits too - deltas), but there's no point in the distinction in git. A commit is a commit. > - The following objects are collectively called "tree-ish": a > tree object, a commit object, a tag object that resolves to > either a commit or a tree object, and can be given to > commands that expect to work on a tree object. > > We could call this category an "ent". LOL. You are a total geek. > - The files under $GIT_DIR/refs record object names, and are > called "refs". What is under refs/heads/ are called "heads", > refs/tags/ "tags". Typically, they are either object names > of commit objects or tag objects that resolve to commit > objects, but a tag can point at any object. > > The tutorial never calls them "refs", but instead "references". It might be worth saying explicitly that a reference is nothing but the same thing as a "object name" aka "sha1". And make it very clear that it can point to any object type, although commits tend to be the most common thng you want to reference. That then leads naturally into a very specific _subcase_ of refs, namely a "head": > - A "head" is always an object name of a commit, and marks the > latest comm
Re: [ANNOUNCE] Cogito-0.13
* Jay Denebeim ([EMAIL PROTECTED]) wrote: > Um, guys... > > If you want to have a dependency on git-core >= 0.99.3 you need to > actually like, you know, put it on-line as well. Just did a yum update, > fails with: > > error: Failed dependencies: > git-core >= 0.99.3 is needed by cogito-0.13-1 > > But on the git repository the git-core == 0.99.1 > > might wanna fix that. (and man is google fast) I've uploaded the rpms yesterday, but they haven't been staged for mirroring yet. thanks, -chris - 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: Template files location
Junio C Hamano wrote: ... If the template files are to become something that always have to exist, /etc first and then falling back on /usr/share would make a lot of sense. But as Johannes Schindelin correctly argued against the "Use the template mechanism to set up refs/ hierarchy as well." patch [*2*], I think git-init-db should work when there is no template directory. In other words, its primary purpose is to help local project administrators ensure newly created repositories have hooks and probably info/exclude that they recommend to the project members. So templates are project specific. The reason to have a sample one shipped as part of the core package is just to help newbies --- they would get a boilerplate hooks/update that explains how they can set it up when they do git-init-db even when they do not have their own customized set of templates yet. For this kind of use, I do not think one default falling back to another is needed. Shipping samples with the plumbing makes sense, especially when the documentation in is insufficient. But installing the samples as part of the default install process seems less than desirable. Or, alternately, install the samples in with the documentation as (non-executable) examples. ... *1* This would probably break Linus, myself and others --- everybody has to say "make prefix=$HOME", so I do not think I am actually going to do it any time soon, if ever. Having prefix=/usr/local as default only helps people who are installing system-wide from the source, and nobody else. People who are writing spec.in and/or debian/rules need to override it to prefix=/usr anyway, and it forces people who are installing to their home to say prefix=$HOME/. I suspect it is an inertia from the good old days when nobody used binary distributions. Rather than changing the default install location in such a way as to make half the user unhappy, make everybody (un)happy by removing the default and forcing it to be specified when make is executed. - 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: Template files location
Petr Baudis <[EMAIL PROTECTED]> writes: > Any reason why that's not the default destination then? Inertia, installing things under $HOME, is why it is not the default. It may be that the project is mature enough that it is time to move away from default installation in HOME, IOW to change the Makefile to say prefix=/usr/local (or prefix=/usr) to match practices of other projects [*1*]. > Or you can try /etc/git-core/ and fall back to /usr/share/git-core :-) If the template files are to become something that always have to exist, /etc first and then falling back on /usr/share would make a lot of sense. But as Johannes Schindelin correctly argued against the "Use the template mechanism to set up refs/ hierarchy as well." patch [*2*], I think git-init-db should work when there is no template directory. In other words, its primary purpose is to help local project administrators ensure newly created repositories have hooks and probably info/exclude that they recommend to the project members. The reason to have a sample one shipped as part of the core package is just to help newbies --- they would get a boilerplate hooks/update that explains how they can set it up when they do git-init-db even when they do not have their own customized set of templates yet. For this kind of use, I do not think one default falling back to another is needed. Come to think of it, GIT_TEMPLATE_DIRECTORY environment variable does not make _ANY_ sense; I am an idiot. It is used only by git-init-db and the reason to have it is to override the default. It should become the command line parameter of it. I'll fix up this breakage soonish. [Footnote] *1* This would probably break Linus, myself and others --- everybody has to say "make prefix=$HOME", so I do not think I am actually going to do it any time soon, if ever. Having prefix=/usr/local as default only helps people who are installing system-wide from the source, and nobody else. People who are writing spec.in and/or debian/rules need to override it to prefix=/usr anyway, and it forces people who are installing to their home to say prefix=$HOME/. I suspect it is an inertia from the good old days when nobody used binary distributions. *2* And I am sure many others shared the same objection but did not even bother to say anything because what Johannes said made a lot of sense and what the patch did was obviously wrong. - 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: [ANNOUNCE] Cogito-0.13
Um, guys... If you want to have a dependency on git-core >= 0.99.3 you need to actually like, you know, put it on-line as well. Just did a yum update, fails with: error: Failed dependencies: git-core >= 0.99.3 is needed by cogito-0.13-1 But on the git repository the git-core == 0.99.1 might wanna fix that. (and man is google fast) Jay -- * Jay Denebeim Moderator rec.arts.sf.tv.babylon5.moderated * * newsgroup submission address: [EMAIL PROTECTED]* * moderator contact address:[EMAIL PROTECTED]* * personal contact address: [EMAIL PROTECTED] * - 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: bisect gives strange answer
> If you see any sort of evidence that this would hold true I really like > to know. I haven't found any evidence. When I rebuilt the kernels from scratch (exporting them into an empty directory using cg-export), I got reliable data and bisected down to a patch that probably was a problem. I will redo those tests but rebuilding in place after each bisection (with -f added to all the git checkout uses in git-bisect-script) and see whether I get the same results. If I don't, it could be due to git or git-bisect (but not so likely with the -f switch) or to the build system. Will keep you and Junio posted. -Sanjoy - 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] Assorted documentation patches
Hi, while sifting through the documentation to find different namings for the same concepts, I saw a few things here and there, which I fixed. Since the sifting was quite numbing, there might be some wrong "fixes". Sorry, patch is attached, because I still can't convince my pine (version 4.63) to send single space lines :-( Ciao, Dscho diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt --- a/Documentation/diff-format.txt +++ b/Documentation/diff-format.txt @@ -62,7 +62,7 @@ customization also applies to "git-diff- 1. When the environment variable 'GIT_EXTERNAL_DIFF' is not set, these commands internally invoke "diff" like this: - diff -L a/ -L a/ -pu + diff -L a/ -L b/ -pu + For added files, `/dev/null` is used for . For removed files, `/dev/null` is used for @@ -101,7 +101,7 @@ For a path that is unmerged, 'GIT_EXTERN parameter, . -Git specific extention to diff format +Git specific extension to diff format - What -p option produces is slightly different from the diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt --- a/Documentation/diff-options.txt +++ b/Documentation/diff-options.txt @@ -5,9 +5,9 @@ Synonym for "-p". -r:: - Look recursivelly in subdirectories; this flag does not + Look recursively in subdirectories; this flag does not mean anything to commands other than "git-diff-tree"; - other commands always looks at all the subdirectories. + other diff commands always look at all the subdirectories. -z:: \0 line termination on output diff --git a/Documentation/git-diff-cache.txt b/Documentation/git-diff-cache.txt --- a/Documentation/git-diff-cache.txt +++ b/Documentation/git-diff-cache.txt @@ -50,13 +50,13 @@ Cached Mode --- If '--cached' is specified, it allows you to ask: - show me the differences between HEAD and the current index + show me the differences between HEAD and the current cache contents (the ones I'd write with a "git-write-tree") -For example, let's say that you have worked on your index file, and are -ready to commit. You want to see eactly *what* you are going to commit is -without having to write a new tree object and compare it that way, and to -do that, you just do +For example, let's say that you have worked on your working directory, updated +some files in the cache and are ready to commit. You want to see eactly +*what* you are going to commit is without having to write a new tree +object and compare it that way, and to do that, you just do git-diff-cache --cached $(cat .git/HEAD) diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt --- a/Documentation/git-diff-tree.txt +++ b/Documentation/git-diff-tree.txt @@ -86,7 +86,7 @@ Or if you are searching for what changed and it will ignore all differences to other files. The pattern is always the prefix, and is matched exactly. There are no -wildcards. Even stricter, it has to match complete path comonent. +wildcards. Even stricter, it has to match a complete path component. I.e. "foo" does not pick up `foobar.h`. "foo" does match `foo/bar.h` so it can be used to name subdirectories. diff --git a/Documentation/git-fsck-cache.txt b/Documentation/git-fsck-cache.txt --- a/Documentation/git-fsck-cache.txt +++ b/Documentation/git-fsck-cache.txt @@ -39,17 +39,17 @@ OPTIONS --standalone:: Limit checks to the contents of GIT_OBJECT_DIRECTORY - (.git/objects), making sure that it is consistent and + ($GIT_DIR/objects), making sure that it is consistent and complete without referring to objects found in alternate object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES, - nor packed GIT archives found in .git/objects/pack; + nor packed GIT archives found in $GIT_DIR/objects/pack; cannot be used with --full. --full:: Check not just objects in GIT_OBJECT_DIRECTORY - (.git/objects), but also the ones found in alternate + ($GIT_DIR/objects), but also the ones found in alternate object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES, - and in packed GIT archives found in .git/objects/pack + and in packed GIT archives found in $GIT_DIR/objects/pack and corresponding pack subdirectories in alternate object pools; cannot be used with --standalone. @@ -69,11 +69,7 @@ that aren't readable from any of the spe So for example - git-fsck-cache --unreachable $(cat .git/HEAD) - -or, for Cogito users: - - git-fsck-cache --unreachable $(cat .git/refs/heads/*) + git-fsck-cache --unreachable $(cat .git/HEAD .git/refs/heads/*) will do quite a _lot_ of verification on the tree. There are a few extra validity tests to be added (make sure that tree objects are @@ -122,18 +118,18 @@ sha1 mismatch :: The database has an object who's sha1 doesn't match
Re: git-cvs-import-script problems
David Kågedal <[EMAIL PROTECTED]> writes: > I just tried importing a large CVS repository to git, using "git > cvsimport". It managed to import a lot of files and revisions, but > half-way through, it stopped with this message: > > Unknown: F > > As far as I can till, this "F" probably came from the CVS server > process. Could it be that my CVS is too new or too old? Upgrading to CVS 1.12.1 seems to have helped. -- David Kågedal - 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: Terminology
Hi, I am finally finished with my preliminary survey: I took what you sent as a strawman, and inserted what I found (I tried to say only something about ambiguous naming): - The unit of storage in GIT is called "object"; no other word is used and the word "object" is used only for this purpose so this one is OK. - A 20-byte SHA1 to uniquely identify "objects"; README and early Linus messages call this "object name" so does tutorial. Many places say "object SHA1" or just "SHA1". "Object" is short for "immutable object". git-cat-file.txt says "repository object". - An "object database" stores a set of "objects", and an individial object can be retrieved by giving it its object name. Tutorial calls it an "object store". git-fsck-cache.txt names it "database" at first, but then also uses "object pool". - Storing a regular file or a symlink in the object database results in a "blob object" created. You cannot directly store filesystem directory, but a collection of blob objects and other tree objects can be recorded as a "tree object" which corresponds to this notion. - $GIT_INDEX_FILE is "index file", which is a collection of "cache entries". The former is sometimes called "cache file", the latter just "cache". Tutorial says "cache" aka "index". Though technically, a cache is the index file _plus_ the related objects in the object database. git-update-cache.txt even makes the difference between the "index" and the "directory cache". - the directory which corresponds to the top of the hierarchy described in the index file; I've seen words like "working tree", "working directory", "work tree" used. The tutorial initially says "working tree", but then "working directory". Usually, a directory does not include its subdirectories, though. git-apply-patch-script.txt, git-apply.txt, git-hash-object.txt, git-read-tree.txt use "work tree". git-checkout-cache.txt, git-commit-tree.txt, git-diff-cache.txt, git-ls-tree.txt, git-update-cache.txt contain "working directory". git-diff-files.txt talks about a "working tree". - When the stat information a cache entry records matches what is in the work tree, the entry is called "clean" or "up-to-date". The opposite is "dirty" or "not up-to-date". - An index file can be in "merged" or "unmerged" state. The former is when it does not have anything but stage 0 entries, the latter otherwise. That seems to be unambiguous (sometimes it's called "index", sometimes "index file"; I don't think that matters). - An merged index file can be written as a "tree object", which is technically a set of interconnected tree objects but we equate it with the toplevel tree object with this set. - A "tree object" can be recorded as a part of a "commit object". The tree object is said to be "associated with" the commit object. In diffcore.txt, "changeset" is used in place of "commit". - A "tag object" can be recorded as a pointer to another object of any type. The act of following the pointer a tag object holds (this can go recursively) until we get to a non-tag object is sometimes called "resolving the tag". - The following objects are collectively called "tree-ish": a tree object, a commit object, a tag object that resolves to either a commit or a tree object, and can be given to commands that expect to work on a tree object. We could call this category an "ent". - The files under $GIT_DIR/refs record object names, and are called "refs". What is under refs/heads/ are called "heads", refs/tags/ "tags". Typically, they are either object names of commit objects or tag objects that resolve to commit objects, but a tag can point at any object. The tutorial never calls them "refs", but instead "references". - A "head" is always an object name of a commit, and marks the latest commit in one line of development. A line of development is often called a "branch". We sometimes use the word "branch head" to stress the fact that we are talking about a single commit that is the latest one in a "branch". In the tutorial, the latter is used in reverse: it talks about a "HEAD development branch" and a "HEAD branch". I find it a little bit troublesome that $GIT_DIR/branches does not really refer to a branch, but rather to a (possibly remote) repository. - Combining the states from more than one lines of developments is called "merging" and typically done between two branch heads. This is called "resolving" in the tutorial and there is git-resolve-script command for it. - A set of "refs" with the set of objects reachable from them constitute a "repository". Although currently there is no provision for a repository to say that its objects are stored in this and that object database, multiple repositories can share the same object database, and there is not a conceptual limit that a repository must retrive its objects from a sin
gitk "hyperlinks" (was Re: Display of merges in gitk)
[ Also Kay Sievers, because the clickability thing sounds like a potentially good thing for webgit too.. ] For 2.6.13 we've been reverting some stuff lately, to make sure we get a stable release. That's fine, and when I revert something I try to mention the commit ID of the thing I revert in the message. Apparently others do too, as indicated by a patch I just got from Petr Vandovec. So we've got for example: 889371f61fd5bb914d0331268f12432590cf7e85: Author: Linus Torvalds <[EMAIL PROTECTED]> 2005-07-30 13:41:56 Committer: Linus Torvalds <[EMAIL PROTECTED]> 2005-07-30 13:41:56 Revert "yenta free_irq on suspend" ACPI is wrong. Devices should not release their IRQ's on suspend and re-aquire them on resume. ACPI should just re-init the IRQ controller instead of breaking most drivers very subtly. Breakage reported by Hugh Dickins <[EMAIL PROTECTED]> Undo: d8c4b4195c7d664baf296818bf756775149232d3 Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> and 403fe5ae57c831968c3dbbaba291ae825a1c5aaa: Author: Petr Vandrovec <[EMAIL PROTECTED]> 2005-08-05 06:50:07 Committer: Linus Torvalds <[EMAIL PROTECTED]> 2005-08-05 06:57:44 [PATCH] rtc: msleep() cannot be used from interrupt Since the beginning of July my Opteron box was randomly crashing and being rebooted by hardware watchdog. Today it finally did it in front of me, and this patch will hopefully fix it. The problem is that at the end of June (the 28th, to be exact: commit 47f176fdaf8924bc83fddcf9658f2fd3ef60d573, "[PATCH] Using msleep() instead of HZ") rtc_get_rtc_time ... and when I use gitk, it would be just too damn cool for words if I could easily follow the SHA1's mentioned in the commit message. I can just cut-and-paste the SHA1, and I've verified that it works fine. However, as you'v enoticed, I'm of the whiny kind, and I thought it could be easier. So I'm whining again. Mommy, mommy, can you make my life easier So I noticed that I really would like two things: - "clickable" SHA1's in commit messages would be really really cool if something like that is even possible with tcl/tk. Now, if you can highlight them when showing the message, that would be extra cool, but even without any highlighing, the thing actually _almost_ works fine already: you can double-click the SHA1, and it will select it. You then have to move the mouse to the "goto" window, and paste in the SHA1 there. And this is where it would be good if this sequence could be simplified a bit. Even if it's something as simple as accepting the SHA1 paste into the same window (not having to go to the "goto" window: just double-click on the SHA1, and then right-click to "paste it back"). - I'd like to have a "back button". Not just for the above kind of thing, but in general too: when searching for something, it would just be very nice if gitk just kept a list of the last commits that have been selected, and there was a web-browser-like button that went back/forward in history. But especially when looking at a revert, I just want to first go to the thing we revert, see what's going on there (get the "historical perspective" - commit log for why the original was done etc), and then I'd want to go back (and possibly forth and back again ;). And while the revert mentioned the thing it reverted (so I could cut-and-paste), the thing it reverted obviously does _not_ mention the thing that reverted it, so now I have to manually just scroll back. This same thing happens for a failed search (I search for xyz, and it actually finds it, and I realize that that was the wrong search, but now I'm two months back..) Mommy, mommy, plase 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: Display of merges in gitk
On Fri, 29 Jul 2005, Paul Mackerras wrote: > > I have reworked the way gitk displays merges. Ok, goodie. It works fine in my environment, with most merges showing up as not interesting. But a merge like 3e0777b8fa96f7073ed5d13d3bc1d573b766bef9 shows an example of where there was actually both real content merges, and some real clashes. However, most of the content merges were trivial, and they often hide the real clashes. For example, if you click on that merge, a _lot_ of it looks like it might be clashes, even though most of it was auto-merged. This is not really a problem, but I get the feeling that it could be improved somehow - maybe a button that hides the parts that don't have clashes? > In the usual case of two parents, lines from the first parent are in red > and lines from the second parent are in blue. Lines in the result that > don't correspond to either parent are in bold black. To get the alternate output, maybe something like: - run "merge" on the original/parent1/parent2 (the same way the git-merge-one-file-script does) - anything that merged fine is in black (regardless of which parent it came from), and then mark the merge rejects are in red/blue depending on parent? I don't know how doable that would be. 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
git-cvs-import-script problems
I just tried importing a large CVS repository to git, using "git cvsimport". It managed to import a lot of files and revisions, but half-way through, it stopped with this message: Unknown: F As far as I can till, this "F" probably came from the CVS server process. Could it be that my CVS is too new or too old? I'm using git b03e2d2091153d239063cfc086a840d74a9eadde, cvs 1.11.20, cvsps 2.1, and the CVS repository is a local directory. Also, when the process stops, I have .git/HEAD pointing to refs/heads/master (which doesn't exist). I thought it would be pointing to refs/heads/origin. -- David Kågedal - 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
Template files location
Dear diary, on Fri, Aug 05, 2005 at 06:37:11AM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > We install files in $(HOME)/etc/git-core/templates/ directory. > > In the standard binary distribution scheme, it should probably > go to either /usr/share or /etc; the former if the distribution > prefers static boilerplate files in /usr/share, latter if we > consider them site-specific conffiles. I just discussed this > privately with a Debian person on the list today, and we are in > favor of installing it under /usr/share/git-core/templates, > because we do not expect the contents of the standard templates > directory will not be a per-site customization [*1*]. > > In any case, this means that the make drivers like spec.in and > debian/rules would need to override some make variables when > they invoke the main Makefile. Any reason why that's not the default destination then? Or you can try /etc/git-core/ and fall back to /usr/share/git-core :-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - 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: Tree tags again..
Sorry about the breakage. I pushed out a fix. Since you always give me hard time with this "tree-tag", I decided to trump it with an even weirder tag myself. We will see what else would break shortly ;-). - 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: [RFC] git homepage
On Fri, Aug 05, 2005 at 04:12:14AM +0200, Petr Baudis wrote: > Dear diary, on Fri, Aug 05, 2005 at 04:00:03AM CEST, I got a letter > where Junio C Hamano <[EMAIL PROTECTED]> told me that... > > Petr Baudis <[EMAIL PROTECTED]> writes: > > > > > http://git.or.cz/ > > > > Wonderful. > > > > Once the page contents stabilizes, it would be a good idea to > > get it added in the page top links of http://www.kernel.org/git > > page. Sorry, I do not know who is in charge of configuring the > > gitweb there. > > I tend to harass Kay Sievers, with measurable effects. :-) You are welcome to do so. :) > > BTW, it may be technically correct, but the combination of > > "rsync" and "www" on the 3rd line of http://www.kernel.org/git > > caught my attention there ;-). > > > > cg-clone rsync://www.kernel.org/pub/scm/ + project path > > Actually, HTTP should be working again now; but it's rather fresh yet so > we should keep it rsync anyway for a while yet for the users of older > GIT/Cogito versions. Changed both to rsync now. Let me know, when we want to switch to http again. Best, Kay - 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
