{"thread":{"id":"2865","subject":"What's in git.git tonight","startedAt":"2005-12-17T09:37:12Z","lastAt":"2005-12-17T09:37:12Z","messageCount":1,"participants":["Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"13765","messageId":"7voe3g12uv.fsf@assigned-by-dhcp.cox.net","threadId":"2865","inReplyTo":null,"subject":"What's in git.git tonight","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-12-17T09:37:12Z","receivedAt":"2005-12-17T09:37:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Since 0.99.9n, there have been a couple of fixes and some\ndocumentation updates.  One notable is that we do not allow '?',\n'*' and '[' in ref names anymore --- this was done after the\nlist discussion with Pasky and friends.\n\nAnother notable is \"We do not like HEAD branch\" patch, but I've\nbeen thinking seriously about reverting it and replace its\neffect by also reverting the misguided attempt to disambiguate\nbranch names and tag names.  This patch with a commit message\nwill follow in a separate message; it currently lives in the\nproposed updates branch.  One positive effect this change brings\nis that it fixes a corner case bug/confusion Johannes mentioned\nthe other day while diagnosing the trouble Len had with his\nrepository (I do not think the problem has anything to do with\nLen's trouble, though).  If you have a branch called \"dead\", and\nyou also have a tag called \"dead\", and if your repository has\nonly one object whose name begins with \"dead\"\n(e.g. \"deadbeef1234...\"), \"git rev-parse --verify dead\" would\npick up the \"deadbeef1234...\"  object, not \"dead\" tag nor \"dead\"\nhead.  When no such object exists, \"git rev-parse --verify dead\"\nfails, saying \"dead\" is ambiguous between heads and tags.  This\nis just confused, and \"reverting the misguided disambiguation\"\nchange will make it pick up the \"dead\" tag in either case.  Most\nlikely I'll have it in \"master\" after further testing over the\nweekend.\n\nOne important patch waiting in the proposed updates is to give\nan option to git-fetch-pack to keep the downloaded pack without\nunpacking it; this was primarily done to help Cogito, but I\nhaven't heard back about it from Pasky yet.  The primary\ndifference between this and the clone-pack change that is\nalready in the master branch, from the user's point of view, is\nthat git-fetch-pack can be efficiently used in an already\npopulated repository [*1*].  Imagine cloning \"master\" branch\nfrom linux-2.6 repository of Linus, and then fetching ALL branch\nfrom libata-dev repository of Jeff --- the difference is large\nenough that you would want to keep the downloaded stuff packed,\nwhile you do want to take advantage of the fact that you already\nhave objects from Linus.  Currently it saves exploding about a\n~800K pack with 1100 objects in it.  Although I mentioned we are\nsupposed to be in deep feature freeze, I feel it is worth to\nhave this one in 1.0.\n\n\n[Footnote]\n\n*1* Theoretically we could deprecate git-clone-pack and use\ngit-fetch-pack exclusively, if we are willing to create refs\nmatching what the remote has in the wrapper script git-clone.\n"}]}