{"thread":{"id":"1259","subject":"Last mile to 1.0?","startedAt":"2005-07-16T17:46:00Z","lastAt":"2005-07-30T02:11:25Z","messageCount":19,"participants":["Junio C Hamano","Eric W. Biederman","David Lang","Alexey Nezhdanov","Ryan Anderson","Gene Heskett","Kevin Smith","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6192","messageId":"7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net","threadId":"1259","inReplyTo":null,"subject":"Last mile to 1.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-16T17:46:00Z","receivedAt":"2005-07-16T17:46:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I do not know what release plan Linus has in mind, and also\nexpect things to be quieter next week during OLS and kernel\nsummit, but I think we are getting really really close.\n\nHere are the things I think we would want to see before we hit\n1.0:\n\n - Remaining feature enhancements and fixes.\n\n   - Anonymous pull from packed archives on remote sites via\n     non-rsync, non-ssh transport.  Many people are behind\n     corporate firewalls that do not pass anything but outgoing\n     http(s) and some do not even pass outgoing ssh.  The recent\n     addition of git-daemon by Linus would greatly alleviate the\n     situation, but we may also end up wanting something HTTP\n     reachable.\n\n - Documentation.\n\n   - Many files under Documentation/ directory have become\n     stale.  I've tried to do one pass of full sweep recently,\n     but I'd like somebody else to make another pass to make\n     sure that the usage strings in programs, what the programs\n     do, and what Documentation says they do match.  Also, the\n     spelling and grammar fixes, which I am very bad at and have\n     not done any attempt, needs to be done.\n\n     Volunteers?\n\n   - Are all the files in Documentation/ reachable from git(7)\n     or otherwise made into a standalone document using asciidoc\n     by the Makefile?  I haven't looked into documentation\n     generation myself (I use only the text files as they are);\n     help to update the Makefile by somebody handy with asciidoc\n     suite is greatly appreciated here.\n\n     Volunteers?\n\n   - We may want to describe more Best Current Practices, along\n     the lines of \"Working with Others\" section in the tutorial.\n     Please write on your faviorite topic and send patches in\n     ;-))\n\n - Publicity.  I would be very happy to see somebody with good\n   writing and summarizing skills to prepare an article to be\n   published on LWN.NET to coincide with the 1.0 release.  An\n   update to GIT traffic would also be nice.\n"},{"id":"6194","messageId":"m18y06pphg.fsf@ebiederm.dsl.xmission.com","threadId":"1259","inReplyTo":"7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile to 1.0?","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-16T18:36:43Z","receivedAt":"2005-07-16T18:36:43Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> I do not know what release plan Linus has in mind, and also\n> expect things to be quieter next week during OLS and kernel\n> summit, but I think we are getting really really close.\n>\n> Here are the things I think we would want to see before we hit\n> 1.0:\n>\n>  - Remaining feature enhancements and fixes.\n>\n>    - Anonymous pull from packed archives on remote sites via\n>      non-rsync, non-ssh transport.  Many people are behind\n>      corporate firewalls that do not pass anything but outgoing\n>      http(s) and some do not even pass outgoing ssh.  The recent\n>      addition of git-daemon by Linus would greatly alleviate the\n>      situation, but we may also end up wanting something HTTP\n>      reachable.\n\nFor this we need a cgi script that will generate an appropriate\npack.  Although stupid http fetching may have some potential\nif we ditch libcurl and use pipelining for http 1.1.  Bandwidth\nwise that will never equal a custom pack because it will not do\ndeltas.  But in the common case of an incremental pull it should\nbe able to equal rsync.\n\nDo we want to put some porcelain around, git-fsck-cache --tags?\nSo we can discover the tag objects in the archive and place\nthem someplace usable.  Jeff Garzik in his howto is still recommending:\n\n>   git-pull-script only downloads sha1-indexed object data, and the requested remote head.\n>   This misses updates to the .git/refs/tags/ and .git/refs/heads/ directories. It is\n>   advisable to update your kernel .git directories periodically with a full rsync command, to\n>   make sure you got everything:\n>$ cd linux-2.6\n>$ rsync -a --verbose --stats --progress \\\n>   rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \\\n>   .git/\n\nWhich feels like something is missing.  Given that tags are\nsha1-indexed objects we should be pulling them.  And I believe you can\nhave a tag as a parent of a commit, so even with the pack optimized\nclients we should be pulling them now.  \n\n\nEric\n"},{"id":"6206","messageId":"7vy8869ryi.fsf@assigned-by-dhcp.cox.net","threadId":"1259","inReplyTo":"m18y06pphg.fsf@ebiederm.dsl.xmission.com","subject":"Re: Last mile to 1.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-17T00:49:57Z","receivedAt":"2005-07-17T00:49:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"ebiederm@xmission.com (Eric W. Biederman) writes:\n\n> Junio C Hamano <junkio@cox.net> writes:\n>>\n>>    - Anonymous pull from packed archives on remote sites via\n>>      non-rsync, non-ssh transport.  ...\n>>      ... but we may also end up wanting something HTTP\n>>      reachable.\n>\n> For this we need a cgi script that will generate an appropriate\n> pack.\n\nI agree that nothing would beat a pack customized for each\npuller from the bandwidth point of view.  I like the general\nidea of git-daemon Linus did and the cgi script you suggest, but\nI wonder what the CPU/disk load implications for the server.\n"},{"id":"6208","messageId":"Pine.LNX.4.62.0507161815100.15383@qynat.qvtvafvgr.pbz","threadId":"1259","inReplyTo":"7vy8869ryi.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile to 1.0?","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2005-07-17T01:18:24Z","receivedAt":"2005-07-17T01:18:24Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"On Sat, 16 Jul 2005, Junio C Hamano wrote:\n\n> ebiederm@xmission.com (Eric W. Biederman) writes:\n>\n>> Junio C Hamano <junkio@cox.net> writes:\n>>>\n>>>    - Anonymous pull from packed archives on remote sites via\n>>>      non-rsync, non-ssh transport.  ...\n>>>      ... but we may also end up wanting something HTTP\n>>>      reachable.\n>>\n>> For this we need a cgi script that will generate an appropriate\n>> pack.\n>\n> I agree that nothing would beat a pack customized for each\n> puller from the bandwidth point of view.  I like the general\n> idea of git-daemon Linus did and the cgi script you suggest, but\n> I wonder what the CPU/disk load implications for the server.\n>\n\nI think you need to nail down the various scenerios that people will be \nuseing here.\n\na very common one will be prople who want to setup a cron job to update \ntheir local tree nightly, in this case having a pre-generated pack file \nwith each day's updates will save a significant amount of processing \npower.\n\nwould it make sense to have it do something along the lines of sending the \nday;s pack file plus a small number of individual object (even if the pack \nfile will partially duplicate object the puller already has)\n\nDavid Lang\n\n\n-- \nThere 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.\n  -- C.A.R. Hoare\n"},{"id":"6240","messageId":"200507180853.41633.snake@penza-gsm.ru","threadId":"1259","inReplyTo":"7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile to 1.0?","fromName":"Alexey Nezhdanov","fromEmail":"snake@penza-gsm.ru","sentAt":"2005-07-18T04:53:41Z","receivedAt":"2005-07-18T04:53:41Z","isPatch":false,"sender":{"key":"snake@penza-gsm.ru","avatar":null},"body":"Satturday, 16 July 2005 21:46 Junio C Hamano wrote:\n> I do not know what release plan Linus has in mind, and also\n> expect things to be quieter next week during OLS and kernel\n> summit, but I think we are getting really really close.\n>\n> Here are the things I think we would want to see before we hit\n> 1.0:\n>\n>  - Remaining feature enhancements and fixes.\n>\n>    - Anonymous pull from packed archives on remote sites via\n>      non-rsync, non-ssh transport.  Many people are behind\n>      corporate firewalls that do not pass anything but outgoing\n>      http(s) and some do not even pass outgoing ssh.  The recent\n>      addition of git-daemon by Linus would greatly alleviate the\n>      situation, but we may also end up wanting something HTTP\n>      reachable.\nI'd add the UTF-8 native support. Currently neither commit nor gitk doesn't \nsupport that. Probably this should be done at as low as possible level.\n\n\n-- \nRespectfully\nAlexey Nezhdanov\n"},{"id":"6241","messageId":"7vfyucfzgt.fsf@assigned-by-dhcp.cox.net","threadId":"1259","inReplyTo":"200507180853.41633.snake@penza-gsm.ru","subject":"Re: Last mile to 1.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-18T05:35:46Z","receivedAt":"2005-07-18T05:35:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexey Nezhdanov <snake@penza-gsm.ru> writes:\n\n> I'd add the UTF-8 native support. Currently neither commit nor gitk doesn't \n> support that. Probably this should be done at as low as possible level.\n\nI do not understand your proposal.  Care to clarify?  You can\nwrite your commit messages in UTF-8 today and \"git-cat-file\ncommit $commit_ID\", which is as low level as you can go, gives\nyou that commit message in UTF-8.\n"},{"id":"6243","messageId":"7vackkekif.fsf@assigned-by-dhcp.cox.net","threadId":"1259","inReplyTo":"Pine.LNX.4.62.0507161815100.15383@qynat.qvtvafvgr.pbz","subject":"Re: Last mile to 1.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-18T05:44:08Z","receivedAt":"2005-07-18T05:44:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Lang <david.lang@digitalinsight.com> writes:\n\n> a very common one will be prople who want to setup a cron job to\n> update their local tree nightly, in this case having a pre-generated\n> pack file with each day's updates will save a significant amount of\n> processing power.\n>\n> would it make sense to have it do something along the lines of sending\n> the day;s pack file plus a small number of individual object (even if\n> the pack file will partially duplicate object the puller already has)\n\nI think that would be a reasonable thing to do.  The server for\nanonymous puller, git-daemon, may need some extending.  As\npeople criticised, git-upload-pack/git-fetch-pack protocol being\nnot easily extensible, we would end up doing another protocol,\nthough, that's OK.\n\nFortunately [*1*], git-daemon itself is written to be extensible\nif you are willing to introduce a totally new protocol driver,\nso if this on-demand pack generation turns out to be too much\na resource hog, we have a reasonably easy way out.\n\n\n[Footnote]\n\n*1* We are fortunate but that is not by dumb luck.  When he did\ndaemon.c::execute(), Linus must have thought things through.\n"},{"id":"6245","messageId":"200507181048.50303.snake@penza-gsm.ru","threadId":"1259","inReplyTo":"7vfyucfzgt.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile to 1.0?","fromName":"Alexey Nezhdanov","fromEmail":"snake@penza-gsm.ru","sentAt":"2005-07-18T06:48:50Z","receivedAt":"2005-07-18T06:48:50Z","isPatch":false,"sender":{"key":"snake@penza-gsm.ru","avatar":null},"body":"Monday, 18 July 2005 09:35 Junio C Hamano wrote:\n> Alexey Nezhdanov <snake@penza-gsm.ru> writes:\n> > I'd add the UTF-8 native support. Currently neither commit nor gitk\n> > doesn't support that. Probably this should be done at as low as possible\n> > level.\n>\n> I do not understand your proposal.  Care to clarify?  You can\n> write your commit messages in UTF-8 today and \"git-cat-file\n> commit $commit_ID\", which is as low level as you can go, gives\n> you that commit message in UTF-8.\nYes. But it have not integration with user environment. Personally I use \nkoi8-r environment and doing \"cg commit\" (and probably \"git commit\" too) \nresults in koi8-r text written as commit text. I remember that this issue \nwere discussed on this list and all come to conclusion that utf-8 is the only \nsane encoding that can be used in this case.\nBut this should not be user's problem - it's just the UI that doesn't \nunderstands when transcoding should be done.\nSimilarly - when I start gitk then I see only weird symbols instead of commit \ntext, not matter what encoding I use for commits - koi8-r or utf-8. BTW \nrussian koi8-r encoded text _in_diff_contents_ show correctly. Wonder why...\n-- \nRespectfully\nAlexey Nezhdanov\n"},{"id":"6246","messageId":"7vr7dw36nz.fsf@assigned-by-dhcp.cox.net","threadId":"1259","inReplyTo":"200507181048.50303.snake@penza-gsm.ru","subject":"Re: Last mile to 1.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-18T07:38:40Z","receivedAt":"2005-07-18T07:38:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexey Nezhdanov <snake@penza-gsm.ru> writes:\n\n> But this should not be user's problem - it's just the UI that doesn't \n> understands when transcoding should be done.\n\nI disagree.\n\nYes, while you _could_ do something like this to feed text in\nlocal encoding to the VISUAL/EDITOR, and convert it back to\nUTF-8:\n\n--- a/git-commit-script\n+++ b/git-commit-script\n@@ -84,7 +84,7 @@\n fi\n if [ \"$?\" != \"0\" ]\n then\n-\tcat .editmsg\n+\tgit-char-conv --utf8-to-user < .editmsg\n \trm .editmsg\n \texit 1\n fi\n@@ -93,7 +93,9 @@\n \t${VISUAL:-${EDITOR:-vi}} .editmsg\n \t;;\n esac\n-grep -v '^#' < .editmsg | git-stripspace > .cmitmsg\n+grep -v '^#' < .editmsg |\n+git-stripspace |\n+git-char-conv --user-to-utf8 > .cmitmsg\n [ -s .cmitmsg ] && \n \ttree=$(git-write-tree) &&\n \tcommit=$(cat .cmitmsg | git-commit-tree $tree $PARENTS) &&\n\n\nI think it is a horrible way to do things.\n\nI presume that your bringing up UTF-8 suggests that you believe\ndoing things in UTF-8 for interoperability's sake is the right\nthing.  If that is indeed the case, then tools other than GIT\nand Cogito you would use would need to deal with this exact same\nproblem, that your VISUAL/EDITOR does not understand UTF-8.\n\nHow about writing a little wrapper, koi-vi, which would roughly\nbe:\n\n    #!/bin/sh\n    tcs -f utf -t koi8 \"$1\" >.tmp-koi\n    vi .tmp-koi\n    tcs -t utf -f koi8 .tmp-koi >\"$1\"\n\nand point VISUAL/EDITOR environment variable at it?  That way\nyour other tools would be able to let you keep using your\nfavorite editor, now utf8 enabled, and deal with UTF-8.  None of\nthe scripts, including the script I quoted above, has to be\nchanged that way.\n\nHaving said that, I personally feel that the choice of the\ncharacter encoding of commit messages is per-project convention\nissue and does not even warrant a per-project \"configuration\nfile\".  As long as your developers all agree to use KOI, and you\nare reasonably sure that you will not ever cross-merge with\nanother project that uses different encoding for commit\nmessages, I think it is perfectly fine to use KOI in your commit\nmessages.  The core's job is only to ensure that we are 8-bit\nclean and faithfully record whatever you throw at us.\n"},{"id":"6371","messageId":"20050723081549.GC3255@mythryan2.michonline.com","threadId":"1259","inReplyTo":"7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile to 1.0?","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-07-23T08:15:49Z","receivedAt":"2005-07-23T08:15:49Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote:\n> I do not know what release plan Linus has in mind, and also\n> expect things to be quieter next week during OLS and kernel\n> summit, but I think we are getting really really close.\n\nLooking at the set of patches we just all dumped on Linus, I think they\npretty much show us that we don't have any major issues.\n\nAs I see it, the status is currently like this:\n\nRevision control - Stable\nPulling locally or over rsync - Stable\nPushing over ssh - Stable\n\nRemote, anonymous pulls not using rsync - Beta\nUsability features[1] - Beta\n\nDocumentation - Alpha\n\nMy feeling is that we're pretty well set to do a 1.0 release.\n\n1 - Usability features are all the things around git-apply,\ngit-format-patch, etc, that we're clearly working on to make life more\npleasant, but aren't really critical.\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"6373","messageId":"20050723085031.GD3255@mythryan2.michonline.com","threadId":"1259","inReplyTo":"7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile to 1.0?","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2005-07-23T08:50:31Z","receivedAt":"2005-07-23T08:50:31Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote:\n>  - Publicity.  I would be very happy to see somebody with good\n>    writing and summarizing skills to prepare an article to be\n>    published on LWN.NET to coincide with the 1.0 release.  An\n>    update to GIT traffic would also be nice.\n\nHow is this for a start?\n\nSource Code Management with Git\n\nGit, sometimes called \"global information tracker\", is a \"directory\ncontent manager\".  Git has been designed to handle absolutely massive\nprojects with speed and efficiency, and the release of the 2.6.12 and\n(soon) the 2.6.13 version of the Linux kernel would indicate that it\ndoes this task well.\n\nGit falls into the category of distributed source code management tools,\nsimilar to Arch or Darcs (or, in the commercial world, BitKeeper).  This\nmeans that every working directory is a full-fledged repository with\nfull revision tracking capabilities.\n\nGit uses the SHA1 hash algorithm to provide a content-addressable pseudo\nfilesystem, complete with its own version of fsck.\n  o Speed of use, both for the project maintainer, and the end-users, is\n    a key development principle.\n  o The history is stored as a directed acyclic graph, making long-lived\n    branches and repeated merging simple.\n  o A collection of related projects are building on the core Git\n    project, either to provide an easier to use interface on top (Darcs,\n    Mercurial, StGit, Cogito), or to take some of the underlying concepts\n    and reimplement them directly into another system (Arch 2.0).\n  o Two, interchangeable, on-disk formats are used:\n    o An efficient, packed format that saves spaced and network\n      bandwidth.\n    o An unpacked format, optimized for fast writes and incremental\n      work.\n\nGit results from the inspiration and frustration of Linus Torvalds, and\nthe enthusiastic help of over 300 participants on the development\nmailing list.[1]\n\n\n1 - Generated with the following, in a maildir folder:\n\tfind . -type f | xargs grep -h \"^From:\" | perl -ne \\\n\t'tr#A-Z#a-z#; m#<(.*)># && print $1,\"\\n\";' | sort -u | wc -l \n\n\n-- \n\nRyan Anderson\n  sometimes Pug Majere\n"},{"id":"6382","messageId":"200507230856.00212.gene.heskett@verizon.net","threadId":"1259","inReplyTo":"20050723081549.GC3255@mythryan2.michonline.com","subject":"Re: Last mile to 1.0?","fromName":"Gene Heskett","fromEmail":"gene.heskett@verizon.net","sentAt":"2005-07-23T12:56:00Z","receivedAt":"2005-07-23T12:56:00Z","isPatch":false,"sender":{"key":"gene.heskett@verizon.net","avatar":null},"body":"On Saturday 23 July 2005 04:15, Ryan Anderson wrote:\n>On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote:\n>> I do not know what release plan Linus has in mind, and also\n>> expect things to be quieter next week during OLS and kernel\n>> summit, but I think we are getting really really close.\n>\n>Looking at the set of patches we just all dumped on Linus, I think\n> they pretty much show us that we don't have any major issues.\n>\n>As I see it, the status is currently like this:\n>\n>Revision control - Stable\n>Pulling locally or over rsync - Stable\n>Pushing over ssh - Stable\n>\n>Remote, anonymous pulls not using rsync - Beta\n>Usability features[1] - Beta\n>\n>Documentation - Alpha\n\nOne old farts comment re the docs here folks.\n\nThis will need to be improved considerably if you want all us lurking \nfrogs to be able to use it without drowning this list with what \nreally should be RTFMable questions.  Specifically, we should be able \nto dl one package and install something that, by reading the \nmanpages, can be made to work OOTB given an adequate network \nconnection.\n\nMy lurking & reading the mail here tends to give me the impression \nthat while it can be made to work, there are yet rough edges for the \nnew user.  Potentially discouraging rough edges...\n\n>My feeling is that we're pretty well set to do a 1.0 release.\n>\n>1 - Usability features are all the things around git-apply,\n>git-format-patch, etc, that we're clearly working on to make life\n> more pleasant, but aren't really critical.\n\n-- \nCheers, Gene\n\"There are four boxes to be used in defense of liberty:\n soap, ballot, jury, and ammo. Please use in that order.\"\n-Ed Howdershelt (Author)\n99.35% setiathome rank, not too shabby for a WV hillbilly\nYahoo.com and AOL/TW attorneys please note, additions to the above\nmessage by Gene Heskett are:\nCopyright 2005 by Maurice Eugene Heskett, all rights reserved.\n"},{"id":"6383","messageId":"200507230914.18095.gene.heskett@verizon.net","threadId":"1259","inReplyTo":"20050723085031.GD3255@mythryan2.michonline.com","subject":"Re: Last mile to 1.0?","fromName":"Gene Heskett","fromEmail":"gene.heskett@verizon.net","sentAt":"2005-07-23T13:14:17Z","receivedAt":"2005-07-23T13:14:17Z","isPatch":false,"sender":{"key":"gene.heskett@verizon.net","avatar":null},"body":"Duplicate send, had typo in orif address line :(\nOn Saturday 23 July 2005 04:50, Ryan Anderson wrote:\n>On Sat, Jul 16, 2005 at 10:46:00AM -0700, Junio C Hamano wrote:\n>>  - Publicity.  I would be very happy to see somebody with good\n>>    writing and summarizing skills to prepare an article to be\n>>    published on LWN.NET to coincide with the 1.0 release.  An\n>>    update to GIT traffic would also be nice.\n>\n>How is this for a start?\n>\n>Source Code Management with Git\n>\n>Git, sometimes called \"global information tracker\", is a \"directory\n>content manager\".  Git has been designed to handle absolutely\n> massive projects with speed and efficiency, and the release of the\n> 2.6.12 and (soon) the 2.6.13 version of the Linux kernel would\n> indicate that it does this task well.\n>\n>Git falls into the category of distributed source code management\n> tools, similar to Arch or Darcs (or, in the commercial world,\n> BitKeeper).  This means that every working directory is a\n> full-fledged repository with full revision tracking capabilities.\n>\n>Git uses the SHA1 hash algorithm to provide a content-addressable\n> pseudo filesystem, complete with its own version of fsck.\n>  o Speed of use, both for the project maintainer, and the\n> end-users, is a key development principle.\n>  o The history is stored as a directed acyclic graph, making\n> long-lived branches and repeated merging simple.\n>  o A collection of related projects are building on the core Git\n>    project, either to provide an easier to use interface on top\n> (Darcs, Mercurial, StGit, Cogito), or to take some of the\n> underlying concepts and reimplement them directly into another\n> system (Arch 2.0). o Two, interchangeable, on-disk formats are\n> used:\n>    o An efficient, packed format that saves spaced and network\n>      bandwidth.\n>    o An unpacked format, optimized for fast writes and incremental\n>      work.\n>\nA very good start for the overview preamble.  Do carry on.\n\n>Git results from the inspiration and frustration of Linus Torvalds,\n> and the enthusiastic help of over 300 participants on the\n> development mailing list.[1]\n>\n>\n>1 - Generated with the following, in a maildir folder:\n> find . -type f | xargs grep -h \"^From:\" | perl -ne \\\n> 'tr#A-Z#a-z#; m#<(.*)># && print $1,\"\\n\";' | sort -u | wc -l\n\n-- \nCheers, Gene\n\"There are four boxes to be used in defense of liberty:\n soap, ballot, jury, and ammo. Please use in that order.\"\n-Ed Howdershelt (Author)\n99.35% setiathome rank, not too shabby for a WV hillbilly\nYahoo.com and AOL/TW attorneys please note, additions to the above\nmessage by Gene Heskett are:\nCopyright 2005 by Maurice Eugene Heskett, all rights reserved.\n"},{"id":"6385","messageId":"42E25874.2090201@qualitycode.com","threadId":"1259","inReplyTo":"20050723085031.GD3255@mythryan2.michonline.com","subject":"Re: Last mile to 1.0?","fromName":"Kevin Smith","fromEmail":"yarcs@qualitycode.com","sentAt":"2005-07-23T14:47:16Z","receivedAt":"2005-07-23T14:47:16Z","isPatch":false,"sender":{"key":"yarcs@qualitycode.com","avatar":null},"body":"Ryan Anderson wrote:\n> Git falls into the category of distributed source code management tools,\n> similar to Arch or Darcs (or, in the commercial world, BitKeeper).  This\n> means that every working directory is a full-fledged repository with\n> full revision tracking capabilities.\n\nThat's not actually what \"distributed\" means. There are several \ndistributed SCM tools[1] that store repo information outside the actual \nworking directory.\n\nPerhaps that last sentence could be something like \"This means that each \ndeveloper has a local full-fledged repository with full revision \ntracking capabilities, not dependent on network access to a central \nserver.\" I'm sure there are better wordings, but I hate to point out an \nproblem without offering at least one possible improvement.\n\nKevin\n\n[1] I believe that ArX, monotone, codeville, and svk all fall into this \ncategory. Possibly even Arch itself, although I haven't researched that.\n"},{"id":"6388","messageId":"7vzmsdqwiw.fsf@assigned-by-dhcp.cox.net","threadId":"1259","inReplyTo":"20050723085031.GD3255@mythryan2.michonline.com","subject":"Re: Last mile to 1.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-23T17:09:43Z","receivedAt":"2005-07-23T17:09:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ryan Anderson <ryan@michonline.com> writes:\n\n> How is this for a start?\n\nA very good start indeed.  Thanks.\n\n> Git falls into the category of distributed source code management tools,\n> similar to Arch or Darcs (or, in the commercial world, BitKeeper).  This\n> means that every working directory is a full-fledged repository with\n> full revision tracking capabilities.\n\nI think Kevin's comment is valid and his description is reasonable.\n\n>   o A collection of related projects are building on the core Git\n>     project, either to provide an easier to use interface on top (Darcs,\n>     Mercurial, StGit, Cogito), or to take some of the underlying concepts\n>     and reimplement them directly into another system (Arch 2.0).\n\nI think you would want to drop Darcs and Mercurial from the \"on\ntop\" list.  If I understand correctly, Mercurial is\nindependently written with its own on-disk formats [*1*].  It\nwould be very unfair to put Darcs in \"building on\" category.\nThey've been there for quite some time with their own repository\nformat and the tools and interfaces are reasonably mature.\n\nInstead, please add gitk and gitweb to the list.  We should not\nforget that these \"mostly read-only\" things are Porcelains.\n\n\n[Footnote]\n\n*1* It feels that actually it is done right.  Its misfortune is\nthat many core kernel people have already switched to git.\n"},{"id":"6396","messageId":"7vsly5korm.fsf@assigned-by-dhcp.cox.net","threadId":"1259","inReplyTo":"20050723081549.GC3255@mythryan2.michonline.com","subject":"[PATCH 0/6] A bit better dumb server support","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-24T00:53:49Z","receivedAt":"2005-07-24T00:53:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Several days ago there was a discussion on discovering remote\ntags and branches.  This was somewhat related to supporting\npacked repositories on a dumb server I have been toying with, so\nhere is my current status.\n\nThe first three patches deal with the discovery of remote tags\nand heads:\n\n  [PATCH 1/6] git-peek-remote: show tags and heads from a remote repository.\n  [PATCH 2/6] Documentation: git-peek-remote.\n  [PATCH 3/6] git-ls-remote: show and optionally store remote refs.\n\nThe discovery over http transport against a dumb server needs to\nhave a couple of files to support it, which is prepared with the\nnext two patches.\n\n  [PATCH 4/6] Add update-server-info.\n  [PATCH 5/6] Document update-server-info.\n\nThe git-update-server-info command introduced by these two\npatches prepare not just the list of tags and heads, but the\nlist of packs and commit ancestry information.  Using that,\ncloning a packed repository over http transport from a dumb\nserver becomes trivial.\n\n  [PATCH 6/6] Support cloning packed repo from dumb http servers.\n\nThe next task would be to add support of the same to git-fetch.\n"},{"id":"6404","messageId":"200507240712.43013.snake@penza-gsm.ru","threadId":"1259","inReplyTo":"7vzmsdqwiw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile to 1.0?","fromName":"Alexey Nezhdanov","fromEmail":"snake@penza-gsm.ru","sentAt":"2005-07-24T03:12:42Z","receivedAt":"2005-07-24T03:12:42Z","isPatch":false,"sender":{"key":"snake@penza-gsm.ru","avatar":null},"body":"Satturday, 23 July 2005 21:09 Junio C Hamano wrote:\n> Instead, please add gitk and gitweb to the list.  We should not\n> forget that these \"mostly read-only\" things are Porcelains.\nThen add qgit too to provide fair coverage.\n\n-- \nRespectfully\nAlexey Nezhdanov\n"},{"id":"6605","messageId":"20050729224148.GB22530@pasky.ji.cz","threadId":"1259","inReplyTo":"7vwtnqhcfb.fsf@assigned-by-dhcp.cox.net","subject":"Re: Last mile to 1.0?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-29T22:41:48Z","receivedAt":"2005-07-29T22:41:48Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jul 16, 2005 at 07:46:00PM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> I do not know what release plan Linus has in mind, and also\n> expect things to be quieter next week during OLS and kernel\n> summit, but I think we are getting really really close.\n> \n> Here are the things I think we would want to see before we hit\n> 1.0:\n> \n>  - Remaining feature enhancements and fixes.\n> \n>    - Anonymous pull from packed archives on remote sites via\n>      non-rsync, non-ssh transport.  Many people are behind\n>      corporate firewalls that do not pass anything but outgoing\n>      http(s) and some do not even pass outgoing ssh.  The recent\n>      addition of git-daemon by Linus would greatly alleviate the\n>      situation, but we may also end up wanting something HTTP\n>      reachable.\n\nI hope to get to it tomorrow but it now occurred to me that I don't know\nwhen do you actually want to release 1.0 and I think it's crucial for it\nto support some sensible HTTP transport - I saw some scripts going in\netc, but what's its current state? Is it usable?\n\nNote that I really _loved_ the Daniel's tools while they lasted. What I\nloved most about them was that they really only pulled objects I needed\nand not a single worthless one. Does the current HTTP transport share\nthis property?\n\n>  - Publicity.  I would be very happy to see somebody with good\n>    writing and summarizing skills to prepare an article to be\n>    published on LWN.NET to coincide with the 1.0 release.  An\n>    update to GIT traffic would also be nice.\n\nNote that I also want to setup a simple \"proof-of-concept\" GIT homepage\ntomorrow. Well, write it, where it should be hosted can be worked out\nlater and I have places for it to reside at for now. (Suggestions for\nfinal hosting welcome. In reality, how nice (and persistent) the URL\ngets is probably the only thing that really matters. My attempt will\nlive at http://git.or.cz/.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6614","messageId":"7v4qad82lu.fsf@assigned-by-dhcp.cox.net","threadId":"1259","inReplyTo":"20050729224148.GB22530@pasky.ji.cz","subject":"Re: Last mile to 1.0?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-30T02:11:25Z","receivedAt":"2005-07-30T02:11:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Note that I really _loved_ the Daniel's tools while they lasted. What I\n> loved most about them was that they really only pulled objects I needed\n> and not a single worthless one. Does the current HTTP transport share\n> this property?\n\nI am a big fan of Barkalow puller, too.  It is conceptually\nsimple, very easy to explain, and quite nicely done to be\ntransport independent.  Performance sucks, but that is not Dan's\nfault.\n\nIf we are talking about a dumb HTTP server that has packed and\nthen prune-packed its repository, \"not a single worthless one\"\nis asking for moon.  If Jeff packed all his 50 branches into a\nsingle pack and prune packed his repository, the only thing a\ndumb server could do when you ask for one of his branches is to\ngive you that statically prepared single pack which contains\neverything, because there would be nothing in .git/objects/??/.\nYou need some CGI support that pulls only needed objects out of\nthat pack and talks a moral equivalent of the upload-pack\nprotocol for that.\n\nBarkalow puller is still useful when all the objects you still\nneed to pull from the remote are unpacked on the remote end.\nThat's how I resurrected \"git clone\" over http with packed dumb\nservers.  For \"clone\" case, I just slurp all the available\npacks, and have Barkalow puller take over the rest.\n\nI have an early WIP for \"git fetch\", but I have backburnered it\nfor quite some time.  I'll push it in its current form into my\nproposed updates branch, so interested people can hack on it.\n\n> Note that I also want to setup a simple \"proof-of-concept\" GIT homepage\n> tomorrow. Well, write it, where it should be hosted can be worked out\n> later and I have places for it to reside at for now. (Suggestions for\n> final hosting welcome. In reality, how nice (and persistent) the URL\n> gets is probably the only thing that really matters. My attempt will\n> live at http://git.or.cz/.)\n\nI hope nobody starts another SCM project called CZ ;-).\n"}]}