{"thread":{"id":"1096","subject":"[ANNOUNCE] Cogito-0.12","startedAt":"2005-07-03T23:46:29Z","lastAt":"2005-07-12T04:48:40Z","messageCount":66,"participants":["Petr Baudis","Brian Gerst","Chris Wright","Junio C Hamano","Linus Torvalds","Eric W. Biederman","Tony Luck","Kevin Smith","Daniel Barkalow","Russell King","Sven Verdoolaege"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"5615","messageId":"20050703234629.GF13848@pasky.ji.cz","threadId":"1096","inReplyTo":null,"subject":"[ANNOUNCE] Cogito-0.12","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-03T23:46:29Z","receivedAt":"2005-07-03T23:46:29Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":" Hello,\n\n I'm happy to announce the release of the 0.12 version of the Cogito\nSCM-like layer over Linus' GIT tree history storage tool. Get it at\n\n\thttp://www.kernel.org/pub/software/scm/cogito/\n\nor cg-update if you have an older version cloned.\n\n I wanted to release it later with more cool features, but after all\nreleasing often is good and people will get to test things more, and\nI wanted to make it possible for kernel.org to upgrade to newer RPM.\nBut it may not be as stable as I'd wish and may have some rough edges,\nso be warned.\n\n This release contains the latest stuff from Linus, with all the\npacking stuff and everything. Other things include heaps of bugfixes,\nenhanced options parsing, ~/.cgrc support, cg-push, real cg-tag, and\nplenty of smaller but nice stuff. And more to come in next days!\n\n About cg-push, it:\n\n (i) works only locally or over git+ssh branches\n\n (ii) the head updated on the other side must be 'master' too\n\t(high priority to fix)\n\n (iii) the head updated on the other side is re-created, thus losing\n\tall attributes (ownership, permissions)\n\t(high priority to fix)\n\n (iv) won't update the remote working tree if there is any associated\n\twith the repository - do cg-cancel to catch up, but that will\n\tlose any local changes you did (note that I plan to rename\n\tcg-cancel to cg-reset)\n\n Also, I've deprecated rsync, as I explained in another mail. Use\ncg-branch-chg to change the branch URLs to some more sensible scheme -\nmost likely HTTP, or SSH if you want to push as well.\n\n Have fun,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5707","messageId":"42CBC822.30701@didntduck.org","threadId":"1096","inReplyTo":"20050703234629.GF13848@pasky.ji.cz","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Brian Gerst","fromEmail":"bgerst@didntduck.org","sentAt":"2005-07-06T12:01:38Z","receivedAt":"2005-07-06T12:01:38Z","isPatch":false,"sender":{"key":"bgerst@didntduck.org","avatar":null},"body":"Petr Baudis wrote:\n> Hello,\n> \n> I'm happy to announce the release of the 0.12 version of the Cogito\n> SCM-like layer over Linus' GIT tree history storage tool. Get it at\n> \n> \thttp://www.kernel.org/pub/software/scm/cogito/\n> \n> or cg-update if you have an older version cloned.\n> \n> I wanted to release it later with more cool features, but after all\n> releasing often is good and people will get to test things more, and\n> I wanted to make it possible for kernel.org to upgrade to newer RPM.\n> But it may not be as stable as I'd wish and may have some rough edges,\n> so be warned.\n> \n> This release contains the latest stuff from Linus, with all the\n> packing stuff and everything. Other things include heaps of bugfixes,\n> enhanced options parsing, ~/.cgrc support, cg-push, real cg-tag, and\n> plenty of smaller but nice stuff. And more to come in next days!\n> \n> About cg-push, it:\n> \n> (i) works only locally or over git+ssh branches\n> \n> (ii) the head updated on the other side must be 'master' too\n> \t(high priority to fix)\n> \n> (iii) the head updated on the other side is re-created, thus losing\n> \tall attributes (ownership, permissions)\n> \t(high priority to fix)\n> \n> (iv) won't update the remote working tree if there is any associated\n> \twith the repository - do cg-cancel to catch up, but that will\n> \tlose any local changes you did (note that I plan to rename\n> \tcg-cancel to cg-reset)\n> \n> Also, I've deprecated rsync, as I explained in another mail. Use\n> cg-branch-chg to change the branch URLs to some more sensible scheme -\n> most likely HTTP, or SSH if you want to push as well.\n\nI really question removing rsync before HTTP pulls become more \neffecient. I did a complete pull of cogito from kernel.org, and http \ntook over 50 minutes to pull everything, while rsync was done in just \nover 1 minute. I dared not even try to pull the full kernel at that speed.\n\nI suspect that part of the problem is that the pull methods are doing a \ndepth first search, so we can't request the next object until the \ncurrent object is fully received and parsed. Changing to a breadth \nfirst search would allow multiple requests in flight and asynchronous \nprocessing which should speed things up. I am exploring using the \ncurl_multi_* functions to do this, but this will require changes to \ncommon code in pull.c.\n\n--\n\t\t\t\tBrian Gerst\n"},{"id":"5758","messageId":"20050707062230.GM5324@shell0.pdx.osdl.net","threadId":"1096","inReplyTo":"20050703234629.GF13848@pasky.ji.cz","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Chris Wright","fromEmail":"chrisw@osdl.org","sentAt":"2005-07-07T06:22:30Z","receivedAt":"2005-07-07T06:22:30Z","isPatch":false,"sender":{"key":"chrisw@sous-sol.org","avatar":null},"body":"* Petr Baudis (pasky@suse.cz) wrote:\n> I'm happy to announce the release of the 0.12 version of the Cogito\n> SCM-like layer over Linus' GIT tree history storage tool. Get it at\n> \n> \thttp://www.kernel.org/pub/software/scm/cogito/\n\nRPMs uploading to:\n\thttp://www.kernel.org/pub/software/scm/cogito/RPMS\n\nthanks,\n-chris\n"},{"id":"5761","messageId":"20050707144501.GG19781@pasky.ji.cz","threadId":"1096","inReplyTo":"42CBC822.30701@didntduck.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-07T14:45:01Z","receivedAt":"2005-07-07T14:45:01Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Wed, Jul 06, 2005 at 02:01:38PM CEST, I got a letter\nwhere Brian Gerst told me that...\n> Petr Baudis wrote:\n> > Also, I've deprecated rsync, as I explained in another mail. Use\n> >cg-branch-chg to change the branch URLs to some more sensible scheme -\n> >most likely HTTP, or SSH if you want to push as well.\n> \n> I really question removing rsync before HTTP pulls become more \n> effecient.\n\nIt won't happen. Or rather, I hope the HTTP pulls become more efficient\nsoon. Actually, perhaps Linus has something done already, my workstation\nis a bit derailed now so I couldn't pull from him in the last few days\n(hopefully will sort that out today).\n\n> I did a complete pull of cogito from kernel.org, and http \n> took over 50 minutes to pull everything, while rsync was done in just \n> over 1 minute. I dared not even try to pull the full kernel at that speed.\n> \n> I suspect that part of the problem is that the pull methods are doing a \n> depth first search, so we can't request the next object until the \n> current object is fully received and parsed. Changing to a breadth \n> first search would allow multiple requests in flight and asynchronous \n> processing which should speed things up. I am exploring using the \n> curl_multi_* functions to do this, but this will require changes to \n> common code in pull.c.\n\nHmm, yes, I guess Linus won't be touching the HTTP backend at all. ;-) I\nsuggest you to check the last development in Linus' branch and sync with\nDaniel Barkalow, who promised improving the pull tools as well.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5766","messageId":"7vk6k2sfa4.fsf@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"20050707144501.GG19781@pasky.ji.cz","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-07T17:21:39Z","receivedAt":"2005-07-07T17:21:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"PB\" == Petr Baudis writes:\n\nPB> It won't happen. Or rather, I hope the HTTP pulls become more efficient\nPB> soon. Actually, perhaps Linus has something done already, my workstation\nPB> is a bit derailed now so I couldn't pull from him in the last few days\nPB> (hopefully will sort that out today).\n\nPB> Hmm, yes, I guess Linus won't be touching the HTTP backend at all. ;-) I\nPB> suggest you to check the last development in Linus' branch and sync with\nPB> Daniel Barkalow, who promised improving the pull tools as well.\n\nIf this weekend is not too late, I have been brewing what is\ncalled an \"efficient pull from dumb servers\" suite, which would\nhopefully fill this gap. I am still in the process of finishing\nthe details, but basically it already seems to work.\n\nLinus, please drop the patch I sent you earlier, privately by\nmistake not CCing the list, that implemented only the server\nend. I've changed some file formats already from that one.\n\nThe outline of how it works is like this.\n\n * I assume a dumb transport (read: static files only HTTP\n server) and no on-request server side processing. All the\n smarts must go in the client. The server side X.git being an\n ordinary GIT archive (no need for files in the work tree),\n plus:\n\n - X.git/objects/pack can have packed GIT archives. I\n envision that this will be a series of 5 to 20 MB packs,\n occasionally adding a new incremental pack when\n X.git/objects/??/ directories accumulate enough standalone\n SHA1 files. It is not necessary to have X.git/objects/??/\n files if an object is contained in one of the packs.\n\n - X.git/info/ has three extra files.\n\n - \"inventory\" lists all the branches stored in X.git/refs\n and looks like this (contents and path):\n\n ff83c8f3554ceb444b413beaeb49b4a781dae944 snap/0\n 013e7c7ff498aae82d799f80da37fbd395545456 snap/10\n ff83c8f3554ceb444b413beaeb49b4a781dae944 heads/master\n dd7ba8b4949535c24e604a37709db0e3be9ccbbc heads/linus\n\n This is to facilitate discovery from a transport that is\n not so \"ls\" friendly, like HTTP.\n\n - \"pack\" lists available packs under X.git/objects/pack and\n looks like this (size and name):\n\n 432495 pk-65fe69e9bc2e8a3e0881e008dde182522156ba7c.pack\n\n The file is there for discovery. The size is used by the\n client to discover optimum set of packs to slurp.\n\n - \"rev-cache\" is a binary file that describes commit\n ancestry information in a dense format. It lists all\n commits available from this repository along with who\n its parents are for each of the commit. This file is\n produced append-only, so that the server side can use\n rsync based mirroring scheme.\n\n A new command \"git-update-dumb-server\" is used to prepare\n these three files. There may need a helper script that uses\n git-pack-objects and friends to prepare packs partitioned to\n allow pulling a popular branch efficiently.\n\n * The client side is called \"git-dumb-pull-script\". This\n downloads the above three files, and .idx files associated\n with packs described in \"pack\". With the information in\n \"inventory\" about desired branch to pull from along with\n \"rev-cache\" ancestry information, it discovers the set of\n commits that is lacking from its local store. By comparing\n that list with downloaded .idx files, along with size\n information for each pack, it comes up a list of packs to\n download to cover the most commits that it wants to obtain,\n and downloads them, verifies them and stores them in its\n .git/objects/pack/ directory.\n\n The above process of downloading packs would typically not\n cover all the things lacking, because some new commits may\n not be in any of the packs. After this point, the usual\n commit-walking git-http-pull can be used to fill the rest,\n and it does not have to pull that many objects. Dan's\n http-pull parallelism improvement would be very useful\n independently here.\n"},{"id":"5774","messageId":"Pine.LNX.4.58.0507071158220.3293@g5.osdl.org","threadId":"1096","inReplyTo":"7vk6k2sfa4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-07T19:04:58Z","receivedAt":"2005-07-07T19:04:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Junio C Hamano wrote:\n> \n> - X.git/objects/pack can have packed GIT archives. I\n> envision that this will be a series of 5 to 20 MB packs,\n> occasionally adding a new incremental pack when\n> X.git/objects/??/ directories accumulate enough standalone\n> SHA1 files. It is not necessary to have X.git/objects/??/\n> files if an object is contained in one of the packs.\n\nNote that I just re-packed the kernel archive on kernel.org, and removed \n_all_ unpacked files. Once that percolates to the mirrors, the http \nprotocol will be useless without anything like this.\n\nThat said, I really think the dumb protocols are useless anyway. No other \nsystem supports pure static object pulling anyway, and as far as I'm \nconcerned, I want \"rsync\" to kind of work (but it won't be optimal, since \nre-packing will delete all the old objects and replace it with the new \npack that is downloaded anew). But plain http? I'm not convinced.\n\nI'd much rather have a \"stupid server\" that just listens to a port, and\nbasically forks off and executes \"git-upload-pack\" when it's connected to\n(perhaps reading the directory name first). Nothing else. Then we can do \na security analysis of upload-pack, which should be fairly easy since it's \nnot actually ever _writing_ anything.\n\nAt that point, you can do\n\n\tgit pull git://www.kernel.org/pub/scm/git/..\n\nand it would just connect to some default \"git port\", pass off the \ndirectory name, and be done with it - exact same discovery protocol that \nnow use for ssh. And \"git clone\" would also automatically work.\n\n\t\tLinus\n"},{"id":"5771","messageId":"7vbr5ejso2.fsf@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071158220.3293@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-07T19:57:17Z","receivedAt":"2005-07-07T19:57:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I have two questions on \"rev-list --objects\".\n\n(1) Would it make sense to have an extra flag to \"rev-list\n --objects\" to make it list all the objects reachable from\n commits listed in its output, even when some of them are\n unchanged from UNINTERESTING commits? Right now, a pack\n produced from \"rev-list --objects A ^B\" does not have enough\n information to reproduce the tree associated with commit A.\n\n(2) When \"showing --objects\", it lists the top-level tree node\n with no name, which makes it indistinguishable from commit\n objects by pack-objects, probably impacting the delta logic.\n Would something like the following patch make sense, to name\n such node \".\"; giving full-path not just the basename to\n all named nodes would be even better, though.\n\n---\n# - master: git-format-patch: Prepare patches for e-mail submission.\n# + (working tree)\ndiff --git a/rev-list.c b/rev-list.c\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -179,7 +179,10 @@ static void show_commit_list(struct comm\n \t\tdie(\"unknown pending object %s (%s)\", sha1_to_hex(obj->sha1), name);\n \t}\n \twhile (objects) {\n-\t\tprintf(\"%s %s\\n\", sha1_to_hex(objects->item->sha1), objects->name);\n+\t\tconst char *name = objects->name;\n+\t\tif (!*name && objects->item->type == tree_type)\n+\t\t\tname = \".\";\n+\t\tprintf(\"%s %s\\n\", sha1_to_hex(objects->item->sha1), name);\n \t\tobjects = objects->next;\n \t}\n }\n"},{"id":"5772","messageId":"7v3bqqjsj6.fsf@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071158220.3293@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-07T20:00:13Z","receivedAt":"2005-07-07T20:00:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> ... No other \nLT> system supports pure static object pulling anyway,...\n\nThat is true, but on the other hand, no other system is easier\nto be deployed by mere mortals on barebone ISP accounts.\n"},{"id":"5781","messageId":"m1vf3muwxw.fsf@ebiederm.dsl.xmission.com","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071158220.3293@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-07T21:29:31Z","receivedAt":"2005-07-07T21:29:31Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> That said, I really think the dumb protocols are useless anyway. No other \n> system supports pure static object pulling anyway, and as far as I'm \n> concerned, I want \"rsync\" to kind of work (but it won't be optimal, since \n> re-packing will delete all the old objects and replace it with the new \n> pack that is downloaded anew). But plain http? I'm not convinced.\n\nHave you not looked at tla/arch? tla does supports dumb servers.\nIt's job is a little easier as it has one file per atomic commit\nI suspect once packs start working well that should not be an\nissue for git either.\n\nFor small projects this is a major benefit, as they can just push\ntheir files to a convenient http or ftp server.\n\n> I'd much rather have a \"stupid server\" that just listens to a port, and\n> basically forks off and executes \"git-upload-pack\" when it's connected to\n> (perhaps reading the directory name first). Nothing else. Then we can do \n> a security analysis of upload-pack, which should be fairly easy since it's \n> not actually ever _writing_ anything.\n>\n> At that point, you can do\n>\n> \tgit pull git://www.kernel.org/pub/scm/git/..\n>\n> and it would just connect to some default \"git port\", pass off the \n> directory name, and be done with it - exact same discovery protocol that \n> now use for ssh. And \"git clone\" would also automatically work.\n\nFor optimizing network bandwidth that sounds like the way to go. For\nadhoc development I don't know. For a central sever you still need\nan authenticated way to push content, which makes it another dimension\nof the problem. So it is mostly a question of what is the sanest way\nto mirror/publish data. http is used a lot for publishing data and\npractically everyone has access to a http server that can host\ncontent, so I think supporting http makes git a lot more accessible\nto people. The only thing more accessible seems to be email, and\nemail is terrible for publish small projects.\n\nEric\n"},{"id":"5777","messageId":"Pine.LNX.4.58.0507071456570.25104@g5.osdl.org","threadId":"1096","inReplyTo":"7vbr5ejso2.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-07T21:58:56Z","receivedAt":"2005-07-07T21:58:56Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Junio C Hamano wrote:\n> \n> (1) Would it make sense to have an extra flag to \"rev-list\n> --objects\" to make it list all the objects reachable from\n> commits listed in its output, even when some of them are\n> unchanged from UNINTERESTING commits? Right now, a pack\n> produced from \"rev-list --objects A ^B\" does not have enough\n> information to reproduce the tree associated with commit A.\n\nWell, that would certainly be possible. Just having a flag that disables \n\"mark_tree_uninteresting()\" would do it.\n\n> (2) When \"showing --objects\", it lists the top-level tree node\n> with no name, which makes it indistinguishable from commit\n> objects by pack-objects, probably impacting the delta logic.\n> Would something like the following patch make sense, to name\n> such node \".\"; giving full-path not just the basename to\n> all named nodes would be even better, though.\n\nIt doesn't impact the delta algorithm, because the objects are sorted by \ntype first, so it never mixes up trees and commits.\n\nBut if you wanted to, something like this would be cleaner than your \nsuggestion..\n\n\t\tLinus\n\ndiff --git a/rev-list.c b/rev-list.c\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -154,7 +154,7 @@ static void show_commit_list(struct comm\n \twhile (list) {\n \t\tstruct commit *commit = pop_most_recent_commit(&list, SEEN);\n \n-\t\tp = process_tree(commit->tree, p, \"\");\n+\t\tp = process_tree(commit->tree, p, \"tree\");\n \t\tif (process_commit(commit) == STOP)\n \t\t\tbreak;\n \t}\n@@ -386,7 +386,7 @@ static struct commit *get_commit_referen\n \t\t\tmark_tree_uninteresting(tree);\n \t\t\treturn NULL;\n \t\t}\n-\t\tadd_pending_object(object, \"\");\n+\t\tadd_pending_object(object, \"tree\");\n \t\treturn NULL;\n \t}\n \n@@ -401,7 +401,7 @@ static struct commit *get_commit_referen\n \t\t\tmark_blob_uninteresting(blob);\n \t\t\treturn NULL;\n \t\t}\n-\t\tadd_pending_object(object, \"\");\n+\t\tadd_pending_object(object, \"blob\");\n \t\treturn NULL;\n \t}\n \tdie(\"%s is unknown object\", name);\n"},{"id":"5778","messageId":"7vslyqp8sm.fsf@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071456570.25104@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-07T22:10:01Z","receivedAt":"2005-07-07T22:10:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\n>> (2) When \"showing --objects\", it lists the top-level tree node\n>> with no name, which makes it indistinguishable from commit\n>> objects by pack-objects, probably impacting the delta logic.\n>> Would something like the following patch make sense, to name\n>> such node \".\"; giving full-path not just the basename to\n>> all named nodes would be even better, though.\n\nLT> It doesn't impact the delta algorithm, because the objects are sorted by \nLT> type first, so it never mixes up trees and commits.\n\nYou are correct. I forgot that it does sorting by type.\n\nWhat do you think about giving full-path so that Makefiles in\ndifferent directories would get different name hashes?\n"},{"id":"5779","messageId":"20050707221443.GB7151@pasky.ji.cz","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071158220.3293@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-07T22:14:44Z","receivedAt":"2005-07-07T22:14:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Let me join the sceptics camp. :-)\n\nDear diary, on Thu, Jul 07, 2005 at 09:04:58PM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> Note that I just re-packed the kernel archive on kernel.org, and removed \n> _all_ unpacked files. Once that percolates to the mirrors, the http \n> protocol will be useless without anything like this.\n\n*grumble*\n\nSo, what _is_ then the way to pull now, actually? If we use rsync, won't\nwe end up with having the objects we previous had twice now?\n\n> That said, I really think the dumb protocols are useless anyway. No other \n> system supports pure static object pulling anyway, and as far as I'm \n> concerned, I want \"rsync\" to kind of work (but it won't be optimal, since \n> re-packing will delete all the old objects and replace it with the new \n> pack that is downloaded anew). But plain http? I'm not convinced.\n\nYou can always just spider the repository which will work just as well\nas rsync in the git case. ;-)\n\nI think it would be actually simplest (for the user) to have a trivial\nCGI script on the other side which will do the git-upload-pack stuff.\nMinimal extra administrative overhead, flexibility, works through\nproxies, and stuff. People can rewrite it in Perl or PHorridP if they\nwish and use it on webhosting servers not allowing much else.\n\nThat's not to say a dedicated server wouldn't have its place too, and\nthat's what's now probably simplest for us. ;-)\n\nNow we are in a situation when there's actually no way to pull from your\nkernel repository without throwing own repository to mess and\nduplicating data, AFAICS.\n\n> I'd much rather have a \"stupid server\" that just listens to a port, and\n> basically forks off and executes \"git-upload-pack\" when it's connected to\n> (perhaps reading the directory name first). Nothing else. Then we can do \n> a security analysis of upload-pack, which should be fairly easy since it's \n> not actually ever _writing_ anything.\n> \n> At that point, you can do\n> \n> \tgit pull git://www.kernel.org/pub/scm/git/..\n> \n> and it would just connect to some default \"git port\", pass off the \n> directory name, and be done with it - exact same discovery protocol that \n> now use for ssh. And \"git clone\" would also automatically work.\n\nEek. Could you please make it at least pretend to be extensible? Compare\ngit-upload-pack with git-ssh-pu* - the second one prepends letters to\nthe data it sends so that if you add a new type of stuff to send (say\nfor authentication or some smart tags stuff), you could extend it in a\nsensible way. What about dividing the communication to \"blocks\"\nseparated by a newline? Each block would have its first word on the\nfirst line saying what kind of block it is - \"refs\", \"have\", \"want\", or\n\"pack\" (for simplicity, the pack block might have additional restriction\nthat it's always the last one). If you hit unknown block, you should\nrespond back by something like \"huh\" and ignore the rest of it.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5782","messageId":"Pine.LNX.4.58.0507071520220.25104@g5.osdl.org","threadId":"1096","inReplyTo":"m1vf3muwxw.fsf@ebiederm.dsl.xmission.com","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-07T22:23:11Z","receivedAt":"2005-07-07T22:23:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Eric W. Biederman wrote:\n>\n> For optimizing network bandwidth that sounds like the way to go. For\n> adhoc development I don't know. For a central sever you still need\n> an authenticated way to push content, which makes it another dimension\n> of the problem.\n\nI'm convinced that \"ssh\" is the only sane way for pushing. If you don't \ntrust somebody enough to give him ssh access, you shouldn't trust him with \nwrite access to your project in the first place.\n\ngit can actually do ssh with a _very_ restricted shell, if people are \nworried about shell access. In fact, the _only_ think the shell needs to \nbe able to do is execute one of two programs, so you could have something \n_really_ trivial in your /etc/passwd as the login shell that doesn't allow \nanything else. But you'd still use ssh as the authentication protocol.\n\nSo I don't worry about pushing. I think we've got that covered. It's \nreally the anonymous pulling that needs something.\n\n\t\tLinus\n"},{"id":"5784","messageId":"Pine.LNX.4.58.0507071549330.25104@g5.osdl.org","threadId":"1096","inReplyTo":"20050707221443.GB7151@pasky.ji.cz","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-07T22:52:28Z","receivedAt":"2005-07-07T22:52:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 8 Jul 2005, Petr Baudis wrote:\n\n> Let me join the sceptics camp. :-)\n> \n> Dear diary, on Thu, Jul 07, 2005 at 09:04:58PM CEST, I got a letter\n> where Linus Torvalds told me that...\n> > Note that I just re-packed the kernel archive on kernel.org, and removed \n> > _all_ unpacked files. Once that percolates to the mirrors, the http \n> > protocol will be useless without anything like this.\n> \n> *grumble*\n> \n> So, what _is_ then the way to pull now, actually? If we use rsync, won't\n> we end up with having the objects we previous had twice now?\n\nRsync works fine. You can either unpack the pack you get, or, if you \nprefer, just run\n\n\tgit-prune-packed\n\nwhich will remove the stand-alone object that it finds in packs. Now \nyou're no longer duplicating data, and your repository is smaller than it \nused to be anyway.\n\nOf course, that requires that you trust the packs 100%. It seems to be \nstable, and I've packed the whole kernel repo, but I actually keep my \nprivate tree unpacked still just in case.\n\n> I think it would be actually simplest (for the user) to have a trivial\n> CGI script on the other side which will do the git-upload-pack stuff.\n\nWell, git-upload-pack expects the other end to follow the proper protocol, \nbut yes, you can certainly expose it through a web interface and a \nspecialized client that way.\n\n\t\tLinus\n"},{"id":"5786","messageId":"7vll4ifbq8.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071549330.25104@g5.osdl.org","subject":"[PATCH] Pull efficiently from a dumb git store.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-07T23:16:47Z","receivedAt":"2005-07-07T23:16:47Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The git-update-dumb-server-script command statically prepares\nadditional information to describe what the server side has, so\nthat a smart client can pull things efficiently even via a\ntransport such as static-file-only HTTP.\n\nThe files prepared by the command is $GIT_DIR/info/server, which\nis a tar archive that contains the following files:\n\n rev-cache -- commit ancestry chain, append only to help\n\t rsync mirroring.\n inventory -- list of refs and their SHA1.\n pack -- list of available prepackaged packs.\n server.sha1 -- sha1sum output for the above three files (optional).\n\nA smart client git-dumb-pull-script works in the following way:\n\n - First it slurps these files, and then .idx files that\n corresponds to the packs described in \"pack\".\n\n - Then it finds the commits that it wants from the server by\n looking at \"inventory\" to find various heads, and \"rev-cache\" to\n find commits that is missing from the client, and \"pack\" to\n figure out downloading which packs is the most efficient way to\n fill what is missing from its repository. This is done with\n the help of the git-dumb-pull-resolve command.\n\n - Then it slurps the pack files.\n\n - The git-http-pull / git-local-pull command walks the commit\n chain in an old-fashioned way and downloads unpacked objects\n to fill the rest.\n\nSigned-off-by: Junio C Hamano \n---\n\n Makefile | 10 +\n dumb-pull-resolve.c | 239 +++++++++++++++++++++++++++++++++\n git-dumb-pull-script | 129 ++++++++++++++++++\n git-update-dumb-server-script | 47 ++++++\n rev-cache.c | 300 +++++++++++++++++++++++++++++++++++++++++\n rev-cache.h | 31 ++++\n show-rev-cache.c | 18 ++\n update-dumb-server.c | 153 +++++++++++++++++++++\n 8 files changed, 925 insertions(+), 2 deletions(-)\n create mode 100644 dumb-pull-resolve.c\n create mode 100755 git-dumb-pull-script\n create mode 100755 git-update-dumb-server-script\n create mode 100644 rev-cache.c\n create mode 100644 rev-cache.h\n create mode 100644 show-rev-cache.c\n create mode 100644 update-dumb-server.c\n\na880bc7300f070aca3a255828b48390cb9793245\ndiff --git a/Makefile b/Makefile\n--- a/Makefile\n+++ b/Makefile\n@@ -31,7 +31,8 @@ SCRIPTS=git git-apply-patch-script git-m\n \tgit-fetch-script git-status-script git-commit-script \\\n \tgit-log-script git-shortlog git-cvsimport-script git-diff-script \\\n \tgit-reset-script git-add-script git-checkout-script git-clone-script \\\n-\tgitk git-cherry git-rebase-script git-relink-script git-repack-script\n+\tgitk git-cherry git-rebase-script git-relink-script git-repack-script \\\n+\tgit-dumb-pull-script git-update-dumb-server-script\n \n PROG= git-update-cache git-diff-files git-init-db git-write-tree \\\n \tgit-read-tree git-commit-tree git-cat-file git-fsck-cache \\\n@@ -44,7 +45,8 @@ PROG= git-update-cache git-diff-files \n \tgit-diff-stages git-rev-parse git-patch-id git-pack-objects \\\n \tgit-unpack-objects git-verify-pack git-receive-pack git-send-pack \\\n \tgit-prune-packed git-fetch-pack git-upload-pack git-clone-pack \\\n-\tgit-show-index\n+\tgit-show-index git-update-dumb-server git-show-rev-cache \\\n+\tgit-dumb-pull-resolve\n \n all: $(PROG)\n \n@@ -58,6 +60,9 @@ LIB_FILE=libgit.a\n LIB_H=cache.h object.h blob.h tree.h commit.h tag.h delta.h epoch.h csum-file.h \\\n \tpack.h pkt-line.h refs.h\n \n+LIB_H += rev-cache.h\n+LIB_OBJS += rev-cache.o\n+\n LIB_H += strbuf.h\n LIB_OBJS += strbuf.o\n \n@@ -153,6 +158,7 @@ object.o: $(LIB_H)\n read-cache.o: $(LIB_H)\n sha1_file.o: $(LIB_H)\n usage.o: $(LIB_H)\n+rev-cache.o: $(LIB_H)\n strbuf.o: $(LIB_H)\n gitenv.o: $(LIB_H)\n entry.o: $(LIB_H)\ndiff --git a/dumb-pull-resolve.c b/dumb-pull-resolve.c\nnew file mode 100644\n--- /dev/null\n+++ b/dumb-pull-resolve.c\n@@ -0,0 +1,239 @@\n+#include \"cache.h\"\n+#include \"rev-cache.h\"\n+\n+static const char *dumb_pull_resolve_usage =\n+\"git-dumb_pull_resolve ( )...\";\n+\n+static struct inventory {\n+\tstruct inventory *next;\n+\tunsigned char sha1[20];\n+\tchar name[1]; /* more; 1 is for terminating NUL */\n+} *inventory;\n+\n+static struct inventory *find_inventory(const char *name)\n+{\n+\tstruct inventory *e = inventory;\n+\twhile (e && strcmp(e->name, name))\n+\t\te = e->next;\n+\treturn e;\n+}\n+\n+static void read_inventory(const char *path)\n+{\n+\tFILE *fp;\n+\tchar buf[1024];\n+\n+\tfp = fopen(path, \"r\");\n+\tif (!fp)\n+\t\tdie(\"cannot open %s\", path);\n+\twhile (fgets(buf, sizeof(buf), fp)) {\n+\t\tstruct inventory *e; \n+\t\tint len = strlen(buf);\n+\t\tif (buf[len-1] != '\\n')\n+\t\t\tdie(\"malformed inventory file\");\n+\t\tbuf[--len] = 0;\n+\t\te = xmalloc(sizeof(*e) + len - 41);\n+\t\tstrcpy(e->name, buf + 41);\n+\t\tget_sha1_hex(buf, e->sha1);\n+\t\te->next = inventory;\n+\t\tinventory = e;\n+\t}\n+\tfclose(fp);\n+}\n+\n+#define MAX_PACKS 0\n+static struct pack {\n+\tstruct pack *next;\n+\tunsigned int *map;\n+\tunsigned long pack_size;\n+\tunsigned long index_size;\n+\tunsigned char ix;\n+\tunsigned long fill;\n+\tchar name[1]; /* more; 1 is for terminating NUL */\n+} *pack;\n+\n+static void map_pack_idx(const char *path, const char *tmpdir)\n+{\n+\tFILE *fp;\n+\tchar buf[1024];\n+\tint num_pack = 0;\n+\n+\tfp = fopen(path, \"r\");\n+\tif (!fp)\n+\t\tdie(\"cannot open %s\", path);\n+\twhile (fgets(buf, sizeof(buf), fp)) {\n+\t\tstruct pack *e;\n+\t\tint len;\n+\t\tint fd;\n+\t\tstruct stat st;\n+\t\tchar path[PATH_MAX];\n+\t\tchar *cp;\n+\n+\t\tcp = strchr(buf, ' ');\n+\t\tif (!cp || !*++cp)\n+\t\t\tdie(\"malformed pack file\");\n+\n+\t\tlen = strlen(cp);\n+\t\tif (cp[len-1] != '\\n')\n+\t\t\tdie(\"malformed pack file\");\n+\t\tcp[--len] = 0;\n+\t\t\n+\t\tif (MAX_PACKS && MAX_PACKS < num_pack) {\n+\t\t\terror(\"cannot handle too many packs. ignoring %s\",\n+\t\t\t cp);\n+\t\t\tcontinue;\n+\t\t}\n+\n+\t\te = xmalloc(sizeof(*e) + len);\n+\t\tstrcpy(e->name, cp);\n+\t\te->pack_size = strtoul(buf, NULL, 10);\n+\n+\t\tsprintf(path, \"%s/%s\", tmpdir, cp);\n+\t\tlen = strlen(path);\n+\t\tstrcpy(path + len - 5, \".idx\");\n+\t\tfd = open(path, O_RDONLY);\n+\t\tif (fd < 0)\n+\t\t\tgoto ignore_entry;\n+\t\tif (fstat(fd, &st)) {\n+\t\t\tclose(fd);\n+\t\t\tgoto ignore_entry;\n+\t\t}\n+\t\te->index_size = st.st_size;\n+\t\te->map = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);\n+\t\tclose(fd);\n+\t\tif (e->map == MAP_FAILED)\n+\t\t\tdie(\"cannot map %s\", path);\n+\t\te->next = pack;\n+\t\te->ix = num_pack++;\n+\t\tpack = e;\n+\t\tcontinue;\n+\tignore_entry:\n+\t\tfree(e);\n+\t}\n+\tfclose(fp);\n+}\n+\n+static int find_in_pack_idx(const unsigned char *sha1, struct pack *e)\n+{\n+\tunsigned int *level1_ofs = e->map;\n+\tint hi = ntohl(level1_ofs[*sha1]);\n+\tint lo = ((*sha1 == 0x0) ? 0 : ntohl(level1_ofs[*sha1 - 1]));\n+\tvoid *index = e->map + 256;\n+\n+\tdo {\n+\t\tint mi = (lo + hi) / 2;\n+\t\tint cmp = memcmp(index + 24 * mi + 4, sha1, 20);\n+\t\tif (!cmp)\n+\t\t\treturn 1;\n+\t\tif (0 < cmp)\n+\t\t\thi = mi;\n+\t\telse\n+\t\t\tlo = mi+1;\n+\t} while (lo < hi);\n+\treturn 0;\n+}\n+\n+static void mark_needed(const unsigned char *sha1)\n+{\n+\tstruct rev_cache *rc;\n+\tstruct rev_list_elem *rle;\n+\tint pos;\n+\n+\tif (has_sha1_file(sha1))\n+\t\treturn;\n+\tpos = find_rev_cache(sha1);\n+\tif (pos < 0)\n+\t\tdie(\"rev-cache does not match inventory\");\n+\trc = rev_cache[pos];\n+\trc->work = 1;\n+\tfor (rle = rc->parents; rle; rle= rle->next)\n+\t\tmark_needed(rle->ri->sha1);\n+}\n+\n+static struct rev_cache *needed;\n+static unsigned long num_needed;\n+\n+static void link_needed(void)\n+{\n+\t/* Link needed ones for quick traversal */\n+\tint i;\n+\tnum_needed = 0;\n+\tfor (i = 0; i < nr_revs; i++) {\n+\t\tstruct rev_cache *rc = rev_cache[i];\n+\t\tif (rc->work) {\n+\t\t\trc->work_ptr = needed;\n+\t\t\tneeded = rc;\n+\t\t\tnum_needed++;\n+\t\t}\n+\t}\n+}\n+\n+/* Currently this part is stupid, FIXME */\n+static void find_optimum_packs(void)\n+{\n+\tstruct rev_cache *rc;\n+\tstruct pack *e;\n+\tunsigned long hits, total;\n+\n+\thits = total = 0;\n+\tfor (rc = needed; rc; rc = rc->work_ptr)\n+\t\trc->work = 0;\n+\n+\tfor (e = pack; e; e = e->next) {\n+\t\te->fill = 0;\n+\t\tfor (rc = needed; rc; rc = rc->work_ptr)\n+\t\t\tif (!rc->work && find_in_pack_idx(rc->sha1, e)) {\n+\t\t\t\trc->work = 1<<(e->ix);\n+\t\t\t\te->fill++;\n+\t\t\t\thits++;\n+\t\t\t}\n+\t\tif (e->fill) {\n+\t\t\tfprintf(stderr, \"use %s to fill %lu\\n\",\n+\t\t\t\te->name, e->fill);\n+\t\t\ttotal += e->pack_size;\n+\t\t}\n+\t}\n+\n+\tfprintf(stderr, \"# needed %lu, hits %lu, total %lu\\n\",\n+\t\tnum_needed, hits, total);\n+\tfor (e = pack; e; e = e->next)\n+\t\tif (e->fill)\n+\t\t\tprintf(\"%s\\n\", e->name);\n+}\n+\n+int main(int ac, char **av)\n+{\n+\tint i;\n+\tchar path[PATH_MAX];\n+\tconst char *tmpdir;\n+\n+\tif (ac < 4 || ac % 2)\n+\t\tusage(dumb_pull_resolve_usage);\n+\n+\ttmpdir = av[1];\n+\tac--; av++;\n+\n+\tsprintf(path, \"%s/inventory\", tmpdir);\n+\tread_inventory(path);\n+\n+\tsprintf(path, \"%s/rev-cache\", tmpdir);\n+\tread_rev_cache(path, NULL, 0);\n+\n+\tfor (i = 1; i < ac; i += 2) {\n+\t\t/* av[i] is a remote branch name */\n+\t\tstruct inventory *e = find_inventory(av[i]);\n+\t\tif (!e) {\n+\t\t\terror(\"cannot find branch %s\", av[i]);\n+\t\t\tcontinue;\n+\t\t}\n+\t\tmark_needed(e->sha1);\n+\t}\n+\n+\tlink_needed();\n+\n+\tsprintf(path, \"%s/pack\", tmpdir);\n+\tmap_pack_idx(path, tmpdir);\n+\n+\tfind_optimum_packs();\n+\treturn 0;\n+}\ndiff --git a/git-dumb-pull-script b/git-dumb-pull-script\nnew file mode 100755\n--- /dev/null\n+++ b/git-dumb-pull-script\n@@ -0,0 +1,129 @@\n+#!/bin/sh\n+\n+: ${GIT_DIR=.git}\n+: ${GIT_OBJECT_DIRECTORY=\"${GIT_DIR}/objects\"}\n+\n+usage () {\n+\techo >&2 \"* git dumb-pull ( ) ...\"\n+\texit 1\n+}\n+\n+error () {\n+\techo >&2 \"* git-dumb-pull: $*\"\n+\texit 1\n+}\n+\n+download_one() {\n+\t# $1 - URL\n+\t# $2 - Local target\n+\tcase \"$1\" in\n+\tfile://* )\n+\t\tpath=/$(expr \"$1\" : 'file:/*\\(.*\\)')\n+\t\tcp \"$path\" \"$2\" || rm -f \"$2\"\n+\t\t;;\n+\thttp://* | https://* )\n+\t\twget -O \"$2\" \"$1\" || rm -f \"$2\"\n+\t\t;;\n+\tesac\n+}\n+\n+case \"$#\" in\n+0)\n+\tusage;;\n+esac\n+url=\"$1\"; shift\n+\n+case \"$url\" in\n+http://* | https://*)\n+\tuse_url=\"$url\"\n+\tcmd='git-http-pull -a -v'\n+\t;;\n+file://*)\n+\tuse_url=/$(expr \"$url\" : 'file:/*\\(.*\\)')\n+\tcmd='git-local-pull -a -l -v'\n+\t;;\n+*)\n+\terror \"Unknown url scheme $url\"\n+\t;;\n+esac\n+\n+# The rest of arguments are remote and local names\n+case $#,$(expr \"$#\" % 2) in\n+0,* | 1,* | *,1)\n+\terror \"Need one or more branch name pairs.\" ;;\n+esac\n+\n+tmp=.git-dumb-pull-$$\n+mkdir \"$tmp\" || error \"cannot create temporary directory\"\n+trap \"rm -fr $tmp\" 0 1 2 3 15\n+\n+# Failing to download is not fatal. It just means the server is\n+# dumber than we thought ;-)\n+if download_one \"$url/info/server\" $tmp/server\n+then\n+\tinfofiles='inventory pack rev-cache'\n+\t(\n+\t cd $tmp &&\n+\t tar xvf server $infofiles || exit 1\n+\t if tar xf server server.sha1\n+\t then\n+\t\tsha1sum -c server.sha1 || {\n+\t\t # did we fail because we did not have sha1sum command?\n+\t\t case \"$?\" in\n+\t\t 127)\n+\t\t : ;; # the command did not exist.\n+\t\t *)\n+\t\t false ;;\n+\t\t esac\n+\t\t}\n+\t else\n+\t \techo >&2 \"* warning: server file lacks sha1 checksum\"\n+\t fi &&\n+\t rm -f server.sha1\n+\t) || exit\n+fi\n+\n+if test -f $tmp/pack\n+then\n+\twhile read pack_size pack\n+\tdo\n+\t\tcase \"$pack\" in\n+\t\t*/*)\n+\t\t\techo >&2 \"* malformed pack $pack\"\n+\t\t\tcontinue\n+\t\t\t;;\n+\t\tesac\n+\n+\t\tidx=$(expr \"$pack\" : '\\(.*\\)\\.pack$').idx\n+\t\t# It is possible, even likely, that we already have that\n+\t\t# index file and associated pack file.\n+\t\tif test -f \"${GIT_OBJECT_DIRECTORY}/pack/$pack\" &&\n+\t\t test -f \"${GIT_OBJECT_DIRECTORY}/pack/$idx\"\n+\t\tthen\n+\t\t\tcontinue\n+\t\tfi\n+\t\tdownload_one \"$url/objects/pack/$idx\" \"$tmp/$idx\"\n+\tdone <$tmp/pack\n+\n+\tgit-dumb-pull-resolve $tmp \"$@\" |\n+\twhile read pack\n+\tdo\n+\t\techo >&2 \"* $pack\"\n+\t\tdownload_one \"$url/objects/pack/$pack\" \"$tmp/$pack\"\n+\t\tif test -f \"$tmp/$pack\" && git-verify-pack \"$tmp/$pack\"\n+\t\tthen\n+\t\t\tidx=$(expr \"$pack\" : '\\(.*\\)\\.pack$').idx\n+\t\t\tmv \"$tmp/$pack\" \"$tmp/$idx\" \\\n+\t\t\t\t\"${GIT_OBJECT_DIRECTORY}/pack/\"\n+\t\tfi\n+\tdone\n+fi\n+\n+while case \"$#\" in 0) break ;; esac\n+do\n+\tremote=\"$1\" local=\"$2\"\n+\t$cmd -w \"$local\" \"$remote\" \"$use_url\"\n+\n+\tshift\n+\tshift\n+done\ndiff --git a/git-update-dumb-server-script b/git-update-dumb-server-script\nnew file mode 100755\n--- /dev/null\n+++ b/git-update-dumb-server-script\n@@ -0,0 +1,47 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2005, Junio C Hamano\n+#\n+\n+: ${GIT_DIR=.git}\n+: ${GIT_OBJECT_DIRECTORY=\"$GIT_DIR/objects\"}\n+export GIT_DIR GIT_OBJECT_DIRECTORY\n+\n+infofiles='inventory pack rev-cache'\n+\n+usage () {\n+\techo >&2 \"* git update-dumb-server\"\n+\texit 1\n+}\n+\n+# Allow 10MB plain SHA1 files to be accumulated before we repack.\n+max_plain_size=10240\n+\n+plain_size=$(\n+{\n+\tdu -sk \"$GIT_OBJECT_DIRECTORY/\" \"$GIT_OBJECT_DIRECTORY/pack/\" |\n+\tsed -e 's/^[ \t]*\\([0-9][0-9]*\\)[ \t].*/\\1/'\n+\techo ' - p'\n+} | dc) &&\n+\n+if test $max_plain_size -lt $plain_size >/dev/null\n+then\n+\tgit-repack-script && git-prune-packed\n+fi &&\n+\n+git-update-dumb-server &&\n+\n+files=$infofiles\n+cd \"$GIT_DIR/info\" &&\n+if sha1sum $infofiles >server.sha1\n+then\n+\tfiles=\"$files server.sha1\"\n+else\n+\trm -f server.sha1\n+\techo >&2 \"* warning: creating server file without sha1sum\"\n+fi &&\n+tar cf server $files &&\n+\n+# We leave rev-cache there for later runs.\n+rm -f server.sha1 inventory pack\n+\ndiff --git a/rev-cache.c b/rev-cache.c\nnew file mode 100644\n--- /dev/null\n+++ b/rev-cache.c\n@@ -0,0 +1,300 @@\n+#include \"refs.h\"\n+#include \"cache.h\"\n+#include \"rev-cache.h\"\n+\n+struct rev_cache **rev_cache;\n+int nr_revs, alloc_revs;\n+\n+struct rev_list_elem *rle_free;\n+\n+#define BATCH_SIZE 512\n+\n+int find_rev_cache(const unsigned char *sha1)\n+{\n+\tint lo = 0, hi = nr_revs;\n+\twhile (lo < hi) {\n+\t\tint mi = (lo + hi) / 2;\n+\t\tstruct rev_cache *ri = rev_cache[mi];\n+\t\tint cmp = memcmp(sha1, ri->sha1, 20);\n+\t\tif (!cmp)\n+\t\t\treturn mi;\n+\t\tif (cmp < 0)\n+\t\t\thi = mi;\n+\t\telse\n+\t\t\tlo = mi + 1;\n+\t}\n+\treturn -lo - 1;\n+}\n+\n+static struct rev_list_elem *alloc_list_elem(void)\n+{\n+\tstruct rev_list_elem *rle;\n+\tif (!rle_free) {\n+\t\tint i;\n+\n+\t\trle = xmalloc(sizeof(*rle) * BATCH_SIZE);\n+\t\tfor (i = 0; i < BATCH_SIZE - 1; i++) {\n+\t\t\trle[i].ri = NULL;\n+\t\t\trle[i].next = &rle[i + 1];\n+\t\t}\n+\t\trle[BATCH_SIZE - 1].ri = NULL; \n+\t\trle[BATCH_SIZE - 1].next = NULL; \n+\t\trle_free = rle;\n+\t}\n+\trle = rle_free;\n+\trle_free = rle->next;\n+\treturn rle;\n+}\n+\n+static struct rev_cache *create_rev_cache(const unsigned char *sha1)\n+{\n+\tstruct rev_cache *ri;\n+\tint pos = find_rev_cache(sha1);\n+\n+\tif (0 <= pos)\n+\t\treturn rev_cache[pos];\n+\tpos = -pos - 1;\n+\tif (alloc_revs <= ++nr_revs) {\n+\t\talloc_revs = alloc_nr(alloc_revs);\n+\t\trev_cache = xrealloc(rev_cache, sizeof(ri) * alloc_revs);\n+\t}\n+\tif (pos < nr_revs)\n+\t\tmemmove(rev_cache + pos + 1, rev_cache + pos,\n+\t\t\t(nr_revs - pos - 1) * sizeof(ri));\n+\tri = xcalloc(1, sizeof(*ri));\n+\tmemcpy(ri->sha1, sha1, 20);\n+\trev_cache[pos] = ri;\n+\treturn ri;\n+}\n+\n+static unsigned char last_sha1[20];\n+\n+static void write_one_rev_cache(FILE *rev_cache_file, struct rev_cache *ri)\n+{\n+\tunsigned char flag;\n+\tstruct rev_list_elem *rle;\n+\n+\tif (ri->written)\n+\t\treturn;\n+\n+\tif (ri->parsed) {\n+\n+\t\t/* We use last_sha1 compression only for the first parent;\n+\t\t * otherwise the resulting rev-cache would lose the parent\n+\t\t * order information.\n+\t\t */\n+\t\tif (ri->parents &&\n+\t\t !memcmp(ri->parents->ri->sha1, last_sha1, 20))\n+\t\t\tflag = (ri->num_parents - 1) | 0x80;\n+\t\telse\n+\t\t\tflag = ri->num_parents;\n+\n+\t\tfwrite(ri->sha1, 20, 1, rev_cache_file);\n+\t\tfwrite(&flag, 1, 1, rev_cache_file);\n+\t\tfor (rle = ri->parents; rle; rle = rle->next) {\n+\t\t\tif (flag & 0x80 && rle == ri->parents)\n+\t\t\t\tcontinue;\n+\t\t\tfwrite(rle->ri->sha1, 20, 1, rev_cache_file);\n+\t\t}\n+\t\tmemcpy(last_sha1, ri->sha1, 20);\n+\t\tri->written = 1;\n+\t}\n+\t/* recursively write children depth first */\n+\tfor (rle = ri->children; rle; rle = rle->next)\n+\t\twrite_one_rev_cache(rev_cache_file, rle->ri);\n+}\n+\n+void write_rev_cache(const char *path)\n+{\n+\t/* write the following commit ancestry information in\n+\t * $GIT_DIR/info/rev-cache.\n+\t *\n+\t * The format is:\n+\t * 20-byte SHA1 (commit ID)\n+\t * 1-byte flag:\n+\t * - bit 0-6 records \"number of parent commit SHA1s to\n+\t * follow\" (i.e. up to 127 children can be listed).\n+\t * - when the bit 7 is on, then \"the entry immediately\n+\t * before this entry is one of the parents of this\n+ * commit\".\n+\t * N x 20-byte SHA1 (parent commit IDs)\n+\t */\n+\tFILE *rev_cache_file;\n+\tint i;\n+\tstruct rev_cache *ri;\n+\n+\trev_cache_file = fopen(path, \"a\");\n+\tif (!rev_cache_file)\n+\t\tdie(\"cannot append to rev cache file.\");\n+\n+\tmemset(last_sha1, 0, 20);\n+\n+\t/* Go through available rev_cache structures, starting from\n+\t * parentless ones first, so that we would get most out of\n+\t * last_sha1 optimization by the depth first behaviour of\n+\t * write_one_rev_cache().\n+\t */\n+\tfor (i = 0; i < nr_revs; i++) {\n+\t\tri = rev_cache[i];\n+\t\tif (ri->num_parents)\n+\t\t\tcontinue;\n+\t\twrite_one_rev_cache(rev_cache_file, ri);\n+\t}\n+\t/* Then the rest */\n+\tfor (i = 0; i < nr_revs; i++) {\n+\t\tri = rev_cache[i];\n+\t\twrite_one_rev_cache(rev_cache_file, ri);\n+\t}\n+\n+\tfclose(rev_cache_file);\n+}\n+\n+static void add_parent(struct rev_cache *child,\n+\t\t const unsigned char *parent_sha1)\n+{\n+\tstruct rev_cache *parent = create_rev_cache(parent_sha1);\n+\tstruct rev_list_elem *e = alloc_list_elem();\n+\n+\t/* Keep the parent list ordered in the same way the commit\n+\t * object records them.\n+\t */\n+\te->ri = parent;\n+\te->next = NULL;\n+\tif (!child->parents_tail)\n+\t\tchild->parents = e;\n+\telse\n+\t\tchild->parents_tail->next = e;\n+\tchild->parents_tail = e;\n+\tchild->num_parents++;\n+\t\n+\t/* There is no inherent order of the children so we just\n+\t * LIFO them together.\n+\t */\n+\te = alloc_list_elem();\n+\te->next = parent->children;\n+\tparent->children = e;\n+\te->ri = child;\n+\tparent->num_children++;\n+}\n+\n+int read_rev_cache(const char *path, FILE *dumpfile, int dry_run)\n+{\n+\tunsigned char *map;\n+\tint fd;\n+\tstruct stat st;\n+\tunsigned long ofs, len;\n+\tstruct rev_cache *ri = NULL;\n+\n+\tfd = open(path, O_RDONLY);\n+\tif (fd < 0)\n+\t\treturn 0;\n+\tif (fstat(fd, &st)) {\n+\t\tclose(fd);\n+\t\treturn -1;\n+\t}\n+\tmap = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0);\n+\tif (map == MAP_FAILED) {\n+\t\tclose(fd);\n+\t\treturn -1;\n+\t}\n+\tclose(fd);\n+\n+\tmemset(last_sha1, 0, 20);\n+\tofs = 0;\n+\tlen = st.st_size;\n+\twhile (ofs < len) {\n+\t\tunsigned char sha1[20];\n+\t\tint flag, cnt, i;\n+\t\tif (len < ofs + 21)\n+\t\t\tdie(\"rev-cache too short\"); \n+\t\tmemcpy(sha1, map + ofs, 20);\n+\t\tflag = map[ofs + 20];\n+\t\tofs += 21;\n+\t\tcnt = (flag & 0x7f) + ((flag & 0x80) != 0);\n+\t\tif (len < ofs + (flag & 0x7f) * 20)\n+\t\t\tdie(\"rev-cache too short to have %d more parents\",\n+\t\t\t (flag & 0x7f));\n+\t\tif (dumpfile)\n+\t\t\tfprintf(dumpfile, \"%s\", sha1_to_hex(sha1));\n+\t\tif (!dry_run) {\n+\t\t\tri = create_rev_cache(sha1);\n+\t\t\tri->written = 1;\n+\t\t\tri->parsed = 1;\n+\t\t\tif (!ri)\n+\t\t\t\tdie(\"cannot create rev-cache for %s\",\n+\t\t\t\t sha1_to_hex(sha1));\n+\t\t}\n+\t\ti = 0;\n+\t\tif (flag & 0x80) {\n+\t\t\tif (!dry_run)\n+\t\t\t\tadd_parent(ri, last_sha1);\n+\t\t\tif (dumpfile)\n+\t\t\t\tfprintf(dumpfile, \" %s\",\n+\t\t\t\t\tsha1_to_hex(last_sha1));\n+\t\t\ti++;\n+\t\t}\n+\t\twhile (i++ < cnt) {\n+\t\t\tif (!dry_run)\n+\t\t\t\tadd_parent(ri, map + ofs);\n+\t\t\tif (dumpfile)\n+\t\t\t\tfprintf(dumpfile, \" %s\",\n+\t\t\t\t\tsha1_to_hex(last_sha1));\n+\t\t\tofs += 20;\n+\t\t}\n+\t\tif (dumpfile)\n+\t\t\tfprintf(dumpfile, \"\\n\");\n+\t\tmemcpy(last_sha1, sha1, 20);\n+\t}\n+\tif (ofs != len)\n+\t\tdie(\"rev-cache truncated?\");\n+\tmunmap(map, len);\n+\treturn 0;\n+}\n+\n+int record_rev_cache(const unsigned char *sha1)\n+{\n+\tunsigned char parent[20];\n+\tchar type[20];\n+\tunsigned long size, ofs;\n+\tunsigned int cnt, i;\n+\tvoid *buf;\n+\tstruct rev_cache *ri;\n+\n+\tbuf = read_sha1_file(sha1, type, &size);\n+\tif (!buf)\n+\t\treturn 1; /* unavailable */\n+\tif (strcmp(type, \"commit\")) {\n+\t\t/* could be a tag or tree */\n+\t\tfree(buf);\n+\t\treturn 1;\n+\t}\n+\tri = create_rev_cache(sha1);\n+\tif (ri->parsed)\n+\t\treturn 0;\n+\n+\tcnt = 0;\n+\tofs = 46; /* \"tree \" + hex-sha1 + \"\\n\" */\n+\twhile (!memcmp(buf + ofs, \"parent \", 7) &&\n+\t !get_sha1_hex(buf + ofs + 7, parent)) {\n+\t\tofs += 48;\n+\t\tcnt++;\n+\t}\n+\tif (cnt * 48 + 46 != ofs) {\n+\t\tfree(buf);\n+\t\treturn error(\"internal error in record_rev_cache\");\n+\t}\n+\n+\tri = create_rev_cache(sha1);\n+\tri->parsed = 1;\n+\n+\tfor (i = 0; i < cnt; i++) {\n+\t\tunsigned char parent_sha1[20];\n+\t\t\n+\t\tofs = 46 + i * 48 + 7;\n+\t\tget_sha1_hex(buf + ofs, parent_sha1);\n+\t\tadd_parent(ri, parent_sha1);\n+\t\trecord_rev_cache(parent_sha1);\n+\t}\n+\tfree(buf);\n+\treturn 0;\n+}\ndiff --git a/rev-cache.h b/rev-cache.h\nnew file mode 100644\n--- /dev/null\n+++ b/rev-cache.h\n@@ -0,0 +1,31 @@\n+#ifndef REV_CACHE_H\n+#define REV_CACHE_H\n+\n+#define REV_CACHE_PATH \"info/rev-cache\"\n+\n+extern struct rev_cache {\n+\tstruct rev_cache *head_list;\n+\tstruct rev_list_elem *children;\n+\tstruct rev_list_elem *parents;\n+\tstruct rev_list_elem *parents_tail;\n+\tunsigned short num_parents;\n+\tunsigned short num_children;\n+\tunsigned int written : 1;\n+\tunsigned int parsed : 1;\n+\tunsigned int work : 30;\n+\tvoid *work_ptr;\n+\tunsigned char sha1[20];\n+} **rev_cache;\n+extern int nr_revs, alloc_revs;\n+\n+struct rev_list_elem {\n+\tstruct rev_list_elem *next;\n+\tstruct rev_cache *ri;\n+};\n+\n+extern int find_rev_cache(const unsigned char *);\n+extern int read_rev_cache(const char *, FILE *, int);\n+extern int record_rev_cache(const unsigned char *);\n+extern void write_rev_cache(const char *);\n+\n+#endif\ndiff --git a/show-rev-cache.c b/show-rev-cache.c\nnew file mode 100644\n--- /dev/null\n+++ b/show-rev-cache.c\n@@ -0,0 +1,18 @@\n+#include \"cache.h\"\n+#include \"rev-cache.h\"\n+\n+static char *dump_rev_cache_usage =\n+\"git-dump-rev-cache \";\n+\n+int main(int ac, char **av)\n+{\n+\twhile (1 < ac && av[0][1] == '-') {\n+\t\t/* do flags here */\n+\t\tbreak;\n+\t\tac--; av++;\n+\t}\n+\tif (ac != 2)\n+\t\tusage(dump_rev_cache_usage);\n+\n+\treturn read_rev_cache(av[1], stdout, 1);\n+}\ndiff --git a/update-dumb-server.c b/update-dumb-server.c\nnew file mode 100644\n--- /dev/null\n+++ b/update-dumb-server.c\n@@ -0,0 +1,153 @@\n+#include \"refs.h\"\n+#include \"cache.h\"\n+#include \"rev-cache.h\"\n+\n+static FILE *inventory_file;\n+static int verbose = 0;\n+\n+static int do_refs(const char *path, const unsigned char *sha1)\n+{\n+\t/* path is like .git/refs/heads/master */\n+\tint pfxlen = 10; /* strlen(\".git/refs/\") */\n+\tfprintf(inventory_file, \"%s %s\\n\", sha1_to_hex(sha1), path + pfxlen);\n+\tif (verbose)\n+\t\tfprintf(stderr, \"inventory %s %s\\n\",\n+\t\t\tsha1_to_hex(sha1), path + pfxlen);\n+\trecord_rev_cache(sha1);\n+\treturn 0;\n+}\n+\n+static int inventory(void)\n+{\n+\t/* write names of $GIT_DIR/refs/?*?/?* files in\n+\t * $GIT_DIR/info/inventory, and find the ancestry\n+\t * information.\n+\t */\n+\tchar path[PATH_MAX];\n+\n+\tstrcpy(path, git_path(\"info/inventory\"));\n+\tsafe_create_leading_directories(path);\n+\tinventory_file = fopen(path, \"w\");\n+\tif (!inventory_file)\n+\t\tdie(\"cannot create inventory file.\");\n+\tfor_each_ref(do_refs);\n+\tfclose(inventory_file);\n+\treturn 0;\n+}\n+\n+static int compare_pack_size(const void *a_, const void *b_)\n+{\n+\tstruct packed_git *const*a = a_;\n+\tstruct packed_git *const*b = b_;\n+\tif ((*a)->pack_size < (*b)->pack_size)\n+\t\treturn 1;\n+\telse if ((*a)->pack_size == (*b)->pack_size)\n+\t\treturn 0;\n+\treturn -1;\n+}\n+\n+static int write_packs(void)\n+{\n+\t/* write names of pack files under $GIT_OBJECT_DIRECTORY/pack\n+\t * into $GIT_DIR/info/packs.\n+\t */\n+\tstruct packed_git *p;\n+\tchar path[PATH_MAX];\n+\tFILE *packs_file;\n+\tint pfxlen = strlen(\".git/objects/pack/\");\n+\tstruct packed_git **list;\n+\tint cnt, i;\n+\n+\tfor (cnt = 0, p = packed_git; p; p = p->next)\n+\t\tcnt++;\n+\tlist = xmalloc(sizeof(*list) * cnt);\n+\tfor (i = 0, p = packed_git; p; p = p->next)\n+\t\tlist[i++] = p;\n+\tqsort(list, cnt, sizeof(*list), compare_pack_size);\n+\n+\tstrcpy(path, git_path(\"info/pack\"));\n+\tsafe_create_leading_directories(path);\n+\tpacks_file = fopen(path, \"w\");\n+\tif (!packs_file)\n+\t\treturn -1;\n+\tfor (i = 0; i < cnt; i++) {\n+\t\tp = list[i];\n+\t\tfprintf(packs_file, \"%lu %s\\n\",\n+\t\t\tp->pack_size, p->pack_name + pfxlen);\n+\t\tif (verbose)\n+\t\t\tfprintf(stderr, \"pack %lu %s\\n\",\n+\t\t\t\tp->pack_size,\n+\t\t\t\tp->pack_name + pfxlen);\n+\t}\n+\tfree(list);\n+\tfclose(packs_file);\n+\treturn 0;\n+}\n+\n+static int inventory_packs(void)\n+{\n+\tstruct packed_git *p;\n+\n+\tfor (p = packed_git; p; p = p->next) {\n+\t\tint nth, lim;\n+\t\tlim = num_packed_objects(p);\n+\t\tfor (nth = 0; nth < lim; nth++) {\n+\t\t\tunsigned char sha1[20];\n+\t\t\tchar type[20];\n+\t\t\tif (nth_packed_object_sha1(p, nth, sha1)) {\n+\t\t\t\terror(\"cannot read %dth object from pack %s\",\n+\t\t\t\t nth, p->pack_name);\n+\t\t\t\tcontinue;\n+\t\t\t}\n+\t\t\tif (sha1_object_info(sha1, type, NULL)) {\n+\t\t\t\terror(\"cannot find type of %s\", sha1_to_hex(sha1));\n+\t\t\t\tcontinue;\n+\t\t\t}\n+\t\t\tif (strcmp(type, \"commit\"))\n+\t\t\t\tcontinue;\n+\t\t\trecord_rev_cache(sha1);\n+\t\t}\n+\t}\n+\treturn 0;\n+}\n+\n+static const char *update_dumb_server_usage =\n+\"git-update-dumb-server [-v] [-a]\";\n+\n+int main(int ac, char **av)\n+{\n+\tchar path[PATH_MAX];\n+\tint all_commits = 0;\n+\n+\twhile (1 < ac && av[1][0] == '-') {\n+\t\tif (!strcmp(av[1], \"-v\"))\n+\t\t\tverbose = 1;\n+\t\telse if (!strcmp(av[1], \"-a\"))\n+\t\t\tall_commits = 1;\n+\t\telse\n+\t\t\tusage(update_dumb_server_usage);\n+\t\tac--; av++;\n+\t}\n+\n+\t/* read existing rev-cache if any */\n+\tstrcpy(path, git_path(REV_CACHE_PATH));\n+\tread_rev_cache(path, verbose ? stderr : NULL, 0);\n+\n+\t/* read refs directory and find commit ancentry information */\n+\tinventory();\n+\n+\t/* \n+\t * prepare info/pack file.\n+\t * Note that we do prepare_packed_git() in case we ran in\n+\t * an headless repository.\n+\t */\n+\tprepare_packed_git();\n+\twrite_packs();\n+\n+\tif (all_commits)\n+\t\tinventory_packs();\n+\n+\t/* update the rev-cache database by appending newly found one to it */\n+\twrite_rev_cache(path);\n+\treturn 0;\n+}\n------------\n"},{"id":"5787","messageId":"7vfyuqfa6r.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"7vll4ifbq8.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] rev-list: add \"--objects=self-sufficient\" flag.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-07T23:50:04Z","receivedAt":"2005-07-07T23:50:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"When --objects=self-sufficient is specified instead of usual\n\"--objects\", rev-list shows all objects reachable from trees\nassociated with the commits in its output. This can be used to\nensure that a single pack can be used to recreate the tree\nassociated with every commit in it.\n\nSigned-off-by: Junio C Hamano \n---\n\n*** This makes things easier for the dumb puller because\n*** self-sufficient pack means less falling back on traditional\n*** http-pull.\n\n rev-list.c | 7 ++-\n t/t6100-rev-list-object.sh | 97 ++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 102 insertions(+), 2 deletions(-)\n create mode 100644 t/t6100-rev-list-object.sh\n\n60563326cea81f89098a88ab716fb4f02e326b43\ndiff --git a/rev-list.c b/rev-list.c\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -27,6 +27,7 @@ static int bisect_list = 0;\n static int tag_objects = 0;\n static int tree_objects = 0;\n static int blob_objects = 0;\n+static int objects_self_sufficient = 0;\n static int verbose_header = 0;\n static int show_parents = 0;\n static int hdr_termination = 0;\n@@ -198,7 +199,7 @@ static void mark_tree_uninteresting(stru\n \tstruct object *obj = &tree->object;\n \tstruct tree_entry_list *entry;\n \n-\tif (!tree_objects)\n+\tif (!tree_objects || objects_self_sufficient)\n \t\treturn;\n \tif (obj->flags & UNINTERESTING)\n \t\treturn;\n@@ -448,7 +449,9 @@ int main(int argc, char **argv)\n \t\t\tbisect_list = 1;\n \t\t\tcontinue;\n \t\t}\n-\t\tif (!strcmp(arg, \"--objects\")) {\n+\t\tif (!strncmp(arg, \"--objects\", 9)) {\n+\t\t\tif (!strcmp(arg+9, \"=self-sufficient\"))\n+\t\t\t\tobjects_self_sufficient = 1;\n \t\t\ttag_objects = 1;\n \t\t\ttree_objects = 1;\n \t\t\tblob_objects = 1;\ndiff --git a/t/t6100-rev-list-object.sh b/t/t6100-rev-list-object.sh\nnew file mode 100644\n--- /dev/null\n+++ b/t/t6100-rev-list-object.sh\n@@ -0,0 +1,97 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2005 Junio C Hamano\n+#\n+\n+test_description='git-rev-list --objects test.\n+\n+'\n+. ./test-lib.sh\n+\n+GIT_AUTHOR_DATE='+0000 946684801'\n+GIT_AUTHOR_NAME=none\n+GIT_AUTHOR_EMAIL=none@none\n+GIT_COMMITTER_DATE='+0000 946684801'\n+GIT_COMMITTER_NAME=none\n+GIT_COMMITTER_EMAIL=none@none\n+export GIT_AUTHOR_DATE GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL \\\n+ GIT_COMMITTER_DATE GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL\n+\n+_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\n+_x40=\"$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40\"\n+sedScript='s/^\\('\"$_x40\"' [^ ]*\\) .*/\\1/p'\n+\n+test_expect_success setup '\n+ for i in frotz nitfol\n+ do\n+\t echo $i >$i &&\n+\t git-update-cache --add $i || exit\n+ done &&\n+ tree0=$(git-write-tree) &&\n+ commit0=$(git-commit-tree $tree0) &&\n+ echo $tree0 &&\n+ echo $commit0 &&\n+ git-ls-tree -r $tree0 &&\n+ echo nitfol nitfol >nitfol &&\n+ git-update-cache --add nitfol &&\n+ tree1=$(git-write-tree) &&\n+ commit1=$(git-commit-tree $tree1 -p $commit0) &&\n+ echo $tree1 &&\n+ echo $commit1 &&\n+ git-ls-tree -r $tree1 \n+' contents.0\n+'\n+\n+test_expect_success 'pack #1 (commit 1 except commit 0)' '\n+ name1=$(git-rev-list --objects $commit1 ^$commit0 | \\\n+ git-pack-objects pk1) &&\n+ ls pk1-* &&\n+ git-verify-pack -v pk1-$name1.idx |\n+ sed -ne \"$sedScript\" | sort >contents.1\n+'\n+\n+test_expect_success 'there should not be any overlaps' '\n+ case $(comm -12 contents.0 contents.1 | wc -l) in\n+ 0) ;;\n+ *) false ;;\n+ esac\n+'\n+\n+test_expect_success 'pack #2 (commit 1 unpacked only)' '\n+ ln pk0-* .git/objects/pack/. &&\n+ name2=$(git-rev-list --objects --unpacked $commit1 | \\\n+ git-pack-objects pk2) &&\n+ ls pk2-* &&\n+ git-verify-pack -v pk1-$name2.idx |\n+ sed -ne \"$sedScript\" | sort >contents.2\n+'\n+\n+test_expect_success 'pack #1 and #2 should be the same' '\n+ diff contents.1 contents.2\n+'\n+\n+test_expect_success 'pack #3 (commit 1 except commit 0, self-sufficient)' '\n+ name3=$(git-rev-list --objects=self-sufficient $commit1 ^$commit0 | \\\n+ git-pack-objects pk3) &&\n+ ls pk3-* &&\n+ git-verify-pack -v pk3-$name3.idx |\n+ sed -ne \"$sedScript\" | sort >contents.3\n+'\n+\n+ls_tree_to_invent='s/^[0-9]* \\([^ ]*\\) \\('\"$_x40\"'\\)\t.*/\\2 \\1/'\n+test_expect_success 'make sure pack #3 is not missing anything from commit1' '\n+ (\n+\techo \"$tree1 tree\"\n+\techo \"$commit1 commit\"\n+\tgit-ls-tree \"$tree1\" | sed -e \"$ls_tree_to_invent\"\n+ ) | sort >tree-contents.1 &&\n+ comm -23 tree-contents.1 contents.3 >missing.3 &&\n+ diff /dev/null missing.3\n+'\n------------\n"},{"id":"5788","messageId":"7vackyfa5a.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"7vll4ifbq8.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] Use --objects=self-sufficient flag to rev-list.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-07T23:50:57Z","receivedAt":"2005-07-07T23:50:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This adds --self-sufficient flag to git-repack-script, and uses\nit when preparing the dumb server material.\n\nSigned-off-by: Junio C Hamano \n---\n\n*** This makes things easier for the dumb puller because\n*** self-sufficient pack means less falling back on traditional\n*** http-pull.\n\n git-repack-script | 10 +++++++++-\n git-update-dumb-server-script | 2 +-\n 2 files changed, 10 insertions(+), 2 deletions(-)\n\n6b0568181ede5540706bcdf69868102f554a2f8a\ndiff --git a/git-repack-script b/git-repack-script\n--- a/git-repack-script\n+++ b/git-repack-script\n@@ -1,8 +1,16 @@\n #!/bin/sh\n : ${GIT_DIR=.git}\n : ${GIT_OBJECT_DIRECTORY=\"$GIT_DIR/objects\"}\n+\n+case \"$1\" in\n+--self-sufficient)\n+\tobjects=--objects=self-sufficient ;;\n+*)\n+\tobjects=--objects ;;\n+esac\n+\n rm -f .tmp-pack-*\n-packname=$(git-rev-list --unpacked --objects $(git-rev-parse --all) |\n+packname=$(git-rev-list --unpacked $objects $(git-rev-parse --all) |\n \tgit-pack-objects --non-empty --incremental .tmp-pack) ||\n \texit 1\n if [ -z \"$packname\" ]; then\ndiff --git a/git-update-dumb-server-script b/git-update-dumb-server-script\n--- a/git-update-dumb-server-script\n+++ b/git-update-dumb-server-script\n@@ -26,7 +26,7 @@ plain_size=$(\n \n if test $max_plain_size -lt $plain_size >/dev/null\n then\n-\tgit-repack-script && git-prune-packed\n+\tgit-repack-script --self-sufficient && git-prune-packed\n fi &&\n \n git-update-dumb-server &&\n------------\n"},{"id":"5789","messageId":"12c511ca05070716526954edd@mail.gmail.com","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071549330.25104@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Tony Luck","fromEmail":"tony.luck@gmail.com","sentAt":"2005-07-07T23:52:25Z","receivedAt":"2005-07-07T23:52:25Z","isPatch":false,"sender":{"key":"tony.luck@gmail.com","avatar":null},"body":"> > So, what _is_ then the way to pull now, actually? If we use rsync, won't\n> > we end up with having the objects we previous had twice now?\n> \n> Rsync works fine. You can either unpack the pack you get, or, if you\n> prefer, just run\n> \n> git-prune-packed\n\ncg-update from a local repo that contains packs is broken though :-(\n\nAlso \"git-fsck-cache\" in a repo that is fully packed complains:\n\n fatal: No default references\n\n-Tony\n"},{"id":"5790","messageId":"7v64vmf9zw.fsf@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"12c511ca05070716526954edd@mail.gmail.com","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-07T23:54:11Z","receivedAt":"2005-07-07T23:54:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"TL\" == Tony Luck writes:\n\nTL> Also \"git-fsck-cache\" in a repo that is fully packed complains:\n\nTL> fatal: No default references\n\n\"git-fsck-cache --full\", perhaps?\n"},{"id":"5791","messageId":"Pine.LNX.4.58.0507071657140.25104@g5.osdl.org","threadId":"1096","inReplyTo":"7vfyuqfa6r.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] rev-list: add \"--objects=self-sufficient\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-07T23:58:13Z","receivedAt":"2005-07-07T23:58:13Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Junio C Hamano wrote:\n>\n> -\t\tif (!strcmp(arg, \"--objects\")) {\n> +\t\tif (!strncmp(arg, \"--objects\", 9)) {\n> +\t\t\tif (!strcmp(arg+9, \"=self-sufficient\"))\n> +\t\t\t\tobjects_self_sufficient = 1;\n\nThis is nasty - if you mis-spell \"self-sufficient\" (easy enough to do) \nyou'll never know the end result isn't what you expected. It won't warn \nyou in any way, it will just make a non-self-sufficient pack..\n\n\t\tLinus\n"},{"id":"5792","messageId":"Pine.LNX.4.58.0507071658460.25104@g5.osdl.org","threadId":"1096","inReplyTo":"12c511ca05070716526954edd@mail.gmail.com","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-07T23:59:37Z","receivedAt":"2005-07-07T23:59:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Tony Luck wrote:\n>\n> > > So, what _is_ then the way to pull now, actually? If we use rsync, won't\n> > > we end up with having the objects we previous had twice now?\n> > \n> > Rsync works fine. You can either unpack the pack you get, or, if you\n> > prefer, just run\n> > \n> > git-prune-packed\n> \n> cg-update from a local repo that contains packs is broken though :-(\n\nIs this with cg-0.12? The most recent release should be happy with packs.\n\n> Also \"git-fsck-cache\" in a repo that is fully packed complains:\n> \n> fatal: No default references\n\nAhh, that's true. I knew about it, and forgot. Will fix,\n\n\t\tLinus\n"},{"id":"5793","messageId":"12c511ca050707170964a2cc92@mail.gmail.com","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071658460.25104@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Tony Luck","fromEmail":"tony.luck@gmail.com","sentAt":"2005-07-08T00:09:45Z","receivedAt":"2005-07-08T00:09:45Z","isPatch":false,"sender":{"key":"tony.luck@gmail.com","avatar":null},"body":"> > cg-update from a local repo that contains packs is broken though :-(\n> \n> Is this with cg-0.12? The most recent release should be happy with packs.\n\nYes ... I pulled, built and installed the latest cogito this afternoon\nbefore trying\nto touch anything involving packs. cg-version says:\n\ncogito-0.12 (b21855b8734ca76ea08c0c17e4a204191b6e3add)\n\nThis is what happens (\"linus\" is a local branch just pulled from kernel.org,\nso it just contains one pack file and its index).\n\n$ cg-update linus\n`/home/aegl/GIT/linus/.git/refs/heads/master' -> `.git/refs/heads/linus'\ndoes not exist /home/aegl/GIT/linus/.git/objects/04/3d051615aa5da09a7e44f1edbb69\n798458e067\nCannot obtain needed object 043d051615aa5da09a7e44f1edbb69798458e067\nwhile processing commit 0000000000000000000000000000000000000000.\ncg-pull: objects pull failed\n\nIf I try it again, it thinks things are up to date (since it\nmistakenly updated the\n.git/refs/heads/linus), but then fails to apply (since it doesn't have\nthe objects\nit needs).\n\n-Tony\n"},{"id":"5794","messageId":"Pine.LNX.4.58.0507071706090.25104@g5.osdl.org","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071658460.25104@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-08T00:09:48Z","receivedAt":"2005-07-08T00:09:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Linus Torvalds wrote:\n> > \n> > cg-update from a local repo that contains packs is broken though :-(\n> \n> Is this with cg-0.12? The most recent release should be happy with packs.\n\nAhh, I see it. It's because it uses \"git-local-pull\", and yes, \ngit-local-pull does the old filename assumption. Right?\n\nHo humm.. That's a bug in local-pull.c, although I'm not sure how to fix\nit best. One option is to just not use it (as in \"use git-fetch-pack\ninstead\"), and another is to use GIT_ALTERNATE_OBJECT_DIRECTORIES and just\npick up the files that way. Yet another one is to actually copy over (or\nlink) the pack-file, but that's likely the least preferable one.\n\nThe _simplest_ fix is to use git-fetch-pack. It doesn't give you the \nconvenient hard-linking, though.\n\n\t\tLinus\n"},{"id":"5795","messageId":"Pine.LNX.4.58.0507071720330.25104@g5.osdl.org","threadId":"1096","inReplyTo":"12c511ca050707170964a2cc92@mail.gmail.com","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-08T00:23:26Z","receivedAt":"2005-07-08T00:23:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Tony Luck wrote:\n> \n> This is what happens (\"linus\" is a local branch just pulled from kernel.org,\n> so it just contains one pack file and its index).\n> \n> $ cg-update linus\n> `/home/aegl/GIT/linus/.git/refs/heads/master' -> `.git/refs/heads/linus'\n> does not exist /home/aegl/GIT/linus/.git/objects/04/3d051615aa5da09a7e44f1edbb69\n> 798458e067\n> Cannot obtain needed object 043d051615aa5da09a7e44f1edbb69798458e067\n> while processing commit 0000000000000000000000000000000000000000.\n> cg-pull: objects pull failed\n\nOk. The immediate fix is to just unpack the pack:\n\n\tmv .git/objects/pack/* .git/\n\tfor i in .git/*.pack; do git-unpack-objects < $i; done\n\n(or similar - the above is untested, but I think it should be obvious \nenough what I'm trying to do).\n\n> If I try it again, it thinks things are up to date (since it mistakenly\n> updated the .git/refs/heads/linus), but then fails to apply (since it\n> doesn't have the objects it needs).\n\nOk, that's a worse bug, it really shouldn't update the head until _after_ \nthe pull has succeeded.\n\n\t\tLinus\n"},{"id":"5796","messageId":"7vvf3mds9c.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071657140.25104@g5.osdl.org","subject":"[PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-08T01:02:39Z","receivedAt":"2005-07-08T01:02:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> This is nasty - if you mis-spell \"self-sufficient\" (easy enough to do) \nLT> you'll never know the end result isn't what you expected. It won't warn \nLT> you in any way, it will just make a non-self-sufficient pack..\n\nAgain you are right. How about --full-objects instead?\n\n------------\nWhen --full-objects is specified instead of usual \"--objects\",\nrev-list shows all objects reachable from trees associated with\nthe commits in its output. This can be used to ensure that a\nsingle pack can be used to recreate the tree associated with\nevery commit in it.\n\nSigned-off-by: Junio C Hamano \n---\n\n rev-list.c | 13 +++++-\n t/t6100-rev-list-object.sh | 98 ++++++++++++++++++++++++++++++++++++++++++++\n 2 files changed, 109 insertions(+), 2 deletions(-)\n create mode 100644 t/t6100-rev-list-object.sh\n\n24c31c0417a54a6ca6dc1b86267bccbbfe87c7d8\ndiff --git a/rev-list.c b/rev-list.c\n--- a/rev-list.c\n+++ b/rev-list.c\n@@ -17,6 +17,7 @@ static const char rev_list_usage[] =\n \t\t \" --min-age=epoch\\n\"\n \t\t \" --bisect\\n\"\n \t\t \" --objects\\n\"\n+\t\t \" --full-objects\\n\"\n \t\t \" --unpacked\\n\"\n \t\t \" --header\\n\"\n \t\t \" --pretty\\n\"\n@@ -27,6 +28,7 @@ static int bisect_list = 0;\n static int tag_objects = 0;\n static int tree_objects = 0;\n static int blob_objects = 0;\n+static int objects_self_sufficient = 0;\n static int verbose_header = 0;\n static int show_parents = 0;\n static int hdr_termination = 0;\n@@ -198,7 +200,7 @@ static void mark_tree_uninteresting(stru\n \tstruct object *obj = &tree->object;\n \tstruct tree_entry_list *entry;\n \n-\tif (!tree_objects)\n+\tif (!tree_objects || objects_self_sufficient)\n \t\treturn;\n \tif (obj->flags & UNINTERESTING)\n \t\treturn;\n@@ -448,7 +450,14 @@ int main(int argc, char **argv)\n \t\t\tbisect_list = 1;\n \t\t\tcontinue;\n \t\t}\n-\t\tif (!strcmp(arg, \"--objects\")) {\n+\t\tif (!strncmp(arg, \"--objects\", 9)) {\n+\t\t\ttag_objects = 1;\n+\t\t\ttree_objects = 1;\n+\t\t\tblob_objects = 1;\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (!strncmp(arg, \"--full-objects\", 9)) {\n+\t\t\tobjects_self_sufficient = 1;\n \t\t\ttag_objects = 1;\n \t\t\ttree_objects = 1;\n \t\t\tblob_objects = 1;\ndiff --git a/t/t6100-rev-list-object.sh b/t/t6100-rev-list-object.sh\nnew file mode 100644\n--- /dev/null\n+++ b/t/t6100-rev-list-object.sh\n@@ -0,0 +1,98 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2005 Junio C Hamano\n+#\n+\n+test_description='git-rev-list --objects test.\n+\n+'\n+. ./test-lib.sh\n+\n+GIT_AUTHOR_DATE='+0000 946684801'\n+GIT_AUTHOR_NAME=none\n+GIT_AUTHOR_EMAIL=none@none\n+GIT_COMMITTER_DATE='+0000 946684801'\n+GIT_COMMITTER_NAME=none\n+GIT_COMMITTER_EMAIL=none@none\n+export GIT_AUTHOR_DATE GIT_AUTHOR_NAME GIT_AUTHOR_EMAIL \\\n+ GIT_COMMITTER_DATE GIT_COMMITTER_NAME GIT_COMMITTER_EMAIL\n+\n+_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'\n+_x40=\"$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40\"\n+sedScript='s/^\\('\"$_x40\"' [^ ]*\\) .*/\\1/p'\n+\n+test_expect_success setup '\n+ for i in frotz nitfol\n+ do\n+\t echo $i >$i &&\n+\t git-update-cache --add $i || exit\n+ done &&\n+ tree0=$(git-write-tree) &&\n+ commit0=$(git-commit-tree $tree0) &&\n+ echo $tree0 &&\n+ echo $commit0 &&\n+ git-ls-tree -r $tree0 &&\n+ echo nitfol nitfol >nitfol &&\n+ rm -f frotz &&\n+ git-update-cache --add nitfol --remove frotz &&\n+ tree1=$(git-write-tree) &&\n+ commit1=$(git-commit-tree $tree1 -p $commit0) &&\n+ echo $tree1 &&\n+ echo $commit1 &&\n+ git-ls-tree -r $tree1 \n+' contents.0\n+'\n+\n+test_expect_success 'pack #1 (commit 1 except commit 0)' '\n+ name1=$(git-rev-list --objects $commit1 ^$commit0 | \\\n+ git-pack-objects pk1) &&\n+ ls pk1-* &&\n+ git-verify-pack -v pk1-$name1.idx |\n+ sed -ne \"$sedScript\" | sort >contents.1\n+'\n+\n+test_expect_success 'there should not be any overlaps' '\n+ case $(comm -12 contents.0 contents.1 | wc -l) in\n+ 0) ;;\n+ *) false ;;\n+ esac\n+'\n+\n+test_expect_success 'pack #2 (commit 1 unpacked only)' '\n+ ln pk0-* .git/objects/pack/. &&\n+ name2=$(git-rev-list --objects --unpacked $commit1 | \\\n+ git-pack-objects pk2) &&\n+ ls pk2-* &&\n+ git-verify-pack -v pk1-$name2.idx |\n+ sed -ne \"$sedScript\" | sort >contents.2\n+'\n+\n+test_expect_success 'pack #1 and #2 should be the same' '\n+ diff contents.1 contents.2\n+'\n+\n+test_expect_success 'pack #3 (commit 1 except commit 0, self-sufficient)' '\n+ name3=$(git-rev-list --full-objects $commit1 ^$commit0 | \\\n+ git-pack-objects pk3) &&\n+ ls pk3-* &&\n+ git-verify-pack -v pk3-$name3.idx |\n+ sed -ne \"$sedScript\" | sort >contents.3\n+'\n+\n+ls_tree_to_invent='s/^[0-9]* \\([^ ]*\\) \\('\"$_x40\"'\\)\t.*/\\2 \\1/'\n+test_expect_success 'make sure pack #3 is not missing anything from commit1' '\n+ (\n+\techo \"$tree1 tree\"\n+\techo \"$commit1 commit\"\n+\tgit-ls-tree \"$tree1\" | sed -e \"$ls_tree_to_invent\"\n+ ) | sort >tree-contents.1 &&\n+ comm -23 tree-contents.1 contents.3 >missing.3 &&\n+ diff /dev/null missing.3\n+'\n------------\n"},{"id":"5797","messageId":"7vpstuds7h.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071657140.25104@g5.osdl.org","subject":"[PATCH] Give --full-objects flag to rev-list when preparing a dumb server.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-08T01:03:46Z","receivedAt":"2005-07-08T01:03:46Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> This is nasty - if you mis-spell \"self-sufficient\" (easy enough to do) \nLT> you'll never know the end result isn't what you expected. It won't warn \nLT> you in any way, it will just make a non-self-sufficient pack..\n\nTo match the change of flag name to --full-objects,...\n\n------------\nThis adds --full flag to git-repack-script, and uses it when\npreparing the dumb server material.\n\nSigned-off-by: Junio C Hamano \n---\n\n git-repack-script | 10 +++++++++-\n git-update-dumb-server-script | 2 +-\n 2 files changed, 10 insertions(+), 2 deletions(-)\n\n0617ae867e7e27a7b484827f882fe7b396bea004\ndiff --git a/git-repack-script b/git-repack-script\n--- a/git-repack-script\n+++ b/git-repack-script\n@@ -1,8 +1,16 @@\n #!/bin/sh\n : ${GIT_DIR=.git}\n : ${GIT_OBJECT_DIRECTORY=\"$GIT_DIR/objects\"}\n+\n+case \"$1\" in\n+--full)\n+\tobjects=--full-objects ;;\n+*)\n+\tobjects=--objects ;;\n+esac\n+\n rm -f .tmp-pack-*\n-packname=$(git-rev-list --unpacked --objects $(git-rev-parse --all) |\n+packname=$(git-rev-list --unpacked $objects $(git-rev-parse --all) |\n \tgit-pack-objects --non-empty --incremental .tmp-pack) ||\n \texit 1\n if [ -z \"$packname\" ]; then\ndiff --git a/git-update-dumb-server-script b/git-update-dumb-server-script\n--- a/git-update-dumb-server-script\n+++ b/git-update-dumb-server-script\n@@ -26,7 +26,7 @@ plain_size=$(\n \n if test $max_plain_size -lt $plain_size >/dev/null\n then\n-\tgit-repack-script && git-prune-packed\n+\tgit-repack-script --full && git-prune-packed\n fi &&\n \n git-update-dumb-server &&\n------------\n"},{"id":"5800","messageId":"Pine.LNX.4.58.0507071832440.25104@g5.osdl.org","threadId":"1096","inReplyTo":"7vvf3mds9c.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-08T01:33:54Z","receivedAt":"2005-07-08T01:33:54Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Junio C Hamano wrote:\n> \n> Again you are right. How about --full-objects instead?\n\nI don't mind the \"--objects=xxx\" format per se, but it would need to \nverify that the \"=xxx\" was either valid or wasn't there at all. So what I \nobjected to was not that it was easy to mis-spell, but that if misspelled, \nthe program wouldn't point it out as an error, but silently just do the \nwrong thing.\n\n\t\tLinus\n"},{"id":"5801","messageId":"Pine.LNX.4.58.0507071841010.25104@g5.osdl.org","threadId":"1096","inReplyTo":"7vvf3mds9c.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-08T01:46:31Z","receivedAt":"2005-07-08T01:46:31Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Junio C Hamano wrote:\n>\n> When --full-objects is specified instead of usual \"--objects\",\n> rev-list shows all objects reachable from trees associated with\n> the commits in its output. This can be used to ensure that a\n> single pack can be used to recreate the tree associated with\n> every commit in it.\n\nHmm.. The more I think about it, the less I think this is about \"full \nobjects\".\n\nAfter all, we won't have all objects: the pack will still cut off any \ncommits that may be reachable but not interesting.\n\nSo this is more specifically about full _trees_, not objects per se. So \nwhile the name of the option doesn't really matter all that much, I do \nthink it would make more sense as \"--whole-trees\" or something like that.\n\nHowever, I really don't think it's a very useful option in the first\nplace. Any dumb web-based thing that depends on \"--whole-trees\" would suck\nhorribly. For the kernel, it means that you'd be guaranteed 17,000+ files,\nand there would be very few deltas in there, so you'd have this 40MB+\npack-file. Which is _not_ an acceptable way of getting updates.\n\n\t\tLinus\n"},{"id":"5802","messageId":"42CDDCF0.9020906@qualitycode.com","threadId":"1096","inReplyTo":"m1vf3muwxw.fsf@ebiederm.dsl.xmission.com","subject":"Dumb servers (was: [ANNOUNCE] Cogito-0.12)","fromName":"Kevin Smith","fromEmail":"yarcs@qualitycode.com","sentAt":"2005-07-08T01:54:56Z","receivedAt":"2005-07-08T01:54:56Z","isPatch":false,"sender":{"key":"yarcs@qualitycode.com","avatar":null},"body":"Eric W. Biederman wrote:\n> Linus Torvalds writes:\n> \n> \n>>That said, I really think the dumb protocols are useless anyway. No other \n>>system supports pure static object pulling anyway, and as far as I'm \n>>concerned, I want \"rsync\" to kind of work (but it won't be optimal, since \n>>re-packing will delete all the old objects and replace it with the new \n>>pack that is downloaded anew). But plain http? I'm not convinced.\n> \n> \n> Have you not looked at tla/arch? tla does supports dumb servers.\n> It's job is a little easier as it has one file per atomic commit\n> I suspect once packs start working well that should not be an\n> issue for git either.\n\nIn addition to GNU arch/tla, it it also supported by baz, ArX, darcs, \nand mercurial.\n\n> For small projects this is a major benefit, as they can just push\n> their files to a convenient http or ftp server.\n\nAbsolutely. For the kernel it might not make sense, but I view it as a \nreally important feature for tiny projects around the world. Even a CGI \nrequirement makes it impossible to serve a project from free or really \ncheap web hosts. Plain HTTP is the only protocol available to people who \nhave no extra money to spend on hosting accounts.\n\nThis happens to be a hot button issue for me, in case you can't tell. \nSorry if I'm ranting.\n\nKevin\n"},{"id":"5803","messageId":"m11x6akpx1.fsf@ebiederm.dsl.xmission.com","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071520220.25104@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-08T02:11:22Z","receivedAt":"2005-07-08T02:11:22Z","isPatch":false,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, 7 Jul 2005, Eric W. Biederman wrote:\n>>\n>> For optimizing network bandwidth that sounds like the way to go. For\n>> adhoc development I don't know. For a central sever you still need\n>> an authenticated way to push content, which makes it another dimension\n>> of the problem.\n>\n> I'm convinced that \"ssh\" is the only sane way for pushing. If you don't \n> trust somebody enough to give him ssh access, you shouldn't trust him with \n> write access to your project in the first place.\n\nAgreed, I brought that up only so I could dismiss it :) \n\n> So I don't worry about pushing. I think we've got that covered. It's \n> really the anonymous pulling that needs something.\n\nSo long as we remember there is a tradeoff between efficiency and\nease of setup for anonymous access and small projects.\n\nEric\n"},{"id":"5804","messageId":"7vy88ica8e.fsf@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071841010.25104@g5.osdl.org","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-08T02:17:21Z","receivedAt":"2005-07-08T02:17:21Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n\nLT> However, I really don't think it's a very useful option in\nLT> the first place. Any dumb web-based thing that depends on\nLT> \"--whole-trees\" would suck horribly.\n\nI agree with these two sentences now.\n\nHowever it does not automatically mean that the avenue I have\nbeen pursuing would not work; the server side preparation needs\nto be a bit more careful than what I sent, which unconditionally\nruns \"prune-packed\". It instead should leave the files that\n\"--whole-trees\" would have packed as plain SHA1 files, so that\nthe bulk is obtained by statically generated packs and the rest\ncan be handled in the commit-chain walker as before.\n\nSo, the server side preparation needs be tweaked to do something\nlike:\n\n (1) Repack when necessary (no --whole-trees).\n\n (2) For each .git/objects/pack/ pack, make a list of trees and\n blobs that are missing from the commits that contained in\n the same pack.\n\n (3) Run \"prune-packed\" but do not prune objects on the list\n produced in the previous step.\n\n (4) Take inventory, rev-cache, and pack, as done by the posted\n patch.\n\nThe determination of (1) is a bit problematic since \"when\nnecessary\" is not \"when .git/objects/?? grew too big\" anymore,\ndue to the fact that (3) would deliberately leave plain SHA1\nfiles there.\n\nA completely different way would be to prepare packs of objects\nbased on age, and create an inventory of such packs. Have\nclient download such an inventory, which essentially says \"if\nyou have this commit, then slurp these packs and you are done.\"\n"},{"id":"5805","messageId":"Pine.LNX.4.58.0507071918230.25104@g5.osdl.org","threadId":"1096","inReplyTo":"42CDDCF0.9020906@qualitycode.com","subject":"Re: Dumb servers (was: [ANNOUNCE] Cogito-0.12)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-08T02:27:33Z","receivedAt":"2005-07-08T02:27:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Kevin Smith wrote:\n> \n> Absolutely. For the kernel it might not make sense, but I view it as a \n> really important feature for tiny projects around the world. Even a CGI \n> requirement makes it impossible to serve a project from free or really \n> cheap web hosts. Plain HTTP is the only protocol available to people who \n> have no extra money to spend on hosting accounts.\n\nWell, the http approach always works as well as an \"rsync\", ie you can \nalways replace \"rsync\" with \"wget -r -c\" or similar.\n\nBut the end result will be a purely dumb mirror of what the other side \nhad, ie it will have all the same problems rsync has with things like \nmultiple branches etc (it will get all of them, not just the objects \nneeded from the one branch you're trying to pull).\n\nSo it's not pretty. But it obviously does work: pack-files haven't changed\nthe fact that git is a append-only thing that lives entirely in the\nfilesystem space and doesn't have any \"dynamic content\" (ie nothing is \nhidden inside server state).\n\n\t\tLinus\n"},{"id":"5806","messageId":"Pine.LNX.4.58.0507071928220.25104@g5.osdl.org","threadId":"1096","inReplyTo":"7vy88ica8e.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-08T02:39:23Z","receivedAt":"2005-07-08T02:39:23Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 7 Jul 2005, Junio C Hamano wrote:\n> \n> However it does not automatically mean that the avenue I have\n> been pursuing would not work; the server side preparation needs\n> to be a bit more careful than what I sent, which unconditionally\n> runs \"prune-packed\". It instead should leave the files that\n> \"--whole-trees\" would have packed as plain SHA1 files, so that\n> the bulk is obtained by statically generated packs and the rest\n> can be handled in the commit-chain walker as before.\n\nI really think the commit-chain walker needs to run locally (ie at the \nserver end, or after fetching all the objects from the server).\n\nI don't know how much you've tried out the git-http-pull and git-ssh-pull \nthings, but their performance was quite horrid for anything half-way \nbigger, because of the totally synchronized IO.\n\nThe \"fetch one object, parse it, fetch the next one, parse that..\" \napproach is just horrible.\n\nI ended up preferring the \"rsync\" thing even though rsync sucked badly on\nbig object stores too, if only because when rsync got working, it at least\nnicely pipelined the transfers, and would transfer things ten times faster\nthan git-ssh-pull did (maybe I'm exaggerating, but I don't think so, it\nreally felt that way).\n\nAnd the thing is, if you purely follow one tree (which is likely the\ncommon case for a lot of users), then you are actually always likely\nbetter off with the \"mirror it\" model. Which is _not_ a good model for\ndevelopers (for example, me rsync'ing from Jeff's kernel repository always\ngot me hundreds of useless objects), but it's fine for somebody who\nactually just wants to track somebody else.\n\nAnd then you really can use just rsync or wget or ncftpget or anything\nelse that has a \"fetch recursively, optimizing existing objects\" mode.\n\nNow, re-packing ends up causing some double transmissions, but I bet the\ncost of those are going to be less than the cost of the \"ping-pong for\neach object\" approach. Especially as most of the repacked objects will be \ndeltas if the repacking is done properly.\n\n\t\tLinus\n"},{"id":"5811","messageId":"20050708081458.GA17022@pasky.ji.cz","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071706090.25104@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-08T08:14:58Z","receivedAt":"2005-07-08T08:14:58Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 08, 2005 at 02:09:48AM CEST, I got a letter\nwhere Linus Torvalds told me that...\n> \n> \n> On Thu, 7 Jul 2005, Linus Torvalds wrote:\n> > > \n> > > cg-update from a local repo that contains packs is broken though :-(\n> > \n> > Is this with cg-0.12? The most recent release should be happy with packs.\n> \n> Ahh, I see it. It's because it uses \"git-local-pull\", and yes, \n> git-local-pull does the old filename assumption. Right?\n> \n> Ho humm.. That's a bug in local-pull.c, although I'm not sure how to fix\n> it best.\n\nIt seems like the whole pull family is totally borked now, and I'm\ngetting desperate. Looks like this evening will be *pull.c fixing for\nme.\n\nJul 04 Daniel Barkalow [PATCH 0/2] Support for transferring pack files in git-ssh-*\n\nis what brings some hope to my life, though. Daniel? Any chance we could\nget the similar fixes for local-pull? (I didn't actually look at the\npatch but briefly.) I'll try to review the ssh patchset ASAP - I still\nprefer it much to the fetch-pack things since its protocol is actually\nextensible.\n\n> The _simplest_ fix is to use git-fetch-pack. It doesn't give you the \n> convenient hard-linking, though.\n\nHard-linking is an absolute must for local repositories (well, either\nthat for people who want safety, or symlinking for the rest who want\nspeed - I want to make that one possible in Cogito ASAP but it requires\nsome non-trivial changes to some of its assumptions).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5826","messageId":"Pine.LNX.4.21.0507081139490.30848-100000@iabervon.org","threadId":"1096","inReplyTo":"20050708081458.GA17022@pasky.ji.cz","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2005-07-08T15:56:42Z","receivedAt":"2005-07-08T15:56:42Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 8 Jul 2005, Petr Baudis wrote:\n\n> It seems like the whole pull family is totally borked now, and I'm\n> getting desperate. Looks like this evening will be *pull.c fixing for\n> me.\n> \n> Jul 04 Daniel Barkalow [PATCH 0/2] Support for transferring pack files in git-ssh-*\n> \n> is what brings some hope to my life, though. Daniel? Any chance we could\n> get the similar fixes for local-pull? (I didn't actually look at the\n> patch but briefly.)\n\nThis patch is not actually for transferring objects which are in pack\nfiles in the source, but for transferring a group of objects as a pack\nfile. It does, however, read the source side with git-pack-objects to\ngenerate the content to send, so it would, I guess, fix the problem for\nthe case where it decides to use a pack to transfer.\n\nThe real fix is to go through the pull methods (local-pull and\nssh-pull; http-pull presumably won't be encountering pack files yet) and\nmake them do appropriate things with pack files.\n\nOne thing that is in the patch is a change to the comment, specifying\nthat fetch() could also get other objects in addition to the one\nspecified, if there's some reason to think this is a good idea; the fix\nfor local-pull is probably to link/symlink/copy the pack file if the\nobject is in one.\n\nFor ssh-pull, serve_object in ssh-push needs to be taught how to extract\nan object from a pack file and send it.\n\nHowever, there's a bug in pull.c, covering up a terrible performance\nissue: it doesn't actually make sure you have all the parent of a commit\nthat you had when it checked (due to not having a way of caching the\nresult of checking this, which would require you to put the entire\nrepository through cache each time you pull). This would mean that, if you\nhave a pack that references something outside of it, you won't get\neverything with my proposal above.\n\nI should be able to spend some time on these issues over the weekend.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"5874","messageId":"m1pstrr8k1.fsf@ebiederm.dsl.xmission.com","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071928220.25104@g5.osdl.org","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-09T21:09:02Z","receivedAt":"2005-07-09T21:09:02Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, 7 Jul 2005, Junio C Hamano wrote:\n>> \n>> However it does not automatically mean that the avenue I have\n>> been pursuing would not work; the server side preparation needs\n>> to be a bit more careful than what I sent, which unconditionally\n>> runs \"prune-packed\". It instead should leave the files that\n>> \"--whole-trees\" would have packed as plain SHA1 files, so that\n>> the bulk is obtained by statically generated packs and the rest\n>> can be handled in the commit-chain walker as before.\n\n> The \"fetch one object, parse it, fetch the next one, parse that..\" \n> approach is just horrible.\n\nAgreed. That does not cover up latency at all and depending on the \nparsing cost can potentially even keep you from having anything on\nyour network connection for a noticeable amount of time.\n\n> I ended up preferring the \"rsync\" thing even though rsync sucked badly on\n> big object stores too, if only because when rsync got working, it at least\n> nicely pipelined the transfers, and would transfer things ten times faster\n> than git-ssh-pull did (maybe I'm exaggerating, but I don't think so, it\n> really felt that way).\n\nThis feels to me like an implementation issue (no pipelining) rather\nthan a design issue (pipelining is impossible).\n\n> And the thing is, if you purely follow one tree (which is likely the\n> common case for a lot of users), then you are actually always likely\n> better off with the \"mirror it\" model. Which is _not_ a good model for\n> developers (for example, me rsync'ing from Jeff's kernel repository always\n> got me hundreds of useless objects), but it's fine for somebody who\n> actually just wants to track somebody else.\n\nI assume the problem with the mirror it model was simply there were\nto many objects?\n\n> And then you really can use just rsync or wget or ncftpget or anything\n> else that has a \"fetch recursively, optimizing existing objects\" mode.\n\nSane. But with an intelligent fetcher and a little extra information\na dumb server should still be able to not fetch branches we care\nnothing about. I think that extra information is simply commit\nobject graph and which packs those commit objects are in. I assume\nthe commit graph information will be fairly modest.\n\nOnce you have that extra information you can generate incremental\npacks whenever you upload to the server, and you can make the\nincremental packs per branch.\n\nThat should allow an dumb fetcher to look at the list of commits\nand just fetch those packs it cares about, and since it only has\nto look one place first it should be fairly sane.\n\nThe core idea is that if the dumb-server-preparation can anticipate\ncommon access patterns (mirror a branch) and give enough information\nso that can be done cheaply and pipelined I don't expect it to be much\nworse than an intelligent fetcher.\n\nThe current intelligent fetch currently has a problem that it cannot\nbe used to bootstrap a repository. If you don't have an ancestor\nof what you are fetching you can't fetch it.\n\nEric\n"},{"id":"5875","messageId":"20050709225818.A31045@flint.arm.linux.org.uk","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507071720330.25104@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-07-09T21:58:18Z","receivedAt":"2005-07-09T21:58:18Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Thu, Jul 07, 2005 at 05:23:26PM -0700, Linus Torvalds wrote:\n> On Thu, 7 Jul 2005, Tony Luck wrote:\n> > This is what happens (\"linus\" is a local branch just pulled from kernel.org,\n> > so it just contains one pack file and its index).\n> > \n> > $ cg-update linus\n> > `/home/aegl/GIT/linus/.git/refs/heads/master' -> `.git/refs/heads/linus'\n> > does not exist /home/aegl/GIT/linus/.git/objects/04/3d051615aa5da09a7e44f1edbb69\n> > 798458e067\n> > Cannot obtain needed object 043d051615aa5da09a7e44f1edbb69798458e067\n> > while processing commit 0000000000000000000000000000000000000000.\n> > cg-pull: objects pull failed\n> \n> Ok. The immediate fix is to just unpack the pack:\n> \n> \tmv .git/objects/pack/* .git/\n> \tfor i in .git/*.pack; do git-unpack-objects < $i; done\n> \n> (or similar - the above is untested, but I think it should be obvious \n> enough what I'm trying to do).\n\nThis is evil on the bandwidth, since you'll keep refetching the packed\nobject (64MB of it) over and over.\n\nHowever, I've tried the above, and I get:\n\n$ mv .git/objects/pack/* .git/\n$ for i in .git/*.pack; do git-unpack-objects < $i; done\nUnpacking 55435 objects\nfatal: inflate returned -3\n\nso it seems that the pack is corrupt... or something.\n\n$ md5sum .git/*.pack\n2be38f2947b99bcd088c1930122aadec .git/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack\n\nand git-fsck-cache produces lots and lots of:\n\ndangling tree fae688b62db0b553aae0bf17f0f70e93819dec2b\nbroken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347\n to blob 008e19210e66f01fbaef1aba30243850766b8b12\nbroken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347\n to blob edae09a4b021e353ab4fbba756e31492fbb8fd2e\nbroken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347\n to blob d098b3ba35384fb912989348fd6da59820711ca4\n... etc ...\n\n-- \nRussell King\n"},{"id":"5876","messageId":"20050709232955.B31045@flint.arm.linux.org.uk","threadId":"1096","inReplyTo":"20050709225818.A31045@flint.arm.linux.org.uk","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-07-09T22:29:55Z","receivedAt":"2005-07-09T22:29:55Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Sat, Jul 09, 2005 at 10:58:18PM +0100, Russell King wrote:\n> On Thu, Jul 07, 2005 at 05:23:26PM -0700, Linus Torvalds wrote:\n> > On Thu, 7 Jul 2005, Tony Luck wrote:\n> > > This is what happens (\"linus\" is a local branch just pulled from kernel.org,\n> > > so it just contains one pack file and its index).\n> > > \n> > > $ cg-update linus\n> > > `/home/aegl/GIT/linus/.git/refs/heads/master' -> `.git/refs/heads/linus'\n> > > does not exist /home/aegl/GIT/linus/.git/objects/04/3d051615aa5da09a7e44f1edbb69\n> > > 798458e067\n> > > Cannot obtain needed object 043d051615aa5da09a7e44f1edbb69798458e067\n> > > while processing commit 0000000000000000000000000000000000000000.\n> > > cg-pull: objects pull failed\n> > \n> > Ok. The immediate fix is to just unpack the pack:\n> > \n> > \tmv .git/objects/pack/* .git/\n> > \tfor i in .git/*.pack; do git-unpack-objects < $i; done\n> > \n> > (or similar - the above is untested, but I think it should be obvious \n> > enough what I'm trying to do).\n> \n> This is evil on the bandwidth, since you'll keep refetching the packed\n> object (64MB of it) over and over.\n> \n> However, I've tried the above, and I get:\n> \n> $ mv .git/objects/pack/* .git/\n> $ for i in .git/*.pack; do git-unpack-objects < $i; done\n> Unpacking 55435 objects\n> fatal: inflate returned -3\n> \n> so it seems that the pack is corrupt... or something.\n> \n> $ md5sum .git/*.pack\n> 2be38f2947b99bcd088c1930122aadec .git/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack\n> \n> and git-fsck-cache produces lots and lots of:\n> \n> dangling tree fae688b62db0b553aae0bf17f0f70e93819dec2b\n> broken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347\n> to blob 008e19210e66f01fbaef1aba30243850766b8b12\n> broken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347\n> to blob edae09a4b021e353ab4fbba756e31492fbb8fd2e\n> broken link from tree faed7d798b84f107dbb9ff8fa97fb909c9ea5347\n> to blob d098b3ba35384fb912989348fd6da59820711ca4\n> ... etc ...\n\nAdditional information: x86 box, running FC2, cogito 0.12 built from\nthe src.rpm on kernel.org. Lots of disk space (blocks + inodes)\nremaining.\n\nPretty please can we stop breaking rmk's git/cogito/repos/scripts ?\n\n-- \nRussell King\n"},{"id":"5878","messageId":"7vpstrv8z6.fsf@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"20050709232955.B31045@flint.arm.linux.org.uk","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-09T23:46:21Z","receivedAt":"2005-07-09T23:46:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"RK\" == Russell King writes:\n\n>> $ mv .git/objects/pack/* .git/\n>> $ for i in .git/*.pack; do git-unpack-objects < $i; done\n>> Unpacking 55435 objects\n>> fatal: inflate returned -3\n>> \n>> so it seems that the pack is corrupt... or something.\n>> \n>> $ md5sum .git/*.pack\n>> 2be38f2947b99bcd088c1930122aadec .git/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack\n\nRK> Additional information: x86 box, running FC2, cogito 0.12 built from\nRK> the src.rpm on kernel.org. Lots of disk space (blocks + inodes)\nRK> remaining.\n\nHmph, I am worried about that inflate() failure. An x86 box,\nrunning Debian sarge, vanilla git without Cogito built from\nLinus tip. From here, it does not look like the pack corruption\nto me; unless you broke md5sum and found a collission, that is.\n\n: siamese; type git-unpack-objects\ngit-unpack-objects is /home/junio/bin/Linux/git-unpack-objects\n: siamese; ldd /home/junio/bin/Linux/git-unpack-objects\n libz.so.1 => /usr/lib/libz.so.1 (0xb7f8e000)\n libcrypto.so.0.9.7 =>\n /usr/lib/i686/cmov/libcrypto.so.0.9.7 (0xb7e8e000)\n libc.so.6 => /lib/tls/libc.so.6 (0xb7d59000)\n libdl.so.2 => /lib/tls/libdl.so.2 (0xb7d56000)\n /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0xb7fad000)\n: siamese; cd /opt/packrat/playpen/public/in-place/git/linux-2.6/\n: siamese; md5sum .git/objects/pack/pack-*.pack\n2be38f2947b99bcd088c1930122aadec .git/objects/pack/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack\n: siamese; cd ..\n: siamese; mkdir junk\n: siamese; cd junk\n: siamese; git-init-db\ndefaulting to local storage area\n: siamese; git-unpack-objects <../linux-2.6/.git/objects/pack/pack-e3117bbaf6a59cb53c3f6f0d9b17b9433f0e4135.pack\nUnpacking 55435 objects 100% (55434/55435) done\n"},{"id":"5879","messageId":"Pine.LNX.4.58.0507092158290.17536@g5.osdl.org","threadId":"1096","inReplyTo":"7vpstrv8z6.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-10T05:02:48Z","receivedAt":"2005-07-10T05:02:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 9 Jul 2005, Junio C Hamano wrote:\n>\n> >>>>> \"RK\" == Russell King writes:\n> \n> >> $ mv .git/objects/pack/* .git/\n> >> $ for i in .git/*.pack; do git-unpack-objects < $i; done\n> >> Unpacking 55435 objects\n> >> fatal: inflate returned -3\n\nAhh, damn. \n\n> >> so it seems that the pack is corrupt... or something.\n\nNo, I htink you're using cogito-0.12, and I fixed this one-liner that \ndidn't make it into cogito:\n\n\tdiff-tree 291ec0f2d2ce65e5ccb876b46d6468af49ddb82e (from 72347a233e6f3c176059a28f0817de6654ef29c7)\n\tAuthor: Linus Torvalds \n\tDate: Tue Jul 5 17:06:09 2005 -0700\n\t\n\t Don't special-case a zero-sized compression.\n\t\n\t zlib actually writes a header for that case, and while ignoring that\n\t header will get us the right data, it will also end up messing up our\n\t stream position. So we actually want zlib to \"uncompress\" even an empty\n\t object.\n\t\n\tdiff --git a/unpack-objects.c b/unpack-objects.c\n\t--- a/unpack-objects.c\n\t+++ b/unpack-objects.c\n\t@@ -55,8 +55,6 @@ static void *get_data(unsigned long size\n\t z_stream stream;\n\t void *buf = xmalloc(size);\n\t\n\t- if (!size)\n\t- return buf;\n\t memset(&stream, 0, sizeof(stream));\n\t\n\t stream.next_out = buf;\n\n(well, I guess it's a two-liner.).\n\nWhat happens is that there's one zero-sized blob in the kernel archive \nhistory, and when we pack it, we pack it as a 8-byte \"compressed\" thing \n(hey, zlib has a header, that's normal), but when we unpack it, because we \nnotice that the result is zero, we'd just skip the zlib header.\n\nWhich was wrong, because now the _next_ object will try to unpack at the \nwrong offset, and that explains why you get -3 (\"bad data\").\n\n\t\t\tLinus\n"},{"id":"5880","messageId":"Pine.LNX.4.58.0507092206480.17536@g5.osdl.org","threadId":"1096","inReplyTo":"m1pstrr8k1.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-10T05:11:07Z","receivedAt":"2005-07-10T05:11:07Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 9 Jul 2005, Eric W. Biederman wrote:\n> \n> I assume the problem with the mirror it model was simply there were\n> to many objects?\n\nYes.\n\n> > And then you really can use just rsync or wget or ncftpget or anything\n> > else that has a \"fetch recursively, optimizing existing objects\" mode.\n> \n> Sane. But with an intelligent fetcher and a little extra information a\n> dumb server should still be able to not fetch branches we care nothing\n> about. I think that extra information is simply commit object graph and\n> which packs those commit objects are in. I assume the commit graph\n> information will be fairly modest.\n\nWell, what I'd hope for is actually that eventually \"webgit\" will have \nsome machine-parseable sub-tree, and then you can have this kind of thing \ngenerated automatically.\n\nBut a _truly_ dumb server (ie one with no CGI at all, just \"raw data\", you\nreally end up with just effectively rsyncing it. Yes, you could create a\nnew \"commit index file\" every time you push, and maybe it's worth it, but \non the other hand, what's wrong with just rsyncing it all and parsing it \nlocally instead?\n\nPeople who use it for major development would all try to get the smart \nclient, even if it's \"just\" some webgit extension thing..\n\nDumb servers work, they just won't do any selective stuff. Big deal. \nThat's why they are dumb.\n\n\t\tLinus\n"},{"id":"5881","messageId":"Pine.LNX.4.58.0507092211470.17536@g5.osdl.org","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507092158290.17536@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-10T05:15:41Z","receivedAt":"2005-07-10T05:15:41Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 9 Jul 2005, Linus Torvalds wrote:\n> \n> No, I htink you're using cogito-0.12, and I fixed this one-liner that \n> didn't make it into cogito:\n\nBtw, this will only affect unpacking. The packed objects should be fine,\nand you'll never see this if you keep the index file around and have the\npack in .git/objects/pack, because then git won't ever do the \"streaming\" \nthing, it will look up exactly where the object is using the index, and it\ndoesn't matter that it doesn't look at the compressed data of a zero-sized\nobject.\n\nSo cogito isn't terminally broken, it just can't do the streaming unpack.\n\nAnd as Russell points out, unpacking the packs after downloading them is\nactually the wrong thing to do, because you break the rsync'ness of your\narchive, so you'll keep on downloading the pack-files over and over again.\n\nSo you can fix this by getting the current git release, but you probably \nshouldn't even care. Just use the pack-files as pack-files instead, and \nenjoy the higher performance and lower disk use ;).\n\n\t\tLinus\n"},{"id":"5882","messageId":"7veka7uqcr.fsf@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507092206480.17536@g5.osdl.org","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-10T06:28:36Z","receivedAt":"2005-07-10T06:28:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"LT\" == Linus Torvalds writes:\n>> On Sat, 9 Jul 2005, Eric W. Biederman wrote:\n>> I assume the commit graph information will be fairly modest.\n\nThat is true. My experience from the one I have been cooking,\nGitified 2.4.0->2.6.12-rc2 BKCVS export results in a bit shy of\n600KB commit ancestry information. The full development trail\nfor that repository contains 370152 objects among which 28237\nare commits; when packed into one pack-idx pair, it is around\na 170MB .pack with a 9MB .idx file.\n\nLT> But a _truly_ dumb server (ie one with no CGI at all, just \"raw data\", you\nLT> really end up with just effectively rsyncing it. Yes, you could create a\nLT> new \"commit index file\" every time you push, and maybe it's worth it, but \nLT> on the other hand, what's wrong with just rsyncing it all and parsing it \nLT> locally instead?\n\nNothing, and you convinced me to drop the one I have been\ncooking. Maybe its time to either change git-fetch-script to\nuse wget -r for http transport for objects part, perhaps?\n"},{"id":"5883","messageId":"20050710075548.A11765@flint.arm.linux.org.uk","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507092211470.17536@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-07-10T06:55:48Z","receivedAt":"2005-07-10T06:55:48Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Sat, Jul 09, 2005 at 10:15:41PM -0700, Linus Torvalds wrote:\n> So you can fix this by getting the current git release, but you probably \n> shouldn't even care. Just use the pack-files as pack-files instead, and \n> enjoy the higher performance and lower disk use ;).\n\nI would if I could, but my workflow involves having an untouched local\ncopy of your tree and several trees for each area.\n\nThis involves updates using relative paths, and as has already been\nfound elsewhere, this (with cogito 0.12) doesn't work with packed\nobjects yet.\n\n-- \nRussell King\n"},{"id":"5884","messageId":"7v4qb3uo63.fsf@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"20050710075548.A11765@flint.arm.linux.org.uk","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-10T07:15:48Z","receivedAt":"2005-07-10T07:15:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"RK\" == Russell King writes:\n\nRK> I would if I could, but my workflow involves having an untouched local\nRK> copy of your tree and several trees for each area.\n\nRK> This involves updates using relative paths, and as has already been\nRK> found elsewhere, this (with cogito 0.12) doesn't work with packed\nRK> objects yet.\n\nAs a workaround until Cogito gets updated, would it help to have\nthe environment variable GIT_ALTERNATE_OBJECT_DIRECTORIES\npointing at the untouched copy of Linus tree's .git/objects/\ndirectory? All your other trees would find the objects in your\ncopied-Linus tree (including packed one) available to them\nalready and hopefully pull breakage does not even have to touch\nthose objects.\n"},{"id":"5885","messageId":"20050710090914.B11765@flint.arm.linux.org.uk","threadId":"1096","inReplyTo":"20050709225818.A31045@flint.arm.linux.org.uk","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-07-10T08:09:14Z","receivedAt":"2005-07-10T08:09:14Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Sat, Jul 09, 2005 at 10:58:18PM +0100, Russell King wrote:\n> $ mv .git/objects/pack/* .git/\n> $ for i in .git/*.pack; do git-unpack-objects < $i; done\n> Unpacking 55435 objects\n> fatal: inflate returned -3\n\nThis morning's cg-update gave these new errors:\n\nreceiving file list ... done\n\nwrote 86 bytes read 192 bytes 556.00 bytes/sec\ntotal size is 410 speedup is 1.47\nMissing object of tag v2.6.11... different source (obsolete tag?)\nMissing object of tag v2.6.11-tree... different source (obsolete tag?)\nMissing object of tag v2.6.12... different source (obsolete tag?)\nMissing object of tag v2.6.12-rc2... different source (obsolete tag?)\nMissing object of tag v2.6.12-rc3... different source (obsolete tag?)\nMissing object of tag v2.6.12-rc4... different source (obsolete tag?)\nMissing object of tag v2.6.12-rc5... different source (obsolete tag?)\nMissing object of tag v2.6.12-rc6... different source (obsolete tag?)\nMissing object of tag v2.6.13-rc1... different source (obsolete tag?)\nMissing object of tag v2.6.13-rc2... different source (obsolete tag?)\n\n-- \nRussell King\n"},{"id":"5888","messageId":"20050710134624.B3279@flint.arm.linux.org.uk","threadId":"1096","inReplyTo":"7v4qb3uo63.fsf@assigned-by-dhcp.cox.net","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-07-10T12:46:24Z","receivedAt":"2005-07-10T12:46:24Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Sun, Jul 10, 2005 at 12:15:48AM -0700, Junio C Hamano wrote:\n> As a workaround until Cogito gets updated, would it help to have\n> the environment variable GIT_ALTERNATE_OBJECT_DIRECTORIES\n> pointing at the untouched copy of Linus tree's .git/objects/\n> directory? All your other trees would find the objects in your\n> copied-Linus tree (including packed one) available to them\n> already and hopefully pull breakage does not even have to touch\n> those objects.\n\nThat seems to work, thanks. I think this is a good idea anyway -\nit seems to mean that each working tree ends up with an empty set of\n.git/objects/* directories. When new work is done in a tree, the\ncorresponding objects then appear, and only these objects need\ntransferring upstream.\n\nIt means that rsync --delete-after can (in theory) be used when\nmaking changes available to the upstream maintainer.\n\n-- \nRussell King\n"},{"id":"5892","messageId":"20050710145954.GB24249@pasky.ji.cz","threadId":"1096","inReplyTo":"20050710090914.B11765@flint.arm.linux.org.uk","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-10T14:59:54Z","receivedAt":"2005-07-10T14:59:54Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Jul 10, 2005 at 10:09:14AM CEST, I got a letter\nwhere Russell King told me that...\n> On Sat, Jul 09, 2005 at 10:58:18PM +0100, Russell King wrote:\n> > $ mv .git/objects/pack/* .git/\n> > $ for i in .git/*.pack; do git-unpack-objects < $i; done\n> > Unpacking 55435 objects\n> > fatal: inflate returned -3\n> \n> This morning's cg-update gave these new errors:\n> \n> receiving file list ... done\n> \n> wrote 86 bytes read 192 bytes 556.00 bytes/sec\n> total size is 410 speedup is 1.47\n> Missing object of tag v2.6.11... different source (obsolete tag?)\n> Missing object of tag v2.6.11-tree... different source (obsolete tag?)\n> Missing object of tag v2.6.12... different source (obsolete tag?)\n> Missing object of tag v2.6.12-rc2... different source (obsolete tag?)\n> Missing object of tag v2.6.12-rc3... different source (obsolete tag?)\n> Missing object of tag v2.6.12-rc4... different source (obsolete tag?)\n> Missing object of tag v2.6.12-rc5... different source (obsolete tag?)\n> Missing object of tag v2.6.12-rc6... different source (obsolete tag?)\n> Missing object of tag v2.6.13-rc1... different source (obsolete tag?)\n> Missing object of tag v2.6.13-rc2... different source (obsolete tag?)\n\nOk, cg-pull didn't quite handle this. I've fixed it so that it should\nreasonably handle it now. Hopefully.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n be careful, some twit might quote you out of context..\n"},{"id":"5897","messageId":"Pine.LNX.4.58.0507100942020.17536@g5.osdl.org","threadId":"1096","inReplyTo":"20050710134624.B3279@flint.arm.linux.org.uk","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-10T16:51:16Z","receivedAt":"2005-07-10T16:51:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 10 Jul 2005, Russell King wrote:\n> \n> It means that rsync --delete-after can (in theory) be used when\n> making changes available to the upstream maintainer.\n\nI'd suggest against that from a safety standpoint (no backups), but what \nyou _can_ do is to upload only the objects I don't have. \n\nThis actually works - I already synced several weeks ago with Paul \nMackerras, who had made his ppc64 git thing contain only the objects that \nI didn't have.\n\nIn other words, if you have my tree pointed to by\nGIT_ALTERNATE_OBJECT_DIRECTORIES, and you populate your tree only with new\nfiles, you can actually upload that small \"sparsely populated\" tree as-is\n(without any of the objects that came from my tree), and I should be able\nto pull it as-is.\n\nWell, at least with rsync. I think my git \"pack\" send/receive thing might\nbe unhappy about a partial tree, but that's something I can fix, so if\nthis makes it easier for people (you can create a totally new tre _really_ \ncheaply and also upload it and move it around very cheaply), then I'm ok \nwith pulling from partial repositories, and I have indeed already done so \nin the past.\n\nBtw, if people start doing this, then I really think we want a \n\".git/config\" file, so that you can have different alternate object \ndirectories for different git directories without having to remember to \nset the environment variables all the time.\n\n\t\tLinus\n\t\n"},{"id":"5903","messageId":"20050710201504.A22477@flint.arm.linux.org.uk","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507100942020.17536@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-07-10T19:15:04Z","receivedAt":"2005-07-10T19:15:04Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Sun, Jul 10, 2005 at 09:51:16AM -0700, Linus Torvalds wrote:\n> On Sun, 10 Jul 2005, Russell King wrote:\n> > It means that rsync --delete-after can (in theory) be used when\n> > making changes available to the upstream maintainer.\n> \n> I'd suggest against that from a safety standpoint (no backups), but what \n> you _can_ do is to upload only the objects I don't have. \n> \n> This actually works - I already synced several weeks ago with Paul \n> Mackerras, who had made his ppc64 git thing contain only the objects that \n> I didn't have.\n\nOk, let's give this a go then. However, I'm not confident in this\nworking, especially after seeing the output of git-fsck-cache --full...\nand I've no idea _why_ it's complaining.\n\nI've pushed this (partial) tree out to\nmaster.kernel.org:~rmk/linux-2.6-arm.git\n\nBelow is the usual mail.\n\n$ export | grep GIT_\ndeclare -x GIT_ALTERNATE_OBJECT_DIRECTORIES=\"/home/rmk/git/linux-2.6/.git/objects\"\n$ git-fsck-cache --full\nerror: cannot read sha1_file for 0084227438c28d26bc2d089b1facc4675310f741\nbad sha1 entry '0084227438c28d26bc2d089b1facc4675310f741'\nerror: cannot read sha1_file for 008c1ddc1fc2854b64fcb49a40f1c933d116fb5c\nbad sha1 entry '008c1ddc1fc2854b64fcb49a40f1c933d116fb5c'\n...\nerror: cannot read sha1_file for 83c28d2c90fe720b5a315b89301cf3a519ffed88\nbad sha1 entry '83c28d2c90fe720b5a315b89301cf3a519ffed88'\ndangling commit 043d051615aa5da09a7e44f1edbb69798458e067\ndangling commit a92b7b80579fe68fe229892815c750f6652eb6a9\n$ grep . .git/refs/heads/*\n.git/refs/heads/master:ec6bced6c7b92904f5ead39c9c1b8dc734e6eff0\n.git/refs/heads/origin:f179bc77d09b9087bfc559d0368bba350342ac76\n.git/refs/heads/smp:053a7b5b7617a72d7c61b6f84196d1c0f79b9849\n$ cd $GIT_ALTERNATE_OBJECT_DIRECTORIES/../..\n$ git-fsck-cache --full\n$ \n\nCould this be because cogito doesn't know how to handle this setup\nproperly yet? Have I just destroyed my git tree by trying to apply\nstuff to it?\n\n---\n\nLinus, Andrew,\n\nPlease incorporate the latest ARM changes, which can be found at:\n\n\tmaster.kernel.org:/home/rmk/linux-2.6-arm.git\n\nThis will update the following files:\n\n arch/arm/mach-omap/Kconfig | 221 -----\n arch/arm/mach-omap/Makefile | 40 \n arch/arm/mach-omap/Makefile.boot | 4 \n arch/arm/mach-omap/board-generic.c | 100 --\n arch/arm/mach-omap/board-h2.c | 189 ----\n arch/arm/mach-omap/board-h3.c | 207 -----\n arch/arm/mach-omap/board-innovator.c | 282 ------\n arch/arm/mach-omap/board-netstar.c | 153 ---\n arch/arm/mach-omap/board-osk.c | 171 ----\n arch/arm/mach-omap/board-perseus2.c | 191 ----\n arch/arm/mach-omap/board-voiceblue.c | 258 ------\n arch/arm/mach-omap/clock.c | 1076 --------------------------\n arch/arm/mach-omap/clock.h | 112 --\n arch/arm/mach-omap/common.c | 549 -------------\n arch/arm/mach-omap/common.h | 36 \n arch/arm/mach-omap/dma.c | 1086 --------------------------\n arch/arm/mach-omap/fpga.c | 188 ----\n arch/arm/mach-omap/gpio.c | 762 ------------------\n arch/arm/mach-omap/irq.c | 219 -----\n arch/arm/mach-omap/leds-h2p2-debug.c | 144 ---\n arch/arm/mach-omap/leds-innovator.c | 103 --\n arch/arm/mach-omap/leds-osk.c | 198 ----\n arch/arm/mach-omap/leds.c | 61 -\n arch/arm/mach-omap/leds.h | 3 \n arch/arm/mach-omap/mcbsp.c | 685 ----------------\n arch/arm/mach-omap/mux.c | 163 ---\n arch/arm/mach-omap/ocpi.c | 114 --\n arch/arm/mach-omap/pm.c | 632 ---------------\n arch/arm/mach-omap/sleep.S | 314 -------\n arch/arm/mach-omap/time.c | 424 ----------\n arch/arm/mach-omap/usb.c | 593 --------------\n arch/arm/Kconfig | 6 \n arch/arm/Makefile | 6 \n arch/arm/configs/enp2611_defconfig | 20 \n arch/arm/configs/ixdp2400_defconfig | 20 \n arch/arm/configs/ixdp2401_defconfig | 20 \n arch/arm/configs/ixdp2800_defconfig | 20 \n arch/arm/configs/ixdp2801_defconfig | 20 \n arch/arm/configs/omap_h2_1610_defconfig | 117 +-\n arch/arm/mach-ixp2000/core.c | 55 -\n arch/arm/mach-ixp2000/enp2611.c | 1 \n arch/arm/mach-ixp2000/ixdp2x00.c | 1 \n arch/arm/mach-ixp2000/ixdp2x01.c | 1 \n arch/arm/mach-omap1/Kconfig | 144 +++\n arch/arm/mach-omap1/Makefile | 30 \n arch/arm/mach-omap1/Makefile.boot | 3 \n arch/arm/mach-omap1/board-generic.c | 99 ++\n arch/arm/mach-omap1/board-h2.c | 188 ++++\n arch/arm/mach-omap1/board-h3.c | 206 ++++\n arch/arm/mach-omap1/board-innovator.c | 281 ++++++\n arch/arm/mach-omap1/board-netstar.c | 152 +++\n arch/arm/mach-omap1/board-osk.c | 170 ++++\n arch/arm/mach-omap1/board-perseus2.c | 190 ++++\n arch/arm/mach-omap1/board-voiceblue.c | 257 ++++++\n arch/arm/mach-omap1/fpga.c | 188 ++++\n arch/arm/mach-omap1/id.c | 188 ++++\n arch/arm/mach-omap1/io.c | 115 ++\n arch/arm/mach-omap1/irq.c | 234 +++++\n arch/arm/mach-omap1/leds-h2p2-debug.c | 144 +++\n arch/arm/mach-omap1/leds-innovator.c | 103 ++\n arch/arm/mach-omap1/leds-osk.c | 194 ++++\n arch/arm/mach-omap1/leds.c | 61 +\n arch/arm/mach-omap1/leds.h | 3 \n arch/arm/mach-omap1/serial.c | 200 ++++\n arch/arm/mach-omap1/time.c | 436 ++++++++++\n arch/arm/mm/Kconfig | 2 \n arch/arm/mm/mm-armv.c | 4 \n arch/arm/plat-omap/Kconfig | 112 ++\n arch/arm/plat-omap/Makefile | 17 \n arch/arm/plat-omap/clock.c | 1323 ++++++++++++++++++++++++++++++++\n arch/arm/plat-omap/clock.h | 120 ++\n arch/arm/plat-omap/common.c | 135 +++\n arch/arm/plat-omap/cpu-omap.c | 128 +++\n arch/arm/plat-omap/dma.c | 1116 ++++++++++++++++++++++++++\n arch/arm/plat-omap/gpio.c | 762 ++++++++++++++++++\n arch/arm/plat-omap/mcbsp.c | 758 ++++++++++++++++++\n arch/arm/plat-omap/mux.c | 160 +++\n arch/arm/plat-omap/ocpi.c | 114 ++\n arch/arm/plat-omap/pm.c | 632 +++++++++++++++\n arch/arm/plat-omap/sleep.S | 314 +++++++\n arch/arm/plat-omap/usb.c | 593 ++++++++++++++\n include/asm-arm/arch-ixp2000/platform.h | 1 \n include/asm-arm/arch-omap/board-h2.h | 5 \n include/asm-arm/arch-omap/board-h3.h | 5 \n include/asm-arm/arch-omap/board-osk.h | 5 \n include/asm-arm/arch-omap/board.h | 12 \n include/asm-arm/arch-omap/common.h | 36 \n include/asm-arm/arch-omap/dma.h | 1 \n include/asm-arm/arch-omap/hardware.h | 24 \n include/asm-arm/arch-omap/irqs.h | 3 \n include/asm-arm/arch-omap/mux.h | 28 \n include/asm-arm/arch-omap/omap16xx.h | 32 \n include/asm-arm/arch-omap/system.h | 21 \n 93 files changed, 10164 insertions(+), 9450 deletions(-)\n\nthrough these changes:\n\nFrom: Tony Lindgren: Sun Jul 10 19:58:20 BST 2005\n\t\n\t[PATCH] ARM: 2803/1: OMAP update 11/11: Add cpufreq support\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch adds minimal cpufreq support for OMAP\n\ttaking advantage of the clock framework.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:19 BST 2005\n\t\n\t[PATCH] ARM: 2805/1: OMAP update 10/11: Update H2 defconfig\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch updates H2 defconfig.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:18 BST 2005\n\t\n\t[PATCH] ARM: 2804/1: OMAP update 9/11: Update OMAP arch files\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch by various OMAP developers syncs the OMAP\n\tspecific arch files with the linux-omap tree.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:17 BST 2005\n\t\n\t[PATCH] ARM: 2802/1: OMAP update 8/11: Update OMAP arch files\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch by various OMAP developers syncs the OMAP\n\tspecific arch files with the linux-omap tree.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:15 BST 2005\n\t\n\t[PATCH] ARM: 2812/1: OMAP update 7c/11: Move arch-omap to plat-omap\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch move common OMAP code from arch-omap to plat-omap\n\tdirectory.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:14 BST 2005\n\t\n\t[PATCH] ARM: 2809/1: OMAP update 7b/11: Move arch-omap to plat-omap\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch move common OMAP code from arch-omap to plat-omap\n\tdirectory.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:13 BST 2005\n\t\n\t[PATCH] ARM: 2807/1: OMAP update 7a/11: Move arch-omap to plat-omap\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch move common OMAP code from arch-omap to plat-omap\n\tdirectory.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:12 BST 2005\n\t\n\t[PATCH] ARM: 2801/1: OMAP update 6/11: Split OMAP1 common code into id, io and serial\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch by Juha Yrjölä and other OMAP developers splits\n\tOMAP1 specific common code into OMAP1 id, io, and serial\n\tcode in mach-omap1 directory.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:11 BST 2005\n\t\n\t[PATCH] ARM: 2806/1: OMAP update 5/11: Move board files into mach-omap1 directory\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch by Paul Mundt and other OMAP developers\n\tmoves OMAP1 board files into mach-omap1 directory.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:10 BST 2005\n\t\n\t[PATCH] ARM: 2799/1: OMAP update 4/11: Move OMAP1 LED code into mach-omap1 directory\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch by Paul Mundt and other OMAP developers\n\tmoves OMAP1 specific LED code into mach-omap1 directory.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:09 BST 2005\n\t\n\t[PATCH] ARM: 2800/1: OMAP update 3/11: Move OMAP1 core code into mach-omap1 directory\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch by Paul Mundt and other OMAP developers\n\tmoves OMAP1 specific IRQ, time, and FPGA code into\n\tmach-omap1 directory.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:08 BST 2005\n\t\n\t[PATCH] ARM: 2798/1: OMAP update 2/11: Change ARM Kconfig to support omap1 and omap2\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch by Paul Mundt and other OMAP developers modifies\n\tARM specific Kconfig to allow sharing code between OMAP1 and\n\tOMAP2 architectures.\n\tIn order to share code between OMAP1 and OMAP2, all OMAP1\n\tspecific code is moved into mach-omap1 directory in the\n\tfollowing patch. A new mach-omap2 directory will be added\n\tlater on.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Tony Lindgren: Sun Jul 10 19:58:06 BST 2005\n\t\n\t[PATCH] ARM: 2797/1: OMAP update 1/11: Update include files\n\t\n\tPatch from Tony Lindgren\n\t\n\tThis patch by various OMAP developers syncs the OMAP\n\tspecific include files with the linux-omap tree.\n\t\n\tSigned-off-by: Tony Lindgren \n\tSigned-off-by: Russell King \n\nFrom: Deepak Saxena: Sun Jul 10 19:44:55 BST 2005\n\t\n\t[PATCH] ARM: 2796/1: Fix ARMv5[TEJ] check in MMU initalization\n\t\n\tPatch from Deepak Saxena\n\t\n\tThe code in mm-armv.c checks for the condition (cpu_architecture()<= ARMv5)\n\tin a few places but should be checking for ARMv5TEJ as the MMU is shared\n\tacross all v5 variations.\n\t\n\tSigned-off-by: Deepak Saxena \n\tSigned-off-by: Russell King \n\nFrom: Lennert Buytenhek: Sun Jul 10 19:44:54 BST 2005\n\t\n\t[PATCH] ARM: 2795/1: update ixp2000 defconfigs\n\t\n\tPatch from Lennert Buytenhek\n\t\n\tUpdate the ixp2000 defconfigs from 2.6.12-git6 to 2.6.13-rc2.\n\t\n\tSigned-off-by: Lennert Buytenhek \n\tSigned-off-by: Russell King \n\nFrom: Lennert Buytenhek: Sun Jul 10 19:44:53 BST 2005\n\t\n\t[PATCH] ARM: 2793/1: platform serial support for ixp2000\n\t\n\tPatch from Lennert Buytenhek\n\t\n\tThis patch converts the ixp2000 serial port over to a platform\n\tserial device.\n\t\n\tSigned-off-by: Lennert Buytenhek \n\tSigned-off-by: Deepak Saxena \n\tSigned-off-by: Russell King \n\n\n\n-- \nRussell King\n"},{"id":"5907","messageId":"Pine.LNX.4.58.0507101228300.17536@g5.osdl.org","threadId":"1096","inReplyTo":"20050710201504.A22477@flint.arm.linux.org.uk","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-10T20:03:30Z","receivedAt":"2005-07-10T20:03:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 10 Jul 2005, Russell King wrote:\n> \n> Ok, let's give this a go then. However, I'm not confident in this\n> working, especially after seeing the output of git-fsck-cache --full...\n> and I've no idea _why_ it's complaining.\n\nOk, I've downloaded your objects, and it all looks fine. Nothing is \nmissing.\n\nSo something is wrong with the git-fsck-cache handling of \nGIT_ALTERNATE_OBJECT_DIRECTORIES, but I don't see what. Other programs \nhappily see the objects, git-fsck-cache for some reason does not, and thus \ncomplains. I'll try to figure it out.\n\nHowever, the more I try to make \"git-pack-objects\" work with a partial\nrepository, the less happy I am about it. It works wonderfully well with\nrsync:, since rsync just doesn't know that something is missing, but\ngenerating the object list when there are objects missing is quite hard.\n\nI can be trivial and say \"missing objects aren't interesting\", and it \nwould _work_, but that just doesn't make me happy. So I'm almost getting \nready to say \"let's not do this thing after all\".\n\n> Could this be because cogito doesn't know how to handle this setup\n> properly yet? Have I just destroyed my git tree by trying to apply\n> stuff to it?\n\nThis is definitely not a cogito problem, that fsck thing is in git itself. \n\nAnd no, you didn't destroy your tree - I just merged it, and the merged \nresults look fine and fsck correctly (and I get the same diffstat you do). \nIt's just a bug in fsck somewhere that makes it look bad.\n\nThat said, my inability to check the pack for completeness for a partial \narchive makes me think this partial rsync wasn't such a good idea after \nall. It _is_ convenient, though, so I'll have to think about the send-pack \nissues some more and see if I can resolve the difficulty without too much \nproblems. And clearly I need to fix git-fsck-cache.\n\nAnyway, I pushed out the merge, so don't worry about your tree. But let's \nhold off on this partial thing for a while, ok?\n\n\t\tLinus\n"},{"id":"5910","messageId":"20050710213209.B22477@flint.arm.linux.org.uk","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507101228300.17536@g5.osdl.org","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Russell King","fromEmail":"rmk@arm.linux.org.uk","sentAt":"2005-07-10T20:32:09Z","receivedAt":"2005-07-10T20:32:09Z","isPatch":false,"sender":{"key":"rmk@arm.linux.org.uk","avatar":null},"body":"On Sun, Jul 10, 2005 at 01:03:30PM -0700, Linus Torvalds wrote:\n> Anyway, I pushed out the merge, so don't worry about your tree. But let's \n> hold off on this partial thing for a while, ok?\n\nThanks, that's good news. I was fearing having to reconstruct stuff.\n\nDo you want me to re-populate linux-2.6-arm.git to be fully populated\nor are you happy for it to just grow the new objects as they become\navailable?\n\n-- \nRussell King\n"},{"id":"5914","messageId":"Pine.LNX.4.58.0507101438230.17536@g5.osdl.org","threadId":"1096","inReplyTo":"20050710213209.B22477@flint.arm.linux.org.uk","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-10T21:40:11Z","receivedAt":"2005-07-10T21:40:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 10 Jul 2005, Russell King wrote:\n>\n> On Sun, Jul 10, 2005 at 01:03:30PM -0700, Linus Torvalds wrote:\n> > Anyway, I pushed out the merge, so don't worry about your tree. But let's \n> > hold off on this partial thing for a while, ok?\n> \n> Thanks, that's good news. I was fearing having to reconstruct stuff.\n> \n> Do you want me to re-populate linux-2.6-arm.git to be fully populated\n> or are you happy for it to just grow the new objects as they become\n> available?\n\nWe can try just letting it grow. That way I'll have more reason to try to \nmake the partial-repo thing just work.\n\n\t\tLinus\n"},{"id":"5915","messageId":"20050710214849.GA18608MdfPADPa@garage.linux.student.kuleuven.ac.be","threadId":"1096","inReplyTo":"m1pstrr8k1.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Sven Verdoolaege","fromEmail":"skimo@kotnet.org","sentAt":"2005-07-10T21:48:50Z","receivedAt":"2005-07-10T21:48:50Z","isPatch":true,"sender":{"key":"skimo@kotnet.org","avatar":null},"body":"On Sat, Jul 09, 2005 at 03:09:02PM -0600, Eric W. Biederman wrote:\n> The current intelligent fetch currently has a problem that it cannot\n> be used to bootstrap a repository. If you don't have an ancestor\n> of what you are fetching you can't fetch it.\n> \n\nNot sure if this is what you want, but you could use the\nfollowing gitweb patch (to be applied on top of my previous\npatches) to get a git tree snapshot for bootstrapping.\n\nhttp://www.liacs.nl/~sverdool/gitweb.cgi?p=gitweb.git;a=summary\nhttp://www.liacs.nl/~sverdool/gitweb.git/\n\nskimo\n--\nSupport pack snapshots.\n\n---\ncommit f76a442a0e2166b3f17db0e496545a600a33f94c\ntree f8f089ab738864e69e0155b10262dbec832b4a11\nparent 8392280de17a89a451c1f7db4e268f2047d4aa83\nauthor Sven Verdoolaege Sun, 10 Jul 2005 23:56:42 +0200\ncommitter Sven Verdoolaege Sun, 10 Jul 2005 23:56:42 +0200\n\n gitweb.cgi | 11 ++++++++---\n 1 files changed, 8 insertions(+), 3 deletions(-)\n\ndiff --git a/gitweb.cgi b/gitweb.cgi\n--- a/gitweb.cgi\n+++ b/gitweb.cgi\n@@ -2058,8 +2058,9 @@ sub git_snapshot {\n \t \"\\n\" .\n \t \"\\n\";\n \tmy %types = (\n-\t\t'Bzipped tar archive' => 'tar.bz2',\n-\t\t'Gzipped tar archive' => 'tar.gz',\n+\t\t'Source tree (bzipped tar archive)' => 'tar.bz2',\n+\t\t'Source tree (gzipped tar archive)' => 'tar.gz',\n+\t\t'Git tree (pack file)' => 'pack',\n \t);\n \tmy $alternate = 0;\n \tfor my $type (sort keys %types) {\n@@ -2094,6 +2095,7 @@ sub git_serve_snapshot {\n \tmy %info = (\n \t\t'tar.bz2' => [ 'application/x-bzip2', 'bzip2' ],\n \t\t'tar.gz' => [ 'application/x-gzip', 'gzip' ],\n+\t\t'pack' => [ 'application/x-git-pack' ],\n \t);\n \tif (!exists $info{$st}) {\n \t\tdie_error(undef, \"Unknown snapshot type.\");\n@@ -2101,7 +2103,10 @@ sub git_serve_snapshot {\n \tmy ($type, $zip) = @{$info{$st}};\n \tprint $cgi->header(-type => $type, \n \t\t\t -attachment => \"$project-$hash.$st\");\n-\topen my $fd, \"-|\", \"$gitbin/git-tar-tree $hash '$project-$hash' | $zip\" \n+\topen my $fd, \"-|\", ($st eq 'pack' ?\n+\t\t\"$gitbin/git-rev-list --max-count=1 --objects $hash | \". \n+\t\t\t\"$gitbin/git-pack-objects --stdout\" :\n+\t\t\"$gitbin/git-tar-tree $hash '$project-$hash' | $zip\")\n \t\tor return;\n \tundef $/;\n \tprint <$fd>;\n"},{"id":"5919","messageId":"Pine.LNX.4.58.0507101517370.17536@g5.osdl.org","threadId":"1096","inReplyTo":"m1pstrr8k1.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-10T22:36:01Z","receivedAt":"2005-07-10T22:36:01Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sat, 9 Jul 2005, Eric W. Biederman wrote:\n> \n> The current intelligent fetch currently has a problem that it cannot\n> be used to bootstrap a repository. If you don't have an ancestor\n> of what you are fetching you can't fetch it.\n\nSure you can.\n\nSee the current \"git clone\". It's actually quite good, it's a pleasure to \nuse now that it gives updates on how much it has done.\n\nJust do\n\n\tgit clone src dest\n\nto try it out. It starts out silent (for big repositories) because it \ntakes a while to get the whole rev list, but once it gets going it's quite \nnice and gives a nice progress report..\n\nIt uses the exact same server side code that \"git-fetch-pack\" does (ie it\njust starts \"git-upload-pack\" on the server).\n\nNow, one thing you cannot do is to start a totally new _project_ on the\nserver side. In order to do a \"git-send-pack\", you need to first create a\ndirectory and do a \"git-init-db\" on the remote side.\n\nSo to create a new project, what you need to do is\n\n\tsrc$ ssh target\n\n\ttarget$ mkdir new-project\n\ttarget$ cd new-project\n\ttarget$ git-init-db\n\ttarget$ exit\n\n\tsrc$ git-send-pack target:new-project master\n\nand you've now sent your \"master\" branch to the new project at \n\"target:new-project\".\n\nYou can even populate multiple branches at a time: just list them all (you\ndo have to list them, because by default \"git-send-pack\" will update the\n_common_ branches, and since the other end is empty, there obviously are\nno common branches to start with).\n\nAhh, you should even be able to automate the sending of all branches by\ndoing\n\n\tgit-send-pack target:new-project $(cd .git ; find refs -type f)\n\nI think - that will end up being equivalent to a \"reverse clone\".\n\nThe smart clients are doing pretty damn well, I think.\n\n\t\t\tLinus\n"},{"id":"5937","messageId":"7vwtnxvnbs.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1096","inReplyTo":"7vfyumj8hn.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH] Check packs and then files.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-11T07:00:55Z","receivedAt":"2005-07-11T07:00:55Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This reverses the order of object lookup, to check pack index\nfirst and then go to the filesystem to find .git/objects/??/\nhierarchy. When most of the objects are packed, this saves\nquite many stat() calls and negative dcache entries; while the\nprice this approach has to pay is negligible, even when most of\nthe objects are outside pack, because checking pack index file\nis quite cheap.\n\nSigned-off-by: Junio C Hamano \n---\n\n sha1_file.c | 9 ++++++---\n 1 files changed, 6 insertions(+), 3 deletions(-)\n\n0394e2b0ed5b197510340f187d02ef2274b6cad2\ndiff --git a/sha1_file.c b/sha1_file.c\n--- a/sha1_file.c\n+++ b/sha1_file.c\n@@ -1035,14 +1035,17 @@ void * read_sha1_file(const unsigned cha\n {\n \tunsigned long mapsize;\n \tvoid *map, *buf;\n+\tstruct pack_entry e;\n \n+\tif (find_pack_entry(sha1, &e))\n+\t\treturn read_packed_sha1(sha1, type, size);\n \tmap = map_sha1_file_internal(sha1, &mapsize);\n \tif (map) {\n \t\tbuf = unpack_sha1_file(map, mapsize, type, size);\n \t\tmunmap(map, mapsize);\n \t\treturn buf;\n \t}\n-\treturn read_packed_sha1(sha1, type, size);\n+\treturn NULL;\n }\n \n void *read_object_with_reference(const unsigned char *sha1,\n@@ -1343,9 +1346,9 @@ int has_sha1_file(const unsigned char *s\n \tstruct stat st;\n \tstruct pack_entry e;\n \n-\tif (find_sha1_file(sha1, &st))\n+\tif (find_pack_entry(sha1, &e))\n \t\treturn 1;\n-\treturn find_pack_entry(sha1, &e);\n+\treturn find_sha1_file(sha1, &st) ? 1 : 0;\n }\n \n int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, const char *type)\n"},{"id":"5948","messageId":"m1irzh74m0.fsf@ebiederm.dsl.xmission.com","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507101517370.17536@g5.osdl.org","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-11T15:19:03Z","receivedAt":"2005-07-11T15:19:03Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Sat, 9 Jul 2005, Eric W. Biederman wrote:\n>> \n>> The current intelligent fetch currently has a problem that it cannot\n>> be used to bootstrap a repository. If you don't have an ancestor\n>> of what you are fetching you can't fetch it.\n>\n> Sure you can.\n>\n> See the current \"git clone\". It's actually quite good, it's a pleasure to \n> use now that it gives updates on how much it has done.\n>\n> Just do\n>\n> \tgit clone src dest\n\nSorry, somehow I just missed that, and then I noticed just a little\nbefore you sent out your email.\n\nI'm having the worst time putting together a mental model of how git\nworks, and the documentation is spotty enough that it hasn't been\nhelpful. So I am wading through the code. It seems every time I turn\na corner there is another rough spot.\n\nI guess I was expecting to pull from one tree into another unrelated\ntree. Getting a tree with two heads and then be able to merge them\ntogether.\n\nA couple of questions.\n\n1) Does git-clone-script when packed copy the entire repository\n or just take a couple of slices of the tree where you have\n references?\n\n2) Is there a way for a pack to create deltas against objects\n that are not in the tree? For a dumb repository making incremental\n changes this is ideal.\n\nEric\n"},{"id":"5950","messageId":"Pine.LNX.4.58.0507110928070.17536@g5.osdl.org","threadId":"1096","inReplyTo":"m1irzh74m0.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-11T16:38:49Z","receivedAt":"2005-07-11T16:38:49Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Eric W. Biederman wrote:\n> \n> I guess I was expecting to pull from one tree into another unrelated\n> tree. Getting a tree with two heads and then be able to merge them\n> together.\n\nYou can do it, but you have to do it by hand. It's a valid operation, but \nit's not an operation I want people to do by mistake, so it's not \nsomething the trivial helper scripts help with.\n\nThe way to do it by hand is to just use something stupid that doesn't\nunderstand what it's doing anyway, and just copy the files over. \"cp -a\" \nor \"rsync\" works fine. Then just do \"git resolve\" by hand. It's not very \nhard at all, but it's definitely something that should be a special case.\n\n> A couple of questions.\n> \n> 1) Does git-clone-script when packed copy the entire repository\n> or just take a couple of slices of the tree where you have\n> references?\n\nIt only gets the objects needed for the references, nothing more.\n\nSo if you only get one branch, it will leave the objects that are specific \nto other branches alone.\n\n> 2) Is there a way for a pack to create deltas against objects\n> that are not in the tree? For a dumb repository making incremental\n> changes this is ideal.\n\nA pack can only have deltas against objects in that pack. It caan't even \nhave deltas to other objects in the same tree, it literally is only \n_within_ a pack. This is so that each pack is totally independent: you can \nalways unpack (and verify) the objects in a pack _without_ having anything \nelse (of course, the end result is often not a full project, and you won't \nhave any references, but at least the _objects_ are valid).\n\nI don't want to have deltas to outside the pack, because while it's \nobviously very nice from a size packing standpoint, it's totally horrid \nfrom an infrastructure standpoint. It would make it possible to have \ncircular dependencies (ie deltas against each other) that could only be \nresolved by having a third pack (or the unpacked object).\n\nIt would also means that you may have to have two packs mapped at the same\ntime to unpack them, which was very much against what I was aiming for: I\nthink that in the long run, for truly huge projects, you'd want to have a\nhistory of packs, each maybe a gigabyte in size, and you may be in the \nsituation that you simply cannot have two packs mapped at the same time \nbecause you don't have enough virtual memory for it.\n\nSo then inter-pack deltas would mean that you'd have to have \"partial pack \nmapping\" etc horrid special case logic. Right now, because a pack is \nalways self-sufficient, you know that in order to unpack an object, if you \nfind it in the index file, you will be able to unpack it by just mapping \nthat pack and going off..\n\nSo the rule is: don't pack too often. The unpacked objects are actually \nworking really really well as long as you don't have tens of thousands of \nthem. Having a few hundred (or even a few thousand) unpacked objects is \nnot a problem at all. Then you do a \"git repack\" when it starts getting \nuncomfortable, and you you continue.\n\n\t\t\tLinus\n"},{"id":"5954","messageId":"Pine.LNX.4.58.0507111045380.17536@g5.osdl.org","threadId":"1096","inReplyTo":"m1irzh74m0.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-11T17:53:32Z","receivedAt":"2005-07-11T17:53:32Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Eric W. Biederman wrote:\n> \n> I'm having the worst time putting together a mental model of how git\n> works, and the documentation is spotty enough that it hasn't been\n> helpful. So I am wading through the code. It seems every time I turn\n> a corner there is another rough spot.\n\nBtw, I know I'm bad at writing docs, but what I _do_ enjoy doing is\nanswering reasonably specific technical questions, and maybe somebody else\ncan write docs by taking advantage of me that way.\n\nI tried to write the tutorial in a way that it also tries to explain how\ngit works (not just a \"do this\", but a \"you update the index file and then\nwrite the result out as a tree object\"), but it obviously covers a fairly\nlimited part of what git actually can do, and at the same time it doesn't\ngo into a lot of detail.\n\nAnd part of that is not just my inability to write documentation, it's\nalso that I just have the wrong \"view\" of the project, ie I probably just\ntake a lot of things for granted and consider them obvious, even though\nthey aren't, and then I probably occasionally explain things that aren't\nworth explaining, because either they _are_ obvious, or people just don't\ncare and they are irrelevant.\n\nI'd love to see somebody write up more of a \"this is how you use git\" kind\nof tutorial, _and_ on the other hand more of a low-level explanation of\nthe notion of an object store where objects refer to each other by their\nSHA1 names, and how that is represented in the filesystem and/or in packs. \n\nSomething with a few pictures would be great (ie screenshots of gitk, but\nalso something that tries to just visually show hot tags point to commits\nthat point to parents and trees, and trees pointing to other trees and\nthen blobs).\n\nAll things that I'm a complete idiot at, but that would help users \nvisualize what the heck git is actually _doing_, so that they don't just \nparrot some magic command line that they don't understand, but can \nactually reason about what they are doing.\n\nI think a lot of people do understand this, but yes, the docs are kind of \nlacking.\n\n\t\t\tLinus\n"},{"id":"5962","messageId":"20050711203042.GR5324@shell0.pdx.osdl.net","threadId":"1096","inReplyTo":"20050710145954.GB24249@pasky.ji.cz","subject":"Re: [ANNOUNCE] Cogito-0.12","fromName":"Chris Wright","fromEmail":"chrisw@osdl.org","sentAt":"2005-07-11T20:30:42Z","receivedAt":"2005-07-11T20:30:42Z","isPatch":false,"sender":{"key":"chrisw@sous-sol.org","avatar":null},"body":"* Petr Baudis (pasky@suse.cz) wrote:\n> Ok, cg-pull didn't quite handle this. I've fixed it so that it should\n> reasonably handle it now. Hopefully.\n\nIs this plus the zero-sized fix worth making cogito-0.12-2 rpm release?\n\nIOW, these two patches...\n\ndiff-tree 291ec0f2d2ce65e5ccb876b46d6468af49ddb82e (from 72347a233e6f3c176059a28f0817de6654ef29c7)\ntree a1d3a4e01516f1d924c407a9e42a6df0d13b43b6\nparent 72347a233e6f3c176059a28f0817de6654ef29c7\nauthor Linus Torvalds 1120608369 -0700\ncommitter Linus Torvalds 1120608369 -0700\n\n Don't special-case a zero-sized compression.\n \n zlib actually writes a header for that case, and while ignoring that\n header will get us the right data, it will also end up messing up our\n stream position. So we actually want zlib to \"uncompress\" even an empty\n object.\n\ndiff --git a/unpack-objects.c b/unpack-objects.c\n--- a/unpack-objects.c\n+++ b/unpack-objects.c\n@@ -55,8 +55,6 @@ static void *get_data(unsigned long size\n \tz_stream stream;\n \tvoid *buf = xmalloc(size);\n \n-\tif (!size)\n-\t\treturn buf;\n \tmemset(&stream, 0, sizeof(stream));\n \n \tstream.next_out = buf;\ndiff-tree 7b754d7f0800117cd97afa5e806e50c7fd16d8c1 (from a2503fd85e6bb7f25d134a5634a1d8efc93fee5f)\nAuthor: Petr Baudis \nDate: Sun Jul 10 16:59:28 2005 +0200\n\n Fix cg-pull to handle packed tags properly\n \n If the objects referenced by refs/tags/ are packed, it wouldn't detect\n them properly and instead try to refetch them, but they are likely to\n be packed on the other side as well and that makes them impossible to\n be fetched explicitly (which isn't a problem as long as they are the\n same branch).\n \n Also, the fetch failure message was confusing.\n \n Reported by Russel King.\n\ndiff --git a/cg-pull b/cg-pull\n--- a/cg-pull\n+++ b/cg-pull\n@@ -294,13 +294,14 @@ $fetch -i -s -u -d \"$uri/refs/tags\" \"$_g\n \tfor tag in *; do\n \t\t[ \"$tag\" = \"*\" ] && break\n \t\ttagid=$(cat $tag)\n-\t\ttagfile=objects/${tagid:0:2}/${tagid:2}\n-\t\t[ -s \"../../$tagfile\" ] && continue\n+\t\tGIT_DIR=../../../$_git git-cat-file -t \"$tagid\" >/dev/null 2>&1 && continue\n \t\techo -n \"Missing object of tag $tag... \"\n+\t\t# In case it's not in a packfile...\n+\t\ttagfile=objects/${tagid:0:2}/${tagid:2}\n \t\tif $fetch -i -s \"$uri/$tagfile\" \"../../$tagfile\" 2>/dev/null >&2; then\n \t\t\techo \"retrieved\"\n \t\telse\n-\t\t\techo \"different source (obsolete tag?)\"\n+\t\t\techo \"unable to retrieve\"\n \t\tfi\n \tdone\n )\n"},{"id":"5991","messageId":"m13bqk26pp.fsf@ebiederm.dsl.xmission.com","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507110928070.17536@g5.osdl.org","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T00:44:50Z","receivedAt":"2005-07-12T00:44:50Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 11 Jul 2005, Eric W. Biederman wrote:\n>> \n>> I guess I was expecting to pull from one tree into another unrelated\n>> tree. Getting a tree with two heads and then be able to merge them\n>> together.\n>\n> You can do it, but you have to do it by hand. It's a valid operation, but \n> it's not an operation I want people to do by mistake, so it's not \n> something the trivial helper scripts help with.\n>\n> The way to do it by hand is to just use something stupid that doesn't\n> understand what it's doing anyway, and just copy the files over. \"cp -a\" \n> or \"rsync\" works fine. Then just do \"git resolve\" by hand. It's not very \n> hard at all, but it's definitely something that should be a special case.\n\nOk. Only the dumb methods are allowed.\n\n>> A couple of questions.\n>> \n>> 1) Does git-clone-script when packed copy the entire repository\n>> or just take a couple of slices of the tree where you have\n>> references?\n>\n> It only gets the objects needed for the references, nothing more.\n>\n> So if you only get one branch, it will leave the objects that are specific \n> to other branches alone.\n\nHmm. As I recall reading the code it grabs everything that is\nin .git/refs/*. So I would actually expect it to grab all of the\nbranches. My real question was different. With a clone it\nappears to just get the objects used to compose a tree object,\nbut none of the history available by looking at the commit\nparents is obtained. Not at all what I would expect for\nan operation named clone.\n\nEric\n"},{"id":"5996","messageId":"Pine.LNX.4.58.0507111810380.17536@g5.osdl.org","threadId":"1096","inReplyTo":"m13bqk26pp.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T01:14:46Z","receivedAt":"2005-07-12T01:14:46Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Eric W. Biederman wrote:\n>\n> Ok. Only the dumb methods are allowed.\n\nWell, no, you can actually do git-clone-pack by hand in that git archive,\nand it will use the smart packing to get the other end, even if it is\ntotally unrelated to the current project.\n\nBut you have to do it by \"hand\" in the sense that none of the nice helper\nscripts will help you to do this. Merging two unrelated projects really is\na very special operation. I've done it once (gitk into git), and I don't\nthink we'll see it done very many times again.\n\n> > So if you only get one branch, it will leave the objects that are specific \n> > to other branches alone.\n> \n> Hmm. As I recall reading the code it grabs everything that is\n> in .git/refs/*.\n\nOnly by default.\n\nIf you specify a branch (or five) git-clone-pack will grab only that\nbranch.\n\nHowever, I don't think \"git clone\" (the script) even exposes that, so\nright now you'd not even see it - \"git clone\" only exposes the \"get all\nthe branches by default\" behaviour.\n\n\t\tLinus\n"},{"id":"6001","messageId":"m164vg7nqo.fsf@ebiederm.dsl.xmission.com","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507111810380.17536@g5.osdl.org","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T02:38:07Z","receivedAt":"2005-07-12T02:38:07Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 11 Jul 2005, Eric W. Biederman wrote:\n>> > So if you only get one branch, it will leave the objects that are specific \n>> > to other branches alone.\n>> \n>> Hmm. As I recall reading the code it grabs everything that is\n>> in .git/refs/*.\n>\n> Only by default.\n>\n> If you specify a branch (or five) git-clone-pack will grab only that\n> branch.\n>\n> However, I don't think \"git clone\" (the script) even exposes that, so\n> right now you'd not even see it - \"git clone\" only exposes the \"get all\n> the branches by default\" behaviour.\n\nYep.\n\nThe question:\nDoes git-upload-pack which gets it's list of objects\nwith \"git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3\"\nget any history beyond the top of tree of each branch. \n\nAs I read the code it does not. \n\nIf the code does not get the history I see some problems.\nIn particular merging with a branch is hard because we\nmay not pull the common history point.\n\nEric\n"},{"id":"6005","messageId":"Pine.LNX.4.58.0507112018560.17536@g5.osdl.org","threadId":"1096","inReplyTo":"m164vg7nqo.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T03:21:12Z","receivedAt":"2005-07-12T03:21:12Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Eric W. Biederman wrote:\n> \n> The question:\n> Does git-upload-pack which gets it's list of objects\n> with \"git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3\"\n> get any history beyond the top of tree of each branch. \n> \n> As I read the code it does not. \n\nIt does. It gets all the history necessary for each branch. git-rev-list\nwill walk the whole history until it hits commits that as been marked as\nuninteresting (or the parents of commits that have been marked as\nuninteresting), and those are the ones that the receiver already has, of\ncourse.\n\nSo after you get a pack, you have all the history for all the branches you \ngot.\n\nA branch you _didn't_ get, you don't get any history for, of course, but \nthat doesn't matter. You'll get that history if you ever pull the branch \nlater.\n\n\t\t\tLinus\n"},{"id":"6006","messageId":"m1wtnw66cc.fsf@ebiederm.dsl.xmission.com","threadId":"1096","inReplyTo":"Pine.LNX.4.58.0507112018560.17536@g5.osdl.org","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Eric W. Biederman","fromEmail":"ebiederm@xmission.com","sentAt":"2005-07-12T03:39:15Z","receivedAt":"2005-07-12T03:39:15Z","isPatch":true,"sender":{"key":"ebiederm@xmission.com","avatar":"https://avatars.githubusercontent.com/u/7477136?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 11 Jul 2005, Eric W. Biederman wrote:\n>> \n>> The question:\n>> Does git-upload-pack which gets it's list of objects\n>> with \"git-rev-list --objects needed1 needed2 needed3 ^has1 ^has2 ^has3\"\n>> get any history beyond the top of tree of each branch. \n>> \n>> As I read the code it does not. \n>\n> It does. It gets all the history necessary for each branch. git-rev-list\n> will walk the whole history until it hits commits that as been marked as\n> uninteresting (or the parents of commits that have been marked as\n> uninteresting), and those are the ones that the receiver already has, of\n> course.\n\nOk. So the intention is sane then.\n\nLooking closer it appears that commit_list_insert is recursive\nand that is what I missed.\n\n> So after you get a pack, you have all the history for all the branches you \n> got.\n>\n> A branch you _didn't_ get, you don't get any history for, of course, but \n> that doesn't matter. You'll get that history if you ever pull the branch \n> later.\n\nRight. Things work well if you have all of the history.\n\n\nEric\n"},{"id":"6014","messageId":"Pine.LNX.4.58.0507112141310.17536@g5.osdl.org","threadId":"1096","inReplyTo":"m1wtnw66cc.fsf@ebiederm.dsl.xmission.com","subject":"Re: [PATCH] rev-list: add \"--full-objects\" flag.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-12T04:48:40Z","receivedAt":"2005-07-12T04:48:40Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 11 Jul 2005, Eric W. Biederman wrote:\n> \n> Looking closer it appears that commit_list_insert is recursive\n> and that is what I missed.\n\nActually, it's \"pop_most_recent_commit()\" that ends up being the\n\"recursive\" part: it will pop the top-most entry, but as it is popping it \nit will push the parents of that entry onto the same list.\n\nSo basically, you can get a list of all history by first inserting the top \nentry, and then doing \"pop_most_recent_commit()\" until the list is empty.\n\nNow, git-rev-list ends up being slightly more complex than that, since it\nhas support for multiple starting points, and marking commits (and thus\ntheir parents) uninteresting, and two other sorting methods in addition to \nthe default \"by date\" thing.\n\nAnd then there's all the issues about tags, trees and blobs, and their\nvisibility as a function of the commits that are visible and the command\nline arguments..\n\nIn fact, it turns out that git-rev-list is really the real heart of \"git\". \nAlmost everything else revolves around it. Once you grok git-rev-list, you\nprobably really grok git.\n\n\t\t\tLinus\n"}]}