Re: Last mile to 1.0?
[EMAIL PROTECTED] writes: > I still have the patch to make git-http-pull download packs, and I > should be able to get it to read the objects/info/packs file without > too much trouble. Another thing that may help you gain more parallelism in the initial set of requests is the rev-cache file. You can find out the ancestry information upfront by reading it, without waiting for the commits you asked to arrive. - 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: Last mile to 1.0?
I've been missing for a couple of weeks due to my server dying and needing to be replaced; I think stuff is mostly back in order now. (But I'm not yet resubscribed, and I suspect only dumb mailers are currently willing to talk to my mail server, for some reason I don't yet understand; I'm sort of reading the archives, at least.) I still have the patch to make git-http-pull download packs, and I should be able to get it to read the objects/info/packs file without too much trouble. I was also in progress on a series to rearrange the code in pull.c such that it passes the objects it needs through a list such that it can request them in parallel. I'd gotten as far as making it blast out requests for objects over git-ssh-pull (and then break because it doesn't expect to be able to accidentally read part of the next object while reading the current object); it shouldn't be too hard to make the HTTP version use this to parallelize requests as well. I expect I'll get to work on this on Sunday, in any case. -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: Last mile to 1.0?
Petr Baudis <[EMAIL PROTECTED]> writes: > Note that I really _loved_ the Daniel's tools while they lasted. What I > loved most about them was that they really only pulled objects I needed > and not a single worthless one. Does the current HTTP transport share > this property? I am a big fan of Barkalow puller, too. It is conceptually simple, very easy to explain, and quite nicely done to be transport independent. Performance sucks, but that is not Dan's fault. If we are talking about a dumb HTTP server that has packed and then prune-packed its repository, "not a single worthless one" is asking for moon. If Jeff packed all his 50 branches into a single pack and prune packed his repository, the only thing a dumb server could do when you ask for one of his branches is to give you that statically prepared single pack which contains everything, because there would be nothing in .git/objects/??/. You need some CGI support that pulls only needed objects out of that pack and talks a moral equivalent of the upload-pack protocol for that. Barkalow puller is still useful when all the objects you still need to pull from the remote are unpacked on the remote end. That's how I resurrected "git clone" over http with packed dumb servers. For "clone" case, I just slurp all the available packs, and have Barkalow puller take over the rest. I have an early WIP for "git fetch", but I have backburnered it for quite some time. I'll push it in its current form into my proposed updates branch, so interested people can hack on it. > Note that I also want to setup a simple "proof-of-concept" GIT homepage > tomorrow. Well, write it, where it should be hosted can be worked out > later and I have places for it to reside at for now. (Suggestions for > final hosting welcome. In reality, how nice (and persistent) the URL > gets is probably the only thing that really matters. My attempt will > live at http://git.or.cz/.) I hope nobody starts another SCM project called CZ ;-). - 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: Last mile to 1.0?
Dear diary, on Sat, Jul 16, 2005 at 07:46:00PM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > I do not know what release plan Linus has in mind, and also > expect things to be quieter next week during OLS and kernel > summit, but I think we are getting really really close. > > Here are the things I think we would want to see before we hit > 1.0: > > - Remaining feature enhancements and fixes. > >- Anonymous pull from packed archives on remote sites via > non-rsync, non-ssh transport. Many people are behind > corporate firewalls that do not pass anything but outgoing > http(s) and some do not even pass outgoing ssh. The recent > addition of git-daemon by Linus would greatly alleviate the > situation, but we may also end up wanting something HTTP > reachable. I hope to get to it tomorrow but it now occurred to me that I don't know when do you actually want to release 1.0 and I think it's crucial for it to support some sensible HTTP transport - I saw some scripts going in etc, but what's its current state? Is it usable? Note that I really _loved_ the Daniel's tools while they lasted. What I loved most about them was that they really only pulled objects I needed and not a single worthless one. Does the current HTTP transport share this property? > - Publicity. I would be very happy to see somebody with good >writing and summarizing skills to prepare an article to be >published on LWN.NET to coincide with the 1.0 release. An >update to GIT traffic would also be nice. Note that I also want to setup a simple "proof-of-concept" GIT homepage tomorrow. Well, write it, where it should be hosted can be worked out later and I have places for it to reside at for now. (Suggestions for final hosting welcome. In reality, how nice (and persistent) the URL gets is probably the only thing that really matters. My attempt will live at http://git.or.cz/.) -- 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: Last mile to 1.0?
Satturday, 23 July 2005 21:09 Junio C Hamano wrote: > Instead, please add gitk and gitweb to the list. We should not > forget that these "mostly read-only" things are Porcelains. Then add qgit too to provide fair coverage. -- Respectfully Alexey Nezhdanov - 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: Last mile to 1.0?
Ryan Anderson <[EMAIL PROTECTED]> writes: > How is this for a start? A very good start indeed. Thanks. > Git falls into the category of distributed source code management tools, > similar to Arch or Darcs (or, in the commercial world, BitKeeper). This > means that every working directory is a full-fledged repository with > full revision tracking capabilities. I think Kevin's comment is valid and his description is reasonable. > o A collection of related projects are building on the core Git > project, either to provide an easier to use interface on top (Darcs, > Mercurial, StGit, Cogito), or to take some of the underlying concepts > and reimplement them directly into another system (Arch 2.0). I think you would want to drop Darcs and Mercurial from the "on top" list. If I understand correctly, Mercurial is independently written with its own on-disk formats [*1*]. It would be very unfair to put Darcs in "building on" category. They've been there for quite some time with their own repository format and the tools and interfaces are reasonably mature. Instead, please add gitk and gitweb to the list. We should not forget that these "mostly read-only" things are Porcelains. [Footnote] *1* It feels that actually it is done right. Its misfortune is that many core kernel people have already switched to git. - 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: Last mile to 1.0?
Ryan Anderson wrote: Git falls into the category of distributed source code management tools, similar to Arch or Darcs (or, in the commercial world, BitKeeper). This means that every working directory is a full-fledged repository with full revision tracking capabilities. That's not actually what "distributed" means. There are several distributed SCM tools[1] that store repo information outside the actual working directory. Perhaps that last sentence could be something like "This means that each developer has a local full-fledged repository with full revision tracking capabilities, not dependent on network access to a central server." I'm sure there are better wordings, but I hate to point out an problem without offering at least one possible improvement. Kevin [1] I believe that ArX, monotone, codeville, and svk all fall into this category. Possibly even Arch itself, although I haven't researched that. - 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: Last mile to 1.0?
Duplicate send, had typo in orif address line :( On Saturday 23 July 2005 04:50, Ryan Anderson wrote: >On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote: >> - Publicity. I would be very happy to see somebody with good >>writing and summarizing skills to prepare an article to be >>published on LWN.NET to coincide with the 1.0 release. An >>update to GIT traffic would also be nice. > >How is this for a start? > >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). This means that every working directory is a > full-fledged repository with full revision tracking capabilities. > >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 > (Darcs, Mercurial, StGit, Cogito), or to take some of the > underlying concepts and reimplement them directly into another > system (Arch 2.0). 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. > A very good start for the overview preamble. Do carry on. >Git results from the inspiration and frustration of Linus Torvalds, > and the enthusiastic help of over 300 participants on the > development mailing list.[1] > > >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 -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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: Last mile to 1.0?
On Saturday 23 July 2005 04:15, Ryan Anderson wrote: >On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote: >> I do not know what release plan Linus has in mind, and also >> expect things to be quieter next week during OLS and kernel >> summit, but I think we are getting really really close. > >Looking at the set of patches we just all dumped on Linus, I think > they pretty much show us that we don't have any major issues. > >As I see it, the status is currently like this: > >Revision control - Stable >Pulling locally or over rsync - Stable >Pushing over ssh - Stable > >Remote, anonymous pulls not using rsync - Beta >Usability features[1] - Beta > >Documentation - Alpha One old farts comment re the docs here folks. This will need to be improved considerably if you want all us lurking frogs to be able to use it without drowning this list with what really should be RTFMable questions. Specifically, we should be able to dl one package and install something that, by reading the manpages, can be made to work OOTB given an adequate network connection. My lurking & reading the mail here tends to give me the impression that while it can be made to work, there are yet rough edges for the new user. Potentially discouraging rough edges... >My feeling is that we're pretty well set to do a 1.0 release. > >1 - Usability features are all the things around git-apply, >git-format-patch, etc, that we're clearly working on to make life > more pleasant, but aren't really critical. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.35% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - 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: Last mile to 1.0?
On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote: > - Publicity. I would be very happy to see somebody with good >writing and summarizing skills to prepare an article to be >published on LWN.NET to coincide with the 1.0 release. An >update to GIT traffic would also be nice. How is this for a start? 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). This means that every working directory is a full-fledged repository with full revision tracking capabilities. 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 (Darcs, Mercurial, StGit, Cogito), or to take some of the underlying concepts and reimplement them directly into another system (Arch 2.0). 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. Git results from the inspiration and frustration of Linus Torvalds, and the enthusiastic help of over 300 participants on the development mailing list.[1] 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 -- 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: Last mile to 1.0?
On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote: > I do not know what release plan Linus has in mind, and also > expect things to be quieter next week during OLS and kernel > summit, but I think we are getting really really close. Looking at the set of patches we just all dumped on Linus, I think they pretty much show us that we don't have any major issues. As I see it, the status is currently like this: Revision control - Stable Pulling locally or over rsync - Stable Pushing over ssh - Stable Remote, anonymous pulls not using rsync - Beta Usability features[1] - Beta Documentation - Alpha My feeling is that we're pretty well set to do a 1.0 release. 1 - Usability features are all the things around git-apply, git-format-patch, etc, that we're clearly working on to make life more pleasant, but aren't really critical. -- 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: Last mile to 1.0?
Alexey Nezhdanov <[EMAIL PROTECTED]> writes:
> But this should not be user's problem - it's just the UI that doesn't
> understands when transcoding should be done.
I disagree.
Yes, while you _could_ do something like this to feed text in
local encoding to the VISUAL/EDITOR, and convert it back to
UTF-8:
--- a/git-commit-script
+++ b/git-commit-script
@@ -84,7 +84,7 @@
fi
if [ "$?" != "0" ]
then
- cat .editmsg
+ git-char-conv --utf8-to-user < .editmsg
rm .editmsg
exit 1
fi
@@ -93,7 +93,9 @@
${VISUAL:-${EDITOR:-vi}} .editmsg
;;
esac
-grep -v '^#' < .editmsg | git-stripspace > .cmitmsg
+grep -v '^#' < .editmsg |
+git-stripspace |
+git-char-conv --user-to-utf8 > .cmitmsg
[ -s .cmitmsg ] &&
tree=$(git-write-tree) &&
commit=$(cat .cmitmsg | git-commit-tree $tree $PARENTS) &&
I think it is a horrible way to do things.
I presume that your bringing up UTF-8 suggests that you believe
doing things in UTF-8 for interoperability's sake is the right
thing. If that is indeed the case, then tools other than GIT
and Cogito you would use would need to deal with this exact same
problem, that your VISUAL/EDITOR does not understand UTF-8.
How about writing a little wrapper, koi-vi, which would roughly
be:
#!/bin/sh
tcs -f utf -t koi8 "$1" >.tmp-koi
vi .tmp-koi
tcs -t utf -f koi8 .tmp-koi >"$1"
and point VISUAL/EDITOR environment variable at it? That way
your other tools would be able to let you keep using your
favorite editor, now utf8 enabled, and deal with UTF-8. None of
the scripts, including the script I quoted above, has to be
changed that way.
Having said that, I personally feel that the choice of the
character encoding of commit messages is per-project convention
issue and does not even warrant a per-project "configuration
file". As long as your developers all agree to use KOI, and you
are reasonably sure that you will not ever cross-merge with
another project that uses different encoding for commit
messages, I think it is perfectly fine to use KOI in your commit
messages. The core's job is only to ensure that we are 8-bit
clean and faithfully record whatever you throw at us.
-
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: Last mile to 1.0?
Monday, 18 July 2005 09:35 Junio C Hamano wrote: > Alexey Nezhdanov <[EMAIL PROTECTED]> writes: > > I'd add the UTF-8 native support. Currently neither commit nor gitk > > doesn't support that. Probably this should be done at as low as possible > > level. > > I do not understand your proposal. Care to clarify? You can > write your commit messages in UTF-8 today and "git-cat-file > commit $commit_ID", which is as low level as you can go, gives > you that commit message in UTF-8. Yes. But it have not integration with user environment. Personally I use koi8-r environment and doing "cg commit" (and probably "git commit" too) results in koi8-r text written as commit text. I remember that this issue were discussed on this list and all come to conclusion that utf-8 is the only sane encoding that can be used in this case. But this should not be user's problem - it's just the UI that doesn't understands when transcoding should be done. Similarly - when I start gitk then I see only weird symbols instead of commit text, not matter what encoding I use for commits - koi8-r or utf-8. BTW russian koi8-r encoded text _in_diff_contents_ show correctly. Wonder why... -- Respectfully Alexey Nezhdanov - 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: Last mile to 1.0?
David Lang <[EMAIL PROTECTED]> writes: > a very common one will be prople who want to setup a cron job to > update their local tree nightly, in this case having a pre-generated > pack file with each day's updates will save a significant amount of > processing power. > > would it make sense to have it do something along the lines of sending > the day;s pack file plus a small number of individual object (even if > the pack file will partially duplicate object the puller already has) I think that would be a reasonable thing to do. The server for anonymous puller, git-daemon, may need some extending. As people criticised, git-upload-pack/git-fetch-pack protocol being not easily extensible, we would end up doing another protocol, though, that's OK. Fortunately [*1*], git-daemon itself is written to be extensible if you are willing to introduce a totally new protocol driver, so if this on-demand pack generation turns out to be too much a resource hog, we have a reasonably easy way out. [Footnote] *1* We are fortunate but that is not by dumb luck. When he did daemon.c::execute(), Linus must have thought things through. - 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: Last mile to 1.0?
Alexey Nezhdanov <[EMAIL PROTECTED]> writes: > I'd add the UTF-8 native support. Currently neither commit nor gitk doesn't > support that. Probably this should be done at as low as possible level. I do not understand your proposal. Care to clarify? You can write your commit messages in UTF-8 today and "git-cat-file commit $commit_ID", which is as low level as you can go, gives you that commit message in UTF-8. - 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: Last mile to 1.0?
Satturday, 16 July 2005 21:46 Junio C Hamano wrote: > I do not know what release plan Linus has in mind, and also > expect things to be quieter next week during OLS and kernel > summit, but I think we are getting really really close. > > Here are the things I think we would want to see before we hit > 1.0: > > - Remaining feature enhancements and fixes. > >- Anonymous pull from packed archives on remote sites via > non-rsync, non-ssh transport. Many people are behind > corporate firewalls that do not pass anything but outgoing > http(s) and some do not even pass outgoing ssh. The recent > addition of git-daemon by Linus would greatly alleviate the > situation, but we may also end up wanting something HTTP > reachable. I'd add the UTF-8 native support. Currently neither commit nor gitk doesn't support that. Probably this should be done at as low as possible level. -- Respectfully Alexey Nezhdanov - 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: Last mile to 1.0?
On Sat, 16 Jul 2005, Junio C Hamano wrote: [EMAIL PROTECTED] (Eric W. Biederman) writes: Junio C Hamano <[EMAIL PROTECTED]> writes: - Anonymous pull from packed archives on remote sites via non-rsync, non-ssh transport. ... ... but we may also end up wanting something HTTP reachable. For this we need a cgi script that will generate an appropriate pack. I agree that nothing would beat a pack customized for each puller from the bandwidth point of view. I like the general idea of git-daemon Linus did and the cgi script you suggest, but I wonder what the CPU/disk load implications for the server. I think you need to nail down the various scenerios that people will be useing here. a very common one will be prople who want to setup a cron job to update their local tree nightly, in this case having a pre-generated pack file with each day's updates will save a significant amount of processing power. would it make sense to have it do something along the lines of sending the day;s pack file plus a small number of individual object (even if the pack file will partially duplicate object the puller already has) David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - 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: Last mile to 1.0?
[EMAIL PROTECTED] (Eric W. Biederman) writes: > Junio C Hamano <[EMAIL PROTECTED]> writes: >> >>- Anonymous pull from packed archives on remote sites via >> non-rsync, non-ssh transport. ... >> ... but we may also end up wanting something HTTP >> reachable. > > For this we need a cgi script that will generate an appropriate > pack. I agree that nothing would beat a pack customized for each puller from the bandwidth point of view. I like the general idea of git-daemon Linus did and the cgi script you suggest, but I wonder what the CPU/disk load implications for the server. - 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: Last mile to 1.0?
Junio C Hamano <[EMAIL PROTECTED]> writes: > I do not know what release plan Linus has in mind, and also > expect things to be quieter next week during OLS and kernel > summit, but I think we are getting really really close. > > Here are the things I think we would want to see before we hit > 1.0: > > - Remaining feature enhancements and fixes. > >- Anonymous pull from packed archives on remote sites via > non-rsync, non-ssh transport. Many people are behind > corporate firewalls that do not pass anything but outgoing > http(s) and some do not even pass outgoing ssh. The recent > addition of git-daemon by Linus would greatly alleviate the > situation, but we may also end up wanting something HTTP > reachable. For this we need a cgi script that will generate an appropriate pack. Although stupid http fetching may have some potential if we ditch libcurl and use pipelining for http 1.1. Bandwidth wise that will never equal a custom pack because it will not do deltas. But in the common case of an incremental pull it should be able to equal rsync. Do we want to put some porcelain around, git-fsck-cache --tags? So we can discover the tag objects in the archive and place them someplace usable. Jeff Garzik in his howto is still recommending: > git-pull-script only downloads sha1-indexed object data, and the requested > remote head. > This misses updates to the .git/refs/tags/ and .git/refs/heads/ > directories. It is > advisable to update your kernel .git directories periodically with a full > rsync command, to > make sure you got everything: >$ cd linux-2.6 >$ rsync -a --verbose --stats --progress \ > rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \ > .git/ Which feels like something is missing. Given that tags are sha1-indexed objects we should be pulling them. And I believe you can have a tag as a parent of a commit, so even with the pack optimized clients we should be pulling them now. Eric - 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
Last mile to 1.0?
I do not know what release plan Linus has in mind, and also expect things to be quieter next week during OLS and kernel summit, but I think we are getting really really close. Here are the things I think we would want to see before we hit 1.0: - Remaining feature enhancements and fixes. - Anonymous pull from packed archives on remote sites via non-rsync, non-ssh transport. Many people are behind corporate firewalls that do not pass anything but outgoing http(s) and some do not even pass outgoing ssh. The recent addition of git-daemon by Linus would greatly alleviate the situation, but we may also end up wanting something HTTP reachable. - Documentation. - Many files under Documentation/ directory have become stale. I've tried to do one pass of full sweep recently, but I'd like somebody else to make another pass to make sure that the usage strings in programs, what the programs do, and what Documentation says they do match. Also, the spelling and grammar fixes, which I am very bad at and have not done any attempt, needs to be done. Volunteers? - Are all the files in Documentation/ reachable from git(7) or otherwise made into a standalone document using asciidoc by the Makefile? I haven't looked into documentation generation myself (I use only the text files as they are); help to update the Makefile by somebody handy with asciidoc suite is greatly appreciated here. Volunteers? - We may want to describe more Best Current Practices, along the lines of "Working with Others" section in the tutorial. Please write on your faviorite topic and send patches in ;-)) - Publicity. I would be very happy to see somebody with good writing and summarizing skills to prepare an article to be published on LWN.NET to coincide with the 1.0 release. An update to GIT traffic would also be nice. - 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
