{"thread":{"id":"2189","subject":"0.99.9 on Saturday next week.","startedAt":"2005-10-22T10:23:08Z","lastAt":"2005-10-26T17:55:44Z","messageCount":7,"participants":["Junio C Hamano","H. Peter Anvin","Catalin Marinas","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"10461","messageId":"7vvezpetpv.fsf@assigned-by-dhcp.cox.net","threadId":"2189","inReplyTo":null,"subject":"0.99.9 on Saturday next week.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-22T10:23:08Z","receivedAt":"2005-10-22T10:23:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"We have been at version \"0.99.8.GIT\" for too long, and\nmaintenance branch is now up to 0.99.8f.\n\nWhen git-daemon was deployed on kernel.org machines, I wanted to\nstabilize things a bit so that we can feature freeze and do a\nreal 1.0. Recently we have changed things quite a bit, but\nhaving them only in the \"master\" branch without having an\nofficial release for some time kept Porcelains in limbo. I am\nsure both Pasky and Catalin want to start updating Cogito and\nStGIT to take advantage of what the new core offers, but they\ncannot just randomly use new features only available in the\n\"master\" branch and expect people to use 0.99.8.GIT version of\nunknown vintage.\n\nSo here is a heads-up to list what to expect in 0.99.9. I am\nnot promising that 0.99.9 will be followed by 1.0 -- it could\nwell be 0.99.10.\n\nThe \"master\" branch, not counting barebone Porcelainish scripts\nthat real Porcelains would not utilize, contains the following\nadditions and enhancements. Many of them have been forward\nported to 0.99.8 maintenance branch already:\n\n - Cygwin (HPA).\n - Configuration files (Linus).\n - core.filemode to tell not to trust working tree mode bits.\n - git-daemon (HPA).\n - git-symbolic-ref for platforms with/without symlinks (Linus).\n - sparse .git/object/??/ directory (Linus).\n - git-update-ref.\n - funny pathnames quoted in C-style.\n - sha1^{} and sha1^{type} notation.\n - git-ls-remote reports object names tags point to.\n - git-apply operates in a sparse tree.\n - git-diff records which blob each patch applies to.\n - git-format-patch; --stdout and rev ranges.\n - git-update-index --index-info.\n - git-read-tree -m -u removes empty directories.\n - git-http-fetch drives multiple connections (Nick Hengeveld).\n - git-http-fetch is safer with funny-characters.\n - the name of packfile is more stable.\n - clone-pack keeps the pack unpacked.\n - git-check-ref-format; ref names are stricter than before.\n - git-pack-files --local (Linus).\n - fetch-pack git+ssh:// and ssh+git:// (Linus).\n - svn import (Matthias).\n - ls-tree filename listing bugfix (Robert Fitzsimons).\n - git-index-pack (Sergey).\n\nIn addition, we have handful things cooking in the proposed\nupdates branch. I expect these to come to some conclusion by\nthe end of next week, and 0.99.9 will contain what's ready by\nthen:\n\n - rev-list --dense (Linus).\n - fetch-pack further improvements (Johannes).\n - pack-objects using cached results.\n\nAlthough we had a good proposal for protocol rewrite from HPA\nand discussions that followed, it appeared to me that the change\nmight be a bit too backward incompatible while the advantage was\nnot obvious enough -- I do not think we have a consensus on it.\n0.99.9 will not wait for this discussion to conclude.\n\nOne last request. If you have sent bugfixes in the C-part of\nthe code (i.e. really core) that I have not applied without a\ngood reason, please remind me. I do not think I have dropped or\npostponed-then-forgot anything, but I just want to be sure. I\nam really in stabilization mood this week.\n"},{"id":"10464","messageId":"435A7CEA.9090201@zytor.com","threadId":"2189","inReplyTo":"7vvezpetpv.fsf@assigned-by-dhcp.cox.net","subject":"Re: 0.99.9 on Saturday next week.","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-10-22T17:54:50Z","receivedAt":"2005-10-22T17:54:50Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> Although we had a good proposal for protocol rewrite from HPA\n> and discussions that followed, it appeared to me that the change\n> might be a bit too backward incompatible while the advantage was\n> not obvious enough -- I do not think we have a consensus on it.\n> 0.99.9 will not wait for this discussion to conclude.\n> \n\nNot the least since it would be quite a bit of work to make it happen.\n\n\t-hpa\n"},{"id":"10572","messageId":"tnx64rlrjux.fsf@arm.com","threadId":"2189","inReplyTo":"7vvezpetpv.fsf@assigned-by-dhcp.cox.net","subject":"Re: 0.99.9 on Saturday next week.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-10-25T10:06:46Z","receivedAt":"2005-10-25T10:06:46Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> I am sure both Pasky and Catalin want to start updating Cogito and\n> StGIT to take advantage of what the new core offers, but they cannot\n> just randomly use new features only available in the \"master\" branch\n> and expect people to use 0.99.8.GIT version of unknown vintage.\n\nThe \"master\" branch in StGIT uses, in general, the latest features in\nthe \"master\" branch of GIT. I have a \"stable\" one which is restricted\nto a specific GIT version (0.99.8 at the moment).\n\n> - Configuration files (Linus).\n\nSince the configuration files use the .ini like syntax, is it OK for\nStGIT to use the same file, with an \"[stgit]\" section?\n\n-- \nCatalin\n"},{"id":"10591","messageId":"7virvlh6m5.fsf@assigned-by-dhcp.cox.net","threadId":"2189","inReplyTo":"tnx64rlrjux.fsf@arm.com","subject":"Re: 0.99.9 on Saturday next week.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-10-25T17:02:58Z","receivedAt":"2005-10-25T17:02:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Catalin Marinas writes:\n\n>> - Configuration files (Linus).\n>\n> Since the configuration files use the .ini like syntax, is it OK for\n> StGIT to use the same file, with an \"[stgit]\" section?\n\nI think that is a reasonable thing to do.\n"},{"id":"10595","messageId":"Pine.LNX.4.64.0510251033310.10477@g5.osdl.org","threadId":"2189","inReplyTo":"7virvlh6m5.fsf@assigned-by-dhcp.cox.net","subject":"Re: 0.99.9 on Saturday next week.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-25T17:41:56Z","receivedAt":"2005-10-25T17:41:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 25 Oct 2005, Junio C Hamano wrote:\n>\n> Catalin Marinas writes:\n> \n> >> - Configuration files (Linus).\n> >\n> > Since the configuration files use the .ini like syntax, is it OK for\n> > StGIT to use the same file, with an \"[stgit]\" section?\n> \n> I think that is a reasonable thing to do.\n\nAbsolutely. The whole thing was _designed_ to be used that way. Any C user \nshould be able to just link against config.o without even bothering with \nthe rest of git (the only git-specific thing there should be some naming), \nand any script user can either\n\n - parse the simple config language by hand (not really a good idea, but \n it _is_ pretty simple)\n - just run \"git-var -l\" and parse the output.\n\nie if you want to track \"[stgit]\" config options, just do\n\n\tgit-var -l | sed '/^stgit\\./ s/^stgit.//p'\n\nand it will pick up everything starting with \"stgit.\" and remove that \npart.\n\nWhat remains should be a simple list or \"variable=value\" pairs.\n\nOh - and the convention is that \n\n (a) we've already done any quote expansion (although I may have to make \n git-var quote \"\\n\" - I didn't care enough to do so)\n (b) a boolean variable without a \"=\" means that it was set to \"true\" \n (which is different from an _empty_ one, which has a \"=\" but just \n doesn't have any value)\n\nThe (b) thing is just a special case, so that you can write\n\n\t[stgit]\n\t\tdebug\n\nand it will be the same as\n\n\t[stgit]\n\t\tdebug = true\n\nwhich just seems to be the sane thing to do.\n\n\t\tLinus\n"},{"id":"10655","messageId":"b0943d9e0510260450k624268aav@mail.gmail.com","threadId":"2189","inReplyTo":"Pine.LNX.4.64.0510251033310.10477@g5.osdl.org","subject":"Re: 0.99.9 on Saturday next week.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-10-26T11:50:34Z","receivedAt":"2005-10-26T11:50:34Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 25/10/05, Linus Torvalds wrote:\n> On Tue, 25 Oct 2005, Junio C Hamano wrote:\n> > Catalin Marinas writes:\n> > > Since the configuration files use the .ini like syntax, is it OK for\n> > > StGIT to use the same file, with an \"[stgit]\" section?\n> >\n> > I think that is a reasonable thing to do.\n>\n> Absolutely. The whole thing was _designed_ to be used that way. Any C user\n> should be able to just link against config.o without even bothering with\n> the rest of git (the only git-specific thing there should be some naming),\n> and any script user can either\n\nI use Python for StGIT and it has support for parsing .ini syntax, no\nneed to use GIT for this (unless the syntax you chose would diverge\ntoo much).\n\n--\nCatalin\n"},{"id":"10676","messageId":"Pine.LNX.4.64.0510261046570.10477@g5.osdl.org","threadId":"2189","inReplyTo":"b0943d9e0510260450k624268aav@mail.gmail.com","subject":"Re: 0.99.9 on Saturday next week.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-10-26T17:55:44Z","receivedAt":"2005-10-26T17:55:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 26 Oct 2005, Catalin Marinas wrote:\n> \n> I use Python for StGIT and it has support for parsing .ini syntax, no\n> need to use GIT for this (unless the syntax you chose would diverge\n> too much).\n\nThe syntax differences I'm aware of:\n\n - the git \".ini\" parser is case-insensitive in the variable names. I \n don't know if this is true in general. I do know a lot of people use \n MixedCase things, but I don't know if it's because they care, or \n because they think it's so pretty.\n\n - the git parser accepts either \";\" or \"#\" as comments, and anywhere on a \n line (not just at the beginning). Again, others may or may not do the \n same.\n\n - the git parser wants a \"=\" for the assignment. I think the Python one \n also accepts \":\". If people care, we could make the git parser allow \n either.\n\n - duplicate entries. The git parser allows them, and will just pass them \n on multiple times. In fact, I had a patch (that I threw out) that \n depended on this, and allowed you to rewrite hostnames for git_connect \n with something like\n\n\t[host]\n\t\trewrite = \"host.com:\" \"git://git.host.com/\"\n\t\trewrite = \"other.org:\" \"rsync://rsync.other.org/\"\n\n and the git config file parser happily just parses this as two \n different entries for \"host.rewrite\"\n\n - quoting. This is likely the big one. The git parser thinks only the \n regular '\"' character (\"rabbit ears\") is a quote, and passes single- \n ticks through unmolested. I don't have a clue what others do, if \n anything.\n\nIn the absense of quotes, most should be trivial to handle by just being \ncareful.\n\n\t\tLinus\n"}]}