{"thread":{"id":"2341","subject":"GIT 0.99.9c","startedAt":"2005-11-04T04:04:02Z","lastAt":"2005-11-05T14:00:08Z","messageCount":5,"participants":["Junio C Hamano","Jeff Garzik","Santi Béjar"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"11111","messageId":"7vwtjp2h59.fsf@assigned-by-dhcp.cox.net","threadId":"2341","inReplyTo":null,"subject":"GIT 0.99.9c","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-04T04:04:02Z","receivedAt":"2005-11-04T04:04:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"GIT 0.99.9c is found at http://kernel.org/pub/software/scm/git/\nas usual.  It includes the following fixes and documentation\nupdates since 0.99.9b:\n\n\tAlex Riesen:\n\t      remove CR/LF from .gitignore\n\n\tJon Loeliger\n\t      Illustration: \"Fundamental Git Index Operations\"\n\t      Illustration: \"Git Diff Types\"\n\t      Illustration: \"Commit DAG Revision Naming\"\n\n\tJunio C Hamano:\n\t      Do not put automatic merge message after signed-off-by line.\n\t      git-clone: do not forget to create origin branch.\n\t      Make test-date buildable again.\n\t      Do not fail on hierarchical branch names.\n\t      Ignore '\\r' at the end of line in $GIT_DIR/config\n\t      Be careful when dereferencing tags (credits Pasky).\n\t      Document --since and --until options to rev-parse.\n\t      Add --no-commit to git-merge/git-pull.\n\t      Add 'ours' merge strategy.\n\t      git-merge-ours: make sure our index matches HEAD\n\t      GIT 0.99.9c\n\n\tPeter Eriksen:\n\t      Clean up the SunOS Makefile rule\n\nThe slow and steady march toward 1.0 continues.  \n\nI plan to do another full sweep in the documentation directory\non my next GIT day.\n\nOn the proposed updates front, I am hoping to include Nick's\nhttp-push using DAV in the \"master\" branch soon.  And I would\nappreciate somebody who actually uses svnimport to Ack on\nYaacov's svnimport fix.\n"},{"id":"11112","messageId":"436AE6A3.4040103@pobox.com","threadId":"2341","inReplyTo":"7vwtjp2h59.fsf@assigned-by-dhcp.cox.net","subject":"RFC: GIT networked storage","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-11-04T04:42:11Z","receivedAt":"2005-11-04T04:42:11Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"\nHere's an experiment I've been dying to try.\n\nThe current \"tracker-less\" BitTorrent[1] employs a distributed hash \ntable[2] called Kademlia, where the total content is spread across a \nbunch of computers on the network.  I kinda prefer TANGLE[3] to Kademlia.\n\nAnyway, I was thinking that it would be a neat experiment to add simple \nTANGLE-like peer-to-peer code, to enable git to query \"the git network \nhash table\" for content.\n\nComments, or any pre-code-creation objections?\nHow easy is it to add a new storage backend to git?\n\nTo restrict unlimited uploading, I'm thinking that I'll want the system \nto fall back to {www,git,rsync}.kernel.org as the original source of \ncontent.  [though the code will obviously be generic, and not hardcode \n*.kernel.org policy]\n\nThanks,\n\n\tJeff\n\n\n\n[1] http://www.bittorrent.com/trackerless.html\n[2] http://www.etse.urv.es/~cpairot/dhts.html\n[3] http://www.nicemice.net/amc/research/tangle/\n"},{"id":"11113","messageId":"7vd5lg22gm.fsf@assigned-by-dhcp.cox.net","threadId":"2341","inReplyTo":"436AE6A3.4040103@pobox.com","subject":"Re: RFC: GIT networked storage","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-04T09:21:13Z","receivedAt":"2005-11-04T09:21:13Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff Garzik <jgarzik@pobox.com> writes:\n\n> How easy is it to add a new storage backend to git?\n\nAlmost everything is contained within sha1_file.c.\n\nObject creation side is simple -- everybody who creates an\nobject (e.g update-index registering blobs, write-tree writing\nthe toplevel and intermediate level trees, commit-tree building\na commit object, unpack-objects exploding a pack) goes through\nwrite_sha1_file(), which checks if the object is already\navailable using has_sha1_file() and creates a new object in the\nlocal .git/objects/?? directory.  I am assuming that you are not\nplanning to create objects in a remote peer from within the git\ncode path, and instead to have background process that replicate\nthem over the network to peer repositories, so you probably do\nnot have to touch this side.\n\nExtending inspection and reading from existing objects for your\nnetworked storage may be somewhat messy, but starting points\nare:\n\n. has_sha1_file() takes the object name and returns true/false;\n  if the object is available to us in any form (be it in one of\n  the alternate object stores or the local repository, as\n  individual object in an objects/??/ file or stored in a pack).\n  Currently it looks at packs and then checks individual files\n  for performance reasons (to minimize seeks and to prevent\n  polluting dcache with many negative hits); you would be adding\n  another data source. \n\n. read_sha1_file() takes the object name, and returns the\n  uncompressed contents of the object in addition to the type\n  and the size.\n\n. sha1_object_info() takes the object name and returns the type\n  of the object and optionally returns the size of it, without\n  reading the contents.  Some programs call this before reading\n  the data using read_sha1_file(), so you might want to use this\n  as a cue to prefetch from a remote peer; also you _might_ want\n  to keep type and size cached if you plan to implement\n  forgetful storage that deliberately loses objects and expects\n  to refetch it from its peers.  Good test program once you are\n  done extending this part is git-cat-file with -t and -s flag.\n\nThe above three are the primary read interfaces, but there are\nsome places that cheat by assuming that packs and individual\nobjects are the only two kinds of sources for the object data,\nso you need to be careful.  For example, write_sha1_to_fd(),\nwhich is used only by ssh-upload, first tries to call\nmap_sha1_file_internal(), which is only valid for individual\nobjects, to grab the object data, and when it fails, calls\nread_packed_sha1(), which is only valid for objects in packs,\nwithout even checking if read_packed_sha1() succeeded.  This\ndoesn't crash only because the caller of write_sha1_to_fd()\nchecks if the object is available by calling has_sha1_file()\nitself before calling this function, but you would need to\nchange it to fall back on your networked storage if you do not\nwant to crash when used by ssh-upload.\n\nHTH, and have fun.\n"},{"id":"11146","messageId":"436BC732.3090809@pobox.com","threadId":"2341","inReplyTo":"7vd5lg22gm.fsf@assigned-by-dhcp.cox.net","subject":"Re: RFC: GIT networked storage","fromName":"Jeff Garzik","fromEmail":"jgarzik@pobox.com","sentAt":"2005-11-04T20:40:18Z","receivedAt":"2005-11-04T20:40:18Z","isPatch":false,"sender":{"key":"jgarzik@pobox.com","avatar":null},"body":"Junio C Hamano wrote:\n> Jeff Garzik <jgarzik@pobox.com> writes:\n> \n> \n>>How easy is it to add a new storage backend to git?\n> \n> \n> Almost everything is contained within sha1_file.c.\n> \n> Object creation side is simple -- everybody who creates an\n> object (e.g update-index registering blobs, write-tree writing\n> the toplevel and intermediate level trees, commit-tree building\n> a commit object, unpack-objects exploding a pack) goes through\n> write_sha1_file(), which checks if the object is already\n> available using has_sha1_file() and creates a new object in the\n> local .git/objects/?? directory.  I am assuming that you are not\n> planning to create objects in a remote peer from within the git\n> code path, and instead to have background process that replicate\n> them over the network to peer repositories, so you probably do\n> not have to touch this side.\n> \n> Extending inspection and reading from existing objects for your\n> networked storage may be somewhat messy, but starting points\n> are:\n[...]\n\nThanks.  It looks pretty straightforward to add a new storage backend, \ngrepping on the symbols you listed.\n\n\tJeff\n"},{"id":"11169","messageId":"87irv7urdj.fsf@gmail.com","threadId":"2341","inReplyTo":"7vwtjp2h59.fsf@assigned-by-dhcp.cox.net","subject":"Re: GIT 0.99.9c","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2005-11-05T14:00:08Z","receivedAt":"2005-11-05T14:00:08Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n>  And I would appreciate somebody who actually uses svnimport to Ack on\n> Yaacov's svnimport fix.\n\nLet's try to make a good report :)\n\nSituation:\n\nan svn repo created with cvs2svn, and used with svk so it has\nthe property svk:merge to say explicity the extra parents of a commit.\n\nsvn log -r 1:2 -v file:///repo/susy/\n------------------------------------------------------------------------\nr1 | (no author) | 2003-10-29 16:49:04 +0100 (Wed, 29 Oct 2003) | 1 line\nChanged paths:\n   A /branches\n   A /tags\n   A /trunk\n\nNew repository initialized by cvs2svn.\n------------------------------------------------------------------------\nr2 | guasch | 2003-10-29 16:49:04 +0100 (Wed, 29 Oct 2003) | 2 lines\nChanged paths:\n   A /trunk/includes\n   A /trunk/includes/gamma_gg.F\n\nInitial revision\n\n------------------------------------------------------------------------\n\ngit-svnimport orig:\n\nbela $ git-svnimport -v file:///repo/susy/\n1: Unrecognized path: /branches\n1: Unrecognized path: /tags\nTree ID 4b825dc642cb6eb9a060e54bf8d69288fbee4904\nCommitting initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904\nCommitted change 1:/ 2003-10-29 15:49:04)\nCommit ID caff0f3ee5bc540a264f615b000fcbd7b355586a\nWriting to refs/heads/origin\nDONE: 1 origin caff0f3ee5bc540a264f615b000fcbd7b355586a\n... 2 /trunk/includes ...\nName does not refer to a filesystem file: Attempted to get textual contents of a *non*-file node at /home/santi/usr/bin/git-svnimport line 115\nbela $ git-cat-file tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904\nbela $ \n\nand the same error for the commit r2 with \"-s 2\". I suppose that it\ntries to chechkout the includes dir.\n\ngit-svnimport new:\n\nI've used the one in the message\n\"[PATCH] Several fixes to import mono's svn tree\"\n\nbela $ git-svnimport -v file:///repo/susy/\nTree ID 4b825dc642cb6eb9a060e54bf8d69288fbee4904\nCommitting initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904\nCommitted change 1:/ 2003-10-29 15:49:04)\nCommit ID caff0f3ee5bc540a264f615b000fcbd7b355586a\nWriting to refs/heads/origin\nDONE: 1 origin caff0f3ee5bc540a264f615b000fcbd7b355586a\n... 2 /trunk/includes/gamma_gg.F ...\nTree ID b7ea8a91831deea3a6015a17f8843be4833255bc\nMerge parent branch: caff0f3ee5bc540a264f615b000fcbd7b355586a\nCommitted change 2:/ 2003-10-29 15:49:04)\nCommit ID 6dc8146789badce6368705f9317e7f65f4526f6b\nWriting to refs/heads/origin\nDONE: 2 origin 6dc8146789badce6368705f9317e7f65f4526f6b\n\n[...]\n\nDONE: 154 SinCosAlpha 657abeb912a00d6fad9fcd4436490d81b4002bcb\nSwitching from 657abeb912a00d6fad9fcd4436490d81b4002bcb to 760501ff6986134eaf0ee34484af1e38e7f8b8b0 (/)\nperl: /home/devel/release/subversion-1.2.3dfsg1/subversion/libsvn_subr/path.c:115: svn_path_join: Assertion `is_canonical (component, clen)' failed.\nAborted\n\nSo it worked till the revision 154. But the revision 155 is:\n\nbela $ svn log -r 155 file:///repo/susy/\n------------------------------------------------------------------------\nr155 | guasch | 2005-02-25 11:19:38 +0100 (Fri, 25 Feb 2005) | 14 lines\nChanged paths:\n   M /\n   M /trunk\n   M /trunk/includes/pp.f\n   A /trunk/includes/subh.F\n\n r157@jgi:  guasch | 2005-02-25 11:19:23 +0100\n  r156@jgi:  guasch | 2005-02-25 11:17:06 +0100\n  Create local branch of SVN mirror\n\n*** Merge branch SinCosAlpha. Revisions 152:154\n\nbela $ svn diff -r 154:155 file:///repo/susy/\n\n[...]\n\nProperty changes on: trunk\n___________________________________________________________________\nName: svk:merge\n   + e2421932-edf0-0310-b7cb-9d7cda74567f:/local/branches/SinCosAlpha:156\n\n\nProperty changes on: .\n___________________________________________________________________\nName: svk:merge\n   + e2421932-edf0-0310-b7cb-9d7cda74567f:/local:157\n\nbela $ \n\nThis is the first revision that changes the properties of / and\n/trunk, and it does not handle this situation.\n\nA usefull thing would be if it could use this information to create a\nmerge commit. So it could check if this information is from the\nrepository we are importing, and fallback to the heuristic one if it\nfails. (In the case above the \"e242...\" UUID is from another svn\nrepository).\n\nIf I do it by hand, the I get the following:\n156: Unrecognized path: /Xsecfile\n157: Unrecognized path: /Xsecfile/bo_Hqqp/hqqpinterface_sqcd_maximize_SSB_bsg_runningmass_prod.F\n157: Unrecognized path: /Xsecfile/includes/pphtt.f\n157: Unrecognized path: /Xsecfile/includes/dsig_htt.F\n158: Unrecognized path: /Xsecfile/includes/dsig_htt.F\nperl: /home/devel/release/subversion-1.2.3dfsg1/subversion/libsvn_subr/path.c:115: svn_path_join: Assertion `is_canonical (component, clen)' failed.\nAborted\n\nThe r159 changes the properties of /trunk too. The other thing is that\nfinds an \"Unrecognized path\" (that is logical), but I have not find any\nway to tell \"OK, it's my fault, but treat this as branch Xsecfile\".\n\nHope it's usefull.\n\n\n     Santi\n"}]}