{"thread":{"id":"5535","subject":"What's in git.git","startedAt":"2006-09-11T02:21:10Z","lastAt":"2006-09-24T10:37:57Z","messageCount":16,"participants":["Junio C Hamano","Jakub Narebski","Petr Baudis","Johannes Schindelin","Franck Bui-Huu"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"26712","messageId":"7vk64bnnxl.fsf@assigned-by-dhcp.cox.net","threadId":"5535","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-11T02:21:10Z","receivedAt":"2006-09-11T02:21:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It's been two weeks since the last \"What's in\" update, so here\nis the current status.\n\n* The 'master' branch has these since the last announcement.\n\n - Andy Whitcroft spotted a long-standing bug that prevented \n send-pack to deal correctly with a ref whose name is longer\n than 45 bytes, where we did not have to have any such limit.\n\n - Jakub Narebski keeps working on gitweb, with help from Aneesh\n Kumar, Dennis Stosberg, Luben Tuikov, and Martin Waitz.\n There are a lot of clean-ups, including these notables:\n\n - mechanism to selectively enable or disable features by site\n administrators and repository owners.\n - snapshot and blame are now elective features using the above.\n - gitweb no longer uses temporary files to generate diffs.\n\n - Jakub also updated a few autoconf stuff.\n\n - Christian Couder's GIT_TRACE updates.\n\n - Franck Bui-Huu's clean-up to the code for \"format-patch -s\".\n\n - git-daemon acquired a mechanism to selectively enable or\n disable features by site administrators and repository\n owners.\n\n - pack-objects validates the data it copies from existing pack\n or new-style loose objects.\n\n - Other small clean-ups, fixes and updates from Johannes Schindelin,\n Jonas Fonseca, Linus Torvalds, Martin Langhoff, Matthias Kestenholz,\n Sergey Vlasov and Shawn Pearce.\n\n - gitk updates from Paul Mackerras.\n\n\n* The 'next' branch, in addition, has these.\n\n - Andy Whitcroft taught send-pack to use git-rev-list --stdin\n so that we do not have to be limited by the number of refs\n exec() command-line can hold.\n\n - Pasky's Git.pm is on hold; it was discussed and agreed that\n Git.xs layer was a bit premature and is hurting the adoption\n of the entire series.\n\n - Franck Bui-Huu and Rene Scharfe with a bit help from me added\n git-archive command to unify git-tar-tree/git-zip-tree and\n make them accessible over network.\n\n - Jeff King rewrote run_status() shell function in git-commit\n and git-status in C.\n\n - Per requests from the list, \"git apply\" automatically applies\n binary patches without having to be given --binary flag.\n\n - Likewise, \"git diff --binary\" does not give full index line for\n non-binary part of the patch anymore.\n\n - Pack-objects learned to run rev-list logic internally when\n given --revs parameter; the refs arguments you would normally\n give the upstream rev-list can be fed from its standard\n input, instead of usual list of objects.\n\n - Pack-objects also knows how to pretend objects that are in\n named packs are unpacked. This would make easy to update\n repack to incrementally pack loose objects and recent\n \"active\" pack(s).\n\n - I have a few patches to upload-pack that would help\n upload-pack when downloader has more roots than the uploader\n has, but this is frozen until I hear real-world feedback.\n\n - unpack-objects learned a trick not to stop when fed a corrupt\n pack; instead it can make the best effort to recover from\n such an error that was detected.\n\n\n* The 'pu' branch, in addition, has these.\n\n - I have a wip to implement index, working tree and zero or\n more trees in parallel but I haven't looked at it for some\n time.\n"},{"id":"26733","messageId":"ee3hac$n57$1@sea.gmane.org","threadId":"5535","inReplyTo":"7vk64bnnxl.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-11T11:29:19Z","receivedAt":"2006-09-11T11:29:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> - Andy Whitcroft taught send-pack to use git-rev-list --stdin\n> so that we do not have to be limited by the number of refs\n> exec() command-line can hold.\n[...]\n> - Pack-objects learned to run rev-list logic internally when\n> given --revs parameter; the refs arguments you would normally\n> give the upstream rev-list can be fed from its standard\n> input, instead of usual list of objects.\nBTW. could you please document the above?\n\nPerhaps those two options, --stdin to feed arguments from standard input,\nand -revs to run rev-list logic internally should be used whenever possible\nin all the git commands? This would allow to avoid forks and/or command\nline length limit.\n \nIn 'next' currently the following commands have --stdin implemented:\n * git-update-index: --stdin to feed list of paths, one per line\n * git-diff-tree: --stdin to loop over , or pairs of\n [*1*]\n * git-hash-object: --stdin is equivalent of '-' special file\n * git-http-fetch and git-local-fetch have some strange --stdin\n * git-name-rev with --stdin functions as filter\n * git-rev-list: --stdin to feed list of ; it is not clear from \n the manpage if one can use ^, and commit related options\n and shortcuts like --not, .., ...\nAnd the following have --revs implemented\n * git-pack-objects: --revs to provide arguments to rev-list from stdin,\n instead of list of objects. UNDOCUMENTED.\n\nIt would be nice if the following commands had --stdin or had it's --stdin\nusage extended:\n * git-diff-tree: --stdin to allow to provide path limits, separated \n by ' -- ' from or pair of (does git-diff-tree allow\n for diff3-like behavior? then perhaps also three )\n * git-ls-tree: --stdin to loop over , one tree per line.\n * git-cat-object: --stdin to loop over objects, plus -z to change separator\n between records to NULL (or have it turned on by default).\nFor all \"loop\" --stdin, the output should begin with the line which was\narguments, like git-diff-tree outputs first used for diff.\n\nI think it is quite often to use git-rev-list ...| git-diff-tree ...\npipeline, so it might be worth to add --revs option to git-diff-tree.\nOr it might not.\n\nP.S. does git-merge take -F option?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26737","messageId":"7v7j0ajrfh.fsf@assigned-by-dhcp.cox.net","threadId":"5535","inReplyTo":"ee3hac$n57$1@sea.gmane.org","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-11T16:31:30Z","receivedAt":"2006-09-11T16:31:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Perhaps those two options, --stdin to feed arguments from standard input,\n> and -revs to run rev-list logic internally should be used whenever possible\n> in all the git commands? This would allow to avoid forks and/or command\n> line length limit.\n\nSome make more sense than others, from usability point of view.\nIt all depends on how much sense it makes to be able to run them\non sequence of commits.\n\n> * git-rev-list: --stdin to feed list of ; it is not clear from \n> the manpage if one can use ^, and commit related options\n> and shortcuts like --not, .., ...\n> * git-pack-objects: --revs to provide arguments to rev-list from stdin,\n> instead of list of objects. UNDOCUMENTED.\n\nTime spent whining about it is better spent finding it out\nyourself (UTSL) and writing it I suspect. You'll learn how\nthings actually work while doing so ;-).\n\n> It would be nice if the following commands had --stdin or had it's --stdin\n> usage extended:\n> * git-diff-tree: --stdin to allow to provide path limits, separated \n> by ' -- ' from or pair of \n\nSomething like this could be used to follow renames and do more\ninteresting stuff. The caller would create a pair of pipes,\nthrow first tree-pair at it, receive and examine the output, and\ndecide what pathspec to use for the next one and continue. If\nyou do not limit yourself to pathspec but e.g. allow -S to be\nalso specified per invocation, then you can make it to follow\nline movements, not just renames. So in the bigger picture, I\nlike what something like this can offer to the Porcelain writers.\n\nIt is a separate story if it is worth building that _into_\ndiff-tree itself. A sane way to see if it is is to start by\nwriting a rough equivalent that is:\n\n\t#!/bin/sh\n\twhile read stuff;\n do\n\t\t# Note: this really needs to do shell quote\n \tgit-diff-tree $stuff\n\t\techo I am done with one record.\n done\n\nThen, write such a driver program to drive it and see if\nper-line invocation of diff-tree is really the bottleneck. For\nany useful and interesting application of this pattern, I\nsuspect the process that drives this diff-tree loop will have\nenough computation in it, and the only thing you are saving is\nthe start-up cost of diff-tree (i.e. fork+exec). I am not sure\nhow much of the bottleneck it would be in the while thing.\n\n> * git-ls-tree: --stdin to loop over , one tree per line.\n\nLikewise. Also you would need to decide the record delimiter.\n\n> * git-cat-object: --stdin to loop over objects, plus -z to change separator\n> between records to NULL (or have it turned on by default).\n\nI would suggest TYPE SP BYTE-COUNT LF followed by payload\ninstead. You cannot otherwise handle binary files with NUL\n(lesson of the day: NULL is a pointer, the character's name is\nNUL) in it. If you do not mind redundancy to help the consumer\nof this output, TYPE SP SHA-1 SP BYTE-COUNT LF followed by\npayload might even be a better choice.\n\n> For all \"loop\" --stdin, the output should begin with the line which was\n> arguments, like git-diff-tree outputs first used for diff.\n\nThat's something you cannot decide on a whim without knowing how\nthey are used and what convention is the most useful. I suspect\nthat single record delimiter without frill might turn out to be\nmore useful. Parrotting the arguments means you would need to\nmake sure the output format can easily parsable -- the issues\ninclude that you need deal with embedded newlines in them. To\nquote them in the output routine is easy but the consumer now\nneeds to know they need to be dequoted.\n\n> I think it is quite often to use git-rev-list ...| git-diff-tree ...\n> pipeline, so it might be worth to add --revs option to git-diff-tree.\n\nAre you talking about \"git rev-list | git diff-tree --stdin\"???\n\n> P.S. does git-merge take -F option?\n\nNo; it is not a Porcelain so ease of typing is not its goal.\nYou can say longhand: git-merge \"`cat $file`\" ...\nMerge messages are supposed to be mostly automated and short,\nso command line length limit is not much of an issue here.\n"},{"id":"26742","messageId":"ee4j3j$mli$1@sea.gmane.org","threadId":"5535","inReplyTo":"7v7j0ajrfh.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-11T21:06:03Z","receivedAt":"2006-09-11T21:06:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n>>  * git-rev-list: --stdin to feed list of ; it is not clear from \n>>    the manpage if one can use ^, and commit related options\n>>    and shortcuts like --not, .., ...\n>>  * git-pack-objects: --revs to provide arguments to rev-list from stdin,\n>>    instead of list of objects. UNDOCUMENTED.\n> \n> Time spent whining about it is better spent finding it out\n> yourself (UTSL) and writing it I suspect.  You'll learn how\n> things actually work while doing so ;-).\n\nI still think it is better, easier and faster for someone who makes a new\nfeature to document it too.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"26747","messageId":"20060911221411.GG23891@pasky.or.cz","threadId":"5535","inReplyTo":"ee4j3j$mli$1@sea.gmane.org","subject":"Re: What's in git.git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-11T22:14:12Z","receivedAt":"2006-09-11T22:14:12Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Sep 11, 2006 at 11:06:03PM CEST, I got a letter\nwhere Jakub Narebski said that...\n> Junio C Hamano wrote:\n> \n> >>  * git-rev-list: --stdin to feed list of ; it is not clear from \n> >>    the manpage if one can use ^, and commit related options\n> >>    and shortcuts like --not, .., ...\n> >>  * git-pack-objects: --revs to provide arguments to rev-list from stdin,\n> >>    instead of list of objects. UNDOCUMENTED.\n> > \n> > Time spent whining about it is better spent finding it out\n> > yourself (UTSL) and writing it I suspect.  You'll learn how\n> > things actually work while doing so ;-).\n> \n> I still think it is better, easier and faster for someone who makes a new\n> feature to document it too.\n\nEspecially since we _DON'T_ have good track record in other people\nquickly documenting newly introduced undocumented features.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nSnow falling on Perl. White noise covering line noise.\nHides all the bugs too. -- J. Putnam\n"},{"id":"26752","messageId":"7vwt8aezhc.fsf@assigned-by-dhcp.cox.net","threadId":"5535","inReplyTo":"20060911221411.GG23891@pasky.or.cz","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-11T23:48:47Z","receivedAt":"2006-09-11T23:48:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> Dear diary, on Mon, Sep 11, 2006 at 11:06:03PM CEST, I got a letter\n> where Jakub Narebski said that...\n>\n>> I still think it is better, easier and faster for someone who makes a new\n>> feature to document it too.\n>\n> Especially since we _DON'T_ have good track record in other people\n> quickly documenting newly introduced undocumented features.\n\nWell,...\n\nI miss the days the lead of this project had _me_ as a\ncontributor ;-).\n"},{"id":"26784","messageId":"7v7j08b92d.fsf_-_@assigned-by-dhcp.cox.net","threadId":"5535","inReplyTo":"ee3hac$n57$1@sea.gmane.org","subject":"[PATCH] pack-objects: document --revs, --unpacked and --all.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-13T05:59:54Z","receivedAt":"2006-09-13T05:59:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Signed-off-by: Junio C Hamano \n---\n\n * Clear enough?\n\n Documentation/git-pack-objects.txt | 21 ++++++++++++++++++++-\n builtin-pack-objects.c | 2 +-\n 2 files changed, 21 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt\nindex 4991f88..d4661dd 100644\n--- a/Documentation/git-pack-objects.txt\n+++ b/Documentation/git-pack-objects.txt\n@@ -11,7 +11,7 @@ SYNOPSIS\n [verse]\n 'git-pack-objects' [-q] [--no-reuse-delta] [--non-empty]\n \t[--local] [--incremental] [--window=N] [--depth=N]\n-\t{--stdout | base-name} < object-list\n+\t[--revs [--unpacked | --all]*] [--stdout | base-name] < object-list\n \n \n DESCRIPTION\n@@ -56,6 +56,24 @@ base-name::\n \tWrite the pack contents (what would have been written to\n \t.pack file) out to the standard output.\n \n+--revs::\n+\tRead the revision arguments from the standard input, instead of\n+\tindividual object names. The revision arguments are processed\n+\tthe same way as gitlink:git-rev-list[1] with `--objects` flag\n+\tuses its `commit` arguments to build the list of objects it\n+\toutputs. The objects on the resulting list are packed.\n+\n+--unpacked::\n+\tThis implies `--revs`. When processing the list of\n+\trevision arguments read from the standard input, limit\n+\tthe objects packed to those that are not already packed.\n+\n+--all::\n+\tThis implies `--revs`. In addition to the list of\n+\trevision arguments read from the standard input, pretend\n+\tas if all refs under `$GIT_DIR/refs` are specifed to be\n+\tincluded.\n+\n --window and --depth::\n \tThese two options affects how the objects contained in\n \tthe pack are stored using delta compression. The\n@@ -103,6 +121,7 @@ Documentation by Junio C Hamano\n \n See Also\n --------\n+gitlink:git-rev-list[1]\n gitlink:git-repack[1]\n gitlink:git-prune-packed[1]\n \ndiff --git a/builtin-pack-objects.c b/builtin-pack-objects.c\nindex 753dd9a..8d7a120 100644\n--- a/builtin-pack-objects.c\n+++ b/builtin-pack-objects.c\n@@ -15,7 +15,7 @@ #include \"list-objects.h\"\n #include \n #include \n \n-static const char pack_usage[] = \"git-pack-objects [-q] [--no-reuse-delta] [--non-empty] [--local] [--incremental] [--window=N] [--depth=N] {--stdout | base-name} [--revs [--unpacked | --all]* option.\n\n - Linus taught git-grep \"-h\" option to suppress filename\n output.\n\n - \"git-am --skip\" incorrectly insisted that its standard\n input to be connected to a tty. Fixed.\n\n - \"git-apply\" learned to handle --unified=0 patches more\n gracefully by allowing some sanity checks that cannot be\n done with such patches to be disabled.\n\n - Sasha Khapyorsky noticed that http-fetch commit walker can\n almost deal with ftp:// transport already, and added\n minimum updates to support it.\n\n\n* The 'next' branch, in addition, has these.\n\n - Git.pm is on hold, waiting for stripping out Git.xs part before\n going forward.\n\n - Linus introduced packed refs and taught the core about\n them. Christian Couder taught git-branch about them and\n Jeff King taught wt-status about it.\n\n There are still some things that are broken which need to\n be addressed before this series is pushed out to \"master\".\n I offhand know of these two but there probably are others:\n\n - \"git branch -d\" does not work.\n - \"git ls-remote rsync://\" does not work.\n\n - An experimental git-for-each-ref command to help language\n bindings to get information on many refs at once. Hopefully\n Jakub can teach gitweb to use it to speed things up.\n\n\n* The 'pu' branch, in addition, has these.\n\n - Jon Loeliger's git-daemon virtual hosting patch; this will be\n dropped and replaced with his updated version.\n\n - \"git log --author=foo\", \"git log --grep=pattern\" support.\n\n - I haven't started cleaning up the para-walk changes yet; they\n are still in the form of a messy 10-series patchset. When I\n find time I'd like to rewrite diff-index with it and see how\n well it performs.\n"},{"id":"27108","messageId":"eelbd2$56s$1@sea.gmane.org","threadId":"5535","inReplyTo":"7vu035u4c3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-18T05:39:29Z","receivedAt":"2006-09-18T05:39:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n>   - An experimental git-for-each-ref command to help language\n>     bindings to get information on many refs at once.  Hopefully\n>     Jakub can teach gitweb to use it to speed things up.\n\nI use 'origin' (or 'next') version of gitweb, while using _released_\nversion of git (git-core-1.4.2.1-1.i386.rpm). So at least for now \nI wouldn't be able to _test_ the git-for-each-ref.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27109","messageId":"eelbtu$56s$2@sea.gmane.org","threadId":"5535","inReplyTo":"7vu035u4c3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-18T05:48:29Z","receivedAt":"2006-09-18T05:48:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n>     We really need some test suites for gitweb.\n\nCould we use the git.git repository itself for testing gitweb?\nAt least checking if there are any errors or warnings?\n\nThe problem with test suite is that you really need _two_ tests;\nfirst if there are any errors or warnings, then if page looks like\nit should. The first can be done by simply running gitweb with\nat least the following enviromental variables set:\n export GATEWAY_INTERFACE=\"CGI/1.1\"\n export HTTP_ACCEPT=\"*/*\"\n export REQUEST_METHOD=\"GET\"\n export QUERY_STRING=\"\"$1\"\"\nThe second should be done by looking at gitweb output.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27112","messageId":"7vlkohu3j1.fsf@assigned-by-dhcp.cox.net","threadId":"5535","inReplyTo":"eelbd2$56s$1@sea.gmane.org","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-18T05:50:26Z","receivedAt":"2006-09-18T05:50:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>>   - An experimental git-for-each-ref command to help language\n>>     bindings to get information on many refs at once.  Hopefully\n>>     Jakub can teach gitweb to use it to speed things up.\n>\n> I use 'origin' (or 'next') version of gitweb, while using _released_\n> version of git (git-core-1.4.2.1-1.i386.rpm). So at least for now \n> I wouldn't be able to _test_ the git-for-each-ref.\n\nThat's not a good excuse, though. It means you cannot propose\nnew core-side support that only gitweb would benefit from\ninitially, since we will not add new stuff to the core that does\nnot have real users, and new stuff in the core must be cooked in\n\"next\" before it is proven to be useful and correct.\n"},{"id":"27116","messageId":"eeld1a$830$2@sea.gmane.org","threadId":"5535","inReplyTo":"7vlkohu3j1.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-09-18T06:07:21Z","receivedAt":"2006-09-18T06:07:21Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jakub Narebski writes:\n> \n>> Junio C Hamano wrote:\n>>\n>>>   - An experimental git-for-each-ref command to help language\n>>>     bindings to get information on many refs at once.  Hopefully\n>>>     Jakub can teach gitweb to use it to speed things up.\n>>\n>> I use 'origin' (or 'next') version of gitweb, while using _released_\n>> version of git (git-core-1.4.2.1-1.i386.rpm). So at least for now \n>> I wouldn't be able to _test_ the git-for-each-ref.\n> \n> That's not a good excuse, though. It means you cannot propose\n> new core-side support that only gitweb would benefit from\n> initially, since we will not add new stuff to the core that does\n> not have real users, and new stuff in the core must be cooked in\n> \"next\" before it is proven to be useful and correct.\n \nBut this also means that if I were for example to use git-for-each-ref\nin gitweb, I couldn't _test_ if it works. Ah, well, if you can live with\nPATCH/RFC... But I'd rather wait for git-for-each-ref in _released_ version\nof git. \n\nOn the other side as you said the true test for new core stuff is to use\nit. Perhaps someone who runs 'master' or 'next' version of git...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"27124","messageId":"Pine.LNX.4.63.0609181010500.19042@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5535","inReplyTo":"eeld1a$830$2@sea.gmane.org","subject":"Re: What's in git.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-18T08:11:42Z","receivedAt":"2006-09-18T08:11:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 18 Sep 2006, Jakub Narebski wrote:\n\n> Junio C Hamano wrote:\n> \n> > Jakub Narebski writes:\n> > \n> >> Junio C Hamano wrote:\n> >>\n> >>>   - An experimental git-for-each-ref command to help language\n> >>>     bindings to get information on many refs at once.  Hopefully\n> >>>     Jakub can teach gitweb to use it to speed things up.\n> >>\n> >> I use 'origin' (or 'next') version of gitweb, while using _released_\n> >> version of git (git-core-1.4.2.1-1.i386.rpm). So at least for now \n> >> I wouldn't be able to _test_ the git-for-each-ref.\n> > \n> > That's not a good excuse, though. It means you cannot propose\n> > new core-side support that only gitweb would benefit from\n> > initially, since we will not add new stuff to the core that does\n> > not have real users, and new stuff in the core must be cooked in\n> > \"next\" before it is proven to be useful and correct.\n> \n> But this also means that if I were for example to use git-for-each-ref\n> in gitweb, I couldn't _test_ if it works. Ah, well, if you can live with\n> PATCH/RFC... But I'd rather wait for git-for-each-ref in _released_ version\n> of git. \n\nWhy not set up a testing directory, where you use both gitweb _and_ git \nfrom next? It is easy...\n\nCiao,\nDscho\n"},{"id":"27126","messageId":"7vmz8xr3ij.fsf@assigned-by-dhcp.cox.net","threadId":"5535","inReplyTo":"Pine.LNX.4.63.0609181010500.19042@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-18T08:19:00Z","receivedAt":"2006-09-18T08:19:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> > That's not a good excuse, though. It means you cannot propose\n>> > new core-side support that only gitweb would benefit from\n>> > initially, since we will not add new stuff to the core that does\n>> > not have real users, and new stuff in the core must be cooked in\n>> > \"next\" before it is proven to be useful and correct.\n>> \n>> But this also means that if I were for example to use git-for-each-ref\n>> in gitweb, I couldn't _test_ if it works. Ah, well, if you can live with\n>> PATCH/RFC... But I'd rather wait for git-for-each-ref in _released_ version\n>> of git. \n>\n> Why not set up a testing directory, where you use both gitweb _and_ git \n> from next? It is easy...\n\nThat's Ok; it means that he just cannot work on certain things.\nIt's not like we take gitweb patch only from Jakub, so it is not\nthe end of the world either ;-).\n\nAlso it is handy to have somebody who sticks to things that are\navailable in master to catch breakage we might accidentally\ncause by Porcelainish commands jumping the gun before core-side\nchange hits the master branch.\n"},{"id":"27132","messageId":"450EABD0.1040102@innova-card.com","threadId":"5535","inReplyTo":"7vu035u4c3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Franck Bui-Huu","fromEmail":"vagabon.xyz@gmail.com","sentAt":"2006-09-18T14:23:12Z","receivedAt":"2006-09-18T14:23:12Z","isPatch":false,"sender":{"key":"vagabon.xyz@gmail.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> - Franck Bui-Huu and Rene Scharfe added 'git-archive' command,\n> that will eventually supersede 'git-tar-tree' and\n> 'git-zip-tree'.\n> \n\nI still have one issue, but haven't found out the solution yet.\nActually I even don't know if its related to 'archive/upload-archive'\ncommands. Could someone give it a try to tell me if he can at least\nreproduce it ?\n\nHere is the scenario (git-daemon and git-archive are executed on the\nsame machine):\n\ngit-daemon is started with the following command:\n\n$ git daemon --verbose --syslog --export-all \\\n --enable=upload-archive --base-path=/home/fbuihuu/tmp/ --reuseaddr\n\ngit-archive is run to archive a small repo located in ~/tmp/test-git.\nThis is done in an endless loop:\n\n$ while true; do\n> git archive --format=tar --remote=git://localhost/test-git HEAD | tar tf -\n> done\na\nb\na\nb\na\nb\na\nb\na\nb\na\nb\na\nb # stuck !!!\n\nSo after a couple of loops, git-archive is stuck waiting for git-daemon but\ndaemon seems to be stuck somewhere.\n\nSyslog shows something interesting here:\n\n[...]\nSep 18 16:11:42 25-fbuihuu git-daemon: [16549] Connection from 127.0.0.1:30373\nSep 18 16:11:42 25-fbuihuu git-daemon: [16549] Extended attributes (16 bytes) exist \nSep 18 16:11:42 25-fbuihuu git-daemon: [16549] Request upload-archive for '/test-git2'\nSep 18 16:11:42 25-fbuihuu git-upload-archive: finished\nSep 18 16:11:42 25-fbuihuu git-daemon: [16549] Disconnected\nSep 18 16:11:42 25-fbuihuu git-daemon: [16553] Connection from 127.0.0.1:30629\nSep 18 16:11:42 25-fbuihuu git-daemon: [16553] Extended attributes (16 bytes) exist \nSep 18 16:11:42 25-fbuihuu git-daemon: [16553] Request upload-archive for '/test-git2'\nSep 18 16:11:42 25-fbuihuu git-upload-archive: finished\n[END]\n\nIt looks like git-daemon never receives the SIGCHLD signal that is\nnormally sent by upload-archive once it has finished its job.\n\n\t\tFranck\n"},{"id":"27535","messageId":"7vd59lbldm.fsf@assigned-by-dhcp.cox.net","threadId":"5535","inReplyTo":"7vu035u4c3.fsf@assigned-by-dhcp.cox.net","subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-24T10:37:57Z","receivedAt":"2006-09-24T10:37:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"* The 'maint' branch has these fixes since the last announcement.\n\n t3403-rebase-skip failed when run while its standard input is\n connected to /dev/null. It turns out that an earlier safety\n check to prevent git-am to be fed a new patch while there is\n a leftover .dotest/ directory was incorrect. Fixed.\n\n There was an unnecessary xmalloc() in builtin-add. Removed.\n\n* The 'master' branch has these since the last announcement.\n\n Recent change to http-fetch.c did not play well with older\n curl releases. Fixed.\n\n Clean-up of gitweb continues. Notably, generation the\n summary page makes fewer call to git executable.\n\n Receive-pack has an added safety check that lets the\n repository owner to forbid non-fast-forward push into a\n shared repository by setting receive.denyNonFastforwards\n configuration variable.\n\n Output from git-describe can now be used as an abbreviated\n object name.\n\n git-resolve is now officially deprecated. The next \"master\"\n release (1.4.3) will ship with a version that gives an\n annoying \"deprecation warning\" message, and the command will\n be removed from the release after that.\n\n There was a build problem in upload-archive on OpenBSD. Fixed.\n\n git-zip-tree is now superseded by \"git-archive --format=zip\".\n\n Miscellaneous clean-ups and documentation updates.\n\n* The 'next' branch, in addition, has these.\n\n A new command git-show-ref was added to list and verify local\n references.\n\n A new command git-for-each-ref was added to help Porcelains\n to make smaller number of calls to git binary to obtain\n summary information for refs.\n\n cvsimport was updated to use git-for-each-ref.\n\n Git.pm topic lost Git.xs for now.\n\n The resolve_ref() internal API was straightened out to work\n solely on refname (i.e. string that begins with \"refs/\"),\n instead of pathnames. To deal with many refs efficiently,\n there is now a \"packed-ref\" format where many refs are stored\n in a single flat file instead of the traditional\n one-ref-per-file format.\n\n git-diff --color highlights trailing whitespaces and SP\n followed by TAB in indentation as common whitespace errors.\n\n git-daemon now has a virtual host support.\n\n upload-pack stops the fetch-pack on the other side when\n downloader has more roots than uploader; otherwise the\n downloader would send \"have\" from a development line that\n the uploader does not know about til its root.\n\n git-log learned --author=, --committer= and --grep= options\n to filter commits.\n\n pack-objects now creates version 3 packs; this allows a copy\n of larger block of data to be expressed.\n\n Per branch configuration items branch.\"branchname\".remote can\n specify what remotes/ file instead of usual \"origin\" should\n be used when no option is given to \"git fetch\" while on the\n named branch. Similarly, branch.\"branchname\".merge can\n specify which remote branches to be merged while on the named\n branch.\n\n git-svnimport learned a new trick to parse log message for\n Signed-off-by: lines and pick authorship information from\n there. I haven't heard Ack nor Nack from any subversion\n users, but we will hopefully hear somebody scream if it\n breaks things after pushing it out to \"master\".\n\n* The 'pu' branch, in addition, has these.\n\n git-apply --whitespace learned to notice SP before TAB in\n indent as a common whitespace error, in addition to the\n trailing whitespaces it already knew about.\n\n git-diff output is unfriendly to GNU patch when the filename\n contained a SP. Appending a TAB after filename in this case\n works the problem around. However, git-apply needs to learn\n about it as well, so it did.\n\n There is one new data type in the pack format that records\n delta base object by offset in the stream instead of 20-byte\n object name. This reduces the resulting packsize by 3 to 5%.\n\n One additional test for git-branch is in, but the current\n implementation of git-branch fails it.\n"}]}