{"thread":{"id":"5313","subject":"Unresolved issues #3","startedAt":"2006-08-18T04:09:03Z","lastAt":"2006-10-06T16:53:28Z","messageCount":30,"participants":["Junio C Hamano","A Large Angry SCM","Jeff King","Catalin Marinas","Jakub Narebski","Nicolas Pitre","Aneesh Kumar K.V","Jon Loeliger","Martin Langhoff","Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"25513","messageId":"7vpseyelcw.fsf@assigned-by-dhcp.cox.net","threadId":"5313","inReplyTo":null,"subject":"Unresolved issues #3","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-18T04:09:03Z","receivedAt":"2006-08-18T04:09:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"As everybody has probably noticed already, I am terrible at\nmaintaining \"the current issues\" list. The most recent issue of\nthis series was done when? Back on May 4th this year.\n\nShame on me.\n\n\nHere is a list of topics in the recent git traffic that I feel\ninadequately addressed, in no particular order. I've commented\non some of them to give people a feel for what my priorities\nare. Somebody might want to rehash the ones low on my priority\nlist to conclusion with a concrete proposal if they cared about\nthem enough.\n\n\n* Mozilla import team seems to be making an interesting set of\n discoveries around the area of scalability, although I haven't\n personally looked at any of the tools they are using so far.\n\n Continued discussion is encouraged, and I am looking forward\n to see the fruits of this effort. Very much appreciated.\n\n* Eric W Biederman outlined an alternative workflow to track\n history of the tip of a branch that does not use ref-log\n facility.\n\n Message-ID: \n\n I think this sort-of makes sense when everybody involved does\n not misuse the fake parallel branch for purposes other than\n tracking the tip of the other, \"true\", branch, but I fear it\n would confuse people quite a bit. Eric talks about making\n rewinding and rebasing in distributed manner possible, but I\n do not know what merging between the fake branches would mean,\n for example.\n\n* Matthias Lederhofer's helper for stand alone gitweb test looked\n very promising:\n\n Message-ID: <20060806165151.GB9548@moooo.ath.cx>\n\n With the recent flurry of gitweb changes, we really need a\n test suite to catch obvious breakages in the t/ hierarchy, and\n something like this patch would help.\n\n I'd like to apply this patch, if somebody wants to add gitweb\n tests.\n\n* Jeff King sent a patch to color git-status output\n\n Message-ID: <20060805031418.GA11102@coredump.intra.peff.net>\n\n But later he started working on rewriting one core function\n from git-status in C, which I think makes a lot of sense.\n That would make this patch unnecessary. A thread related to\n this effort is this:\n \n Message-ID: <20060810082455.GA30739@coredump.intra.peff.net>\n\n Hoping to see the C implementation of run_status but I am in\n no rush myself.\n\n I vaguely recall there was a companion patch to add vim\n colorizer for the current git-status output, meant for\n contrib/vim, but I lost it. If somebody cares deeply enough\n please send it over.\n\n* Alex Riesen still has problems with Git.pm/Git.xs on Windows\n with ActiveState Perl.\n\n Message-ID: <81b0412b0608020702q2fd4ec83ga43714c15538f7ad@mail.gmail.com>\n\n There was a workaround patch by Alex to disable certain\n commands that happen to use Git.pm:\n\n Message-ID: <81b0412b0608040640s44c0d84et94871bce0271b047@mail.gmail.com>\n\n But I sense this would make us think twice before using Git.pm\n in new programs (i.e. \"Can Alex live without this new nice\n program? If not maybe we should write it without Git.pm\"),\n which feels backwards and I would like to avoid it if we can.\n\n I am not sure what the resolution of this should be.\n\n* Michael S. Tsirkin discovered that we have trouble dealing\n with the same remote ref tracked by multiple tracking\n branches.\n\n Message-ID: <20060807125116.GA28658@mellanox.co.il>\n\n Since I do not see a valid use case that _must_ use more than\n one local tracking branch to track one remote ref, I think it\n is Ok to declare it an error to do so. However, at least, we\n would need a better error message even then.\n\n* Jeff Garzik reports that the summary page of gitweb does not\n look at anything other than \"master\" which is not appropriate\n for his tree.\n\n Message-ID: <44D874F0.6000907@garzik.org>\n\n I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,\n Aneesh) about this.\n\n* gitk bottom-left pane layout is reported to be broken for some\n people.\n\n Message-ID: <20060802192922.GA30539@prophet.net-ronin.org>\n\n \"carbonated beverage\" tried some random hacks to work it\n around but I do not think we have gotten anywhere, and the\n discussion fizzled out.\n\n I vaguely recall paulus saying it was a Tk bug but do not\n recall hearing nor understanding any details myself.\n\n* \"A Large Angry SCM\" wrote a nice summary, \"Git files data\n formats documentation\".\n\n Message-ID: <44D51D47.9090700@gmail.com>\n\n With one final update by Nico yesterday, I think it is ready\n for inclusion.\n\n Does somebody care to make a patch out of it to add it to\n Documentation/technical/, maybe removing pack-format.txt there\n after making sure all it talks about is covered by the new\n documentation?\n\n I do not have enough \"virginity\" to spot omissions in the\n description anymore, so comments from somebody new to the\n system are very much appreciated.\n\n* Martin Langhoff proposed git-xxdiff as a helper after a failed\n merge.\n\n Message-ID: <11546492331601-git-send-email-martin@catalyst.net.nz>\n\n I like the general idea of this a lot, but am having a bit of\n trouble envisioning how we can integrate this while making\n sure mergers other than xxdiff can be added easily without\n disrupting the end user experience.\n\n* Shawn Pearce noticed that fsck-objects do not fully check some\n fields in commits:\n\n Message-ID: <20060814062830.GF18667@spearce.org>\n\n* Although \"annotate\" had some big fixes just before 1.4.2, Ryan\n seems to feel \"blame\" has already won.\n\n Message-ID: <20060807194539.GD15477@h4x0r5.com>\n\n Is there still an area \"annotate\" shines more than \"blame -c\"?\n\n* \"Michael barra_cuda\" noticed that an option \"--no\" is\n ambiguous to git-revert:\n\n Message-ID: <200608031742.23170.barra_cuda@katamail.com>\n\n I need to fix this.\n\n* Cherry-pick should not require -r to suppress \"cherry-picked\n from\" message.\n\n Message-ID: \n\n This was requested by Linus, which I haven't done anything\n about yet. Maybe making -r a no-op, defaulting not to add the\n message, and introducing --record-original flag to add it\n would be a way to go? My fingers are trained to automatically\n type -r when doing cherry-pick which is a very good indication\n that the flag was a mistake.\n\n* Martin Waitz has a patch to accept \"end-of-cover-letter\"\n marker in patch messages.\n\n Message-ID: <20060723214524.GC20068@admingilde.org>\n\n I did not take the patch, primarily because I do not want to\n encourage \"cover letter then log then patch\" format, and also\n the proposed marker \"+++\" looked somewhat ugly (see Message-ID:\n <20060801193408.GF16364@admingilde.org> for an example).\n\n If somebody wants to rehash this I am still open to reconsider\n it, but I sense a veto from Linus coming...\n"},{"id":"25520","messageId":"44E546F2.7070902@gmail.com","threadId":"5313","inReplyTo":"7vpseyelcw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #3","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2006-08-18T04:49:54Z","receivedAt":"2006-08-18T04:49:54Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n...\n> * \"A Large Angry SCM\" wrote a nice summary, \"Git files data\n> formats documentation\".\n> \n> Message-ID: <44D51D47.9090700@gmail.com>\n> \n> With one final update by Nico yesterday, I think it is ready\n> for inclusion.\n> \n> Does somebody care to make a patch out of it to add it to\n> Documentation/technical/, maybe removing pack-format.txt there\n> after making sure all it talks about is covered by the new\n> documentation?\n> \n> I do not have enough \"virginity\" to spot omissions in the\n> description anymore, so comments from somebody new to the\n> system are very much appreciated.\n> \n\nTwo things:\n\n1) I disagree with Nico's assessment that, other than his, there can not\nexist any type 2 packs that have bit 6 set to mean copy from result.\n\n2) The document, if included into the core Git documentation, would be\nviewed as more authoritative than it actually is. It's really just a set\nof (structured) notes on various aspects of the files Git reads and\nwrites, pulled from various sources. Little or no attempt was made to\nseparate \"implementation artifact\" from intended structure.\n"},{"id":"25522","messageId":"20060818051013.GA10900@sigio.intra.peff.net","threadId":"5313","inReplyTo":"7vpseyelcw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #3","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2006-08-18T05:10:13Z","receivedAt":"2006-08-18T05:10:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Aug 17, 2006 at 09:09:03PM -0700, Junio C Hamano wrote:\n\n> * Jeff King sent a patch to color git-status output\n[...]\n> Hoping to see the C implementation of run_status but I am in\n> no rush myself.\n\nI am working on this but got side-tracked by \"real\" work. The current\nstate is that I have a simplistic working C run_status, but I'm still\nhoping to hack the diff code to simultaneously do the tree<->index and\nindex<->files diffs. I will try to send out something next week.\n\n> I vaguely recall there was a companion patch to add vim\n> colorizer for the current git-status output, meant for\n> contrib/vim, but I lost it. If somebody cares deeply enough\n> please send it over.\n\nIt's in <20060805032135.GA11244@coredump.intra.peff.net>. However, if I\ncan get the multi-diff support working, then the status format will\nchange. I will wait until that is resolved before submitting a patch to\nput vim highlighting into contrib/.\n\n-Peff\n"},{"id":"25530","messageId":"tnx1wre4e6s.fsf@arm.com","threadId":"5313","inReplyTo":"7vpseyelcw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #3","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@arm.com","sentAt":"2006-08-18T08:54:03Z","receivedAt":"2006-08-18T08:54:03Z","isPatch":false,"sender":{"key":"catalin.marinas@arm.com","avatar":null},"body":"Junio C Hamano wrote:\n> * Martin Langhoff proposed git-xxdiff as a helper after a failed\n> merge.\n>\n> Message-ID: <11546492331601-git-send-email-martin@catalyst.net.nz>\n>\n> I like the general idea of this a lot, but am having a bit of\n> trouble envisioning how we can integrate this while making\n> sure mergers other than xxdiff can be added easily without\n> disrupting the end user experience.\n\nIn StGIT I can configure the merge command and I currently use the\nattached script (I need to add it to the StGIT repository). It tries\ndiff3 first and, if that fails, invokes emacs' merge (can use xxdiff\nas well). It also checks whether the file was modified in case I want\nto exit and solve the conflict later (maybe after getting conflict\ninformation for the other files).\n\n-- \nCatalin\n\n\n\n#!/usr/bin/env python\n\"\"\"Run diff3 and an interactive tool if this fails.\n\"\"\"\n\n__copyright__ = \"\"\"\nCopyright (C) 2006, Catalin Marinas \n\nThis program is free software; you can redistribute it and/or modify\nit under the terms of the GNU General Public License version 2 as\npublished by the Free Software Foundation.\n\nThis program is distributed in the hope that it will be useful,\nbut WITHOUT ANY WARRANTY; without even the implied warranty of\nMERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the\nGNU General Public License for more details.\n\nYou should have received a copy of the GNU General Public License\nalong with this program; if not, write to the Free Software\nFoundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\n\"\"\"\n\nimport sys, os\n\nif len(sys.argv) != 5:\n print >> sys.stderr, 'Usage: %s ancestor branch1 branch2 output' \\\n % sys.argv[0]\n sys.exit(1)\n\nancestor = sys.argv[1]\nbranch1 = sys.argv[2]\nbranch2 = sys.argv[3]\noutput = sys.argv[4]\n\n# default merger\nif os.system('diff3 -L current -L ancestor -L patched -m -E '\n '\"%s\" \"%s\" \"%s\" > \"%s\"'\n % (branch1, ancestor, branch2, output)):\n # interactive merge\n if os.path.exists(output):\n mtime = os.path.getmtime(output)\n else:\n mtime = 0\n\n ret = os.system('emacs --eval \\'(ediff-merge-files-with-ancestor '\n '\"%s\" \"%s\" \"%s\" nil \"%s\")\\''\n % (branch1, branch2, ancestor, output))\n\n #ret = os.system(\n # 'xxdiff --title1 current --title2 ancestor --title3 patched '\n # '--show-merged-pane -m -E -O -X -M \"%s\" \"%s\" \"%s\" \"%s\"'\n # % (output, branch1, ancestor, branch2))\n\n # error in the interactive merger, just exit\n if ret:\n sys.exit(2)\n\n # check for file modification\n if not os.path.exists(output) or mtime == os.path.getmtime(output):\n sys.exit(3)\n\n# everything's fine\nsys.exit(0)\n"},{"id":"25531","messageId":"ec3va4$ru1$1@sea.gmane.org","threadId":"5313","inReplyTo":"7vpseyelcw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #3","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-18T08:56:36Z","receivedAt":"2006-08-18T08:56:36Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> * Jeff Garzik reports that the summary page of gitweb does not\n>   look at anything other than \"master\" which is not appropriate\n>   for his tree.\n> \n>   Message-ID: <44D874F0.6000907@garzik.org>\n> \n>   I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,\n>   Aneesh) about this.\n\nFor performance reasons this should probably wait for functioning\ngit-show-refs command. BTW. summary page doesn't show \"Last Updated\" based\non \"master\", but based on \"HEAD\" (current branch)... which usually is\n\"master\" I guess in typical usage.\n\nAnother thing that I think is/might be important to gitweb, is to rewrite\ncommitdiff and blobdiff to not use external diff, but builtin\ngit-diff-tree... this probably would lead to changes in the output.\nI'm thinking about \"-B\" without \"-C\" nor \"-M\" for plain output (is this\nno-op for this combination?), and \"-C\", \"-M\" for HTML output.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25532","messageId":"7vbqqics3g.fsf@assigned-by-dhcp.cox.net","threadId":"5313","inReplyTo":"tnx1wre4e6s.fsf@arm.com","subject":"Re: Unresolved issues #3","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-18T09:26:27Z","receivedAt":"2006-08-18T09:26:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Catalin Marinas writes:\n\n> Junio C Hamano wrote:\n>> * Martin Langhoff proposed git-xxdiff as a helper after a failed\n>> merge.\n>>\n>> Message-ID: <11546492331601-git-send-email-martin@catalyst.net.nz>\n>>\n>> I like the general idea of this a lot, but am having a bit of\n>> trouble envisioning how we can integrate this while making\n>> sure mergers other than xxdiff can be added easily without\n>> disrupting the end user experience.\n>\n> In StGIT I can configure the merge command and I currently use the\n> attached script (I need to add it to the StGIT repository). It tries\n> diff3 first and, if that fails, invokes emacs' merge (can use xxdiff\n> as well). It also checks whether the file was modified in case I want\n> to exit and solve the conflict later (maybe after getting conflict\n> information for the other files).\n\nThanks. That is interesting. However, the workflow Martin\nwants to use this is a bit different from this. He wants\nregular diff3/merge to leave conflicted result and have \"xxdiff\n-U\" to sort out the resulting mess (I do that manually myself\nbut without any wrapper).\n\nHaving said that...\n\n> # default merger\n> if os.system('diff3 -L current -L ancestor -L patched -m -E '\n> '\"%s\" \"%s\" \"%s\" > \"%s\"'\n> % (branch1, ancestor, branch2, output)):\n> # interactive merge\n> if os.path.exists(output):\n> mtime = os.path.getmtime(output)\n> else:\n> mtime = 0\n\nThis reminds me that I should make the git barebone\nporcelain-ish to use diff3 directly without using merge\nwrapper.\n\nI wonder why you do not error out when \"if os.path.exists(output)\"\ndoes not hold true; you are redirecting into it, so the possibilities\nare:\n\n - the filesystem is full;\n - your quota ran out;\n - you do not have write permission to the directory \"output\"\n wants to be in;\n - the user gave 'fooled you\"; rm -fr . \"bye' as the value of\n sys.argv[4];\n\netc. No matter what the reason, the fall-back interactive merge\nwould not be able to write into output either anyway, no?\n\nAlso I wonder what would happen upon a user error where an\nexisting file that is unwritable by the user is specified as\noutput.\n"},{"id":"25535","messageId":"b0943d9e0608180256n6b7077b5r6e854b49d85afcc1@mail.gmail.com","threadId":"5313","inReplyTo":"7vbqqics3g.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #3","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2006-08-18T09:56:50Z","receivedAt":"2006-08-18T09:56:50Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On 18/08/06, Junio C Hamano wrote:\n> Catalin Marinas writes:\n> > In StGIT I can configure the merge command and I currently use the\n> > attached script (I need to add it to the StGIT repository). It tries\n> > diff3 first and, if that fails, invokes emacs' merge (can use xxdiff\n> > as well). It also checks whether the file was modified in case I want\n> > to exit and solve the conflict later (maybe after getting conflict\n> > information for the other files).\n>\n> Thanks. That is interesting. However, the workflow Martin\n> wants to use this is a bit different from this. He wants\n> regular diff3/merge to leave conflicted result and have \"xxdiff\n> -U\" to sort out the resulting mess (I do that manually myself\n> but without any wrapper).\n\nThe problem with this approach is that you lose the ancestor\ninformation. You want \"diff3 -E\" command to not report conflicts if\nthe changes are the same but the output no longer has the ancestor\ninformation. The -A option would keep the ancestor (and use \"xxdiff\n--unmerge3\" instead) but it always reports a conflict even if the\nchanges are the same. Are there any diff3 options I missed?\n\nThat's why I prefer to explicitely pass the 3 files to either emacs or xxdiff.\n\n> > # default merger\n> > if os.system('diff3 -L current -L ancestor -L patched -m -E '\n> > '\"%s\" \"%s\" \"%s\" > \"%s\"'\n> > % (branch1, ancestor, branch2, output)):\n> > # interactive merge\n> > if os.path.exists(output):\n> > mtime = os.path.getmtime(output)\n> > else:\n> > mtime = 0\n>\n> I wonder why you do not error out when \"if os.path.exists(output)\"\n> does not hold true; you are redirecting into it, so the possibilities\n> are:\n\nYou are right. I was thinking about the file removed in the current\nbranch but modified in the other. However, this would never invoke\ndiff3.\n\nThanks.\n\n-- \nCatalin\n"},{"id":"25561","messageId":"Pine.LNX.4.64.0608181041420.11359@localhost.localdomain","threadId":"5313","inReplyTo":"44E546F2.7070902@gmail.com","subject":"Re: Unresolved issues #3","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-08-18T14:49:30Z","receivedAt":"2006-08-18T14:49:30Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 17 Aug 2006, A Large Angry SCM wrote:\n\n> Junio C Hamano wrote:\n> ...\n> > * \"A Large Angry SCM\" wrote a nice summary, \"Git files data\n> > formats documentation\".\n> > \n> > Message-ID: <44D51D47.9090700@gmail.com>\n> > \n> > With one final update by Nico yesterday, I think it is ready\n> > for inclusion.\n> > \n> > Does somebody care to make a patch out of it to add it to\n> > Documentation/technical/, maybe removing pack-format.txt there\n> > after making sure all it talks about is covered by the new\n> > documentation?\n> > \n> > I do not have enough \"virginity\" to spot omissions in the\n> > description anymore, so comments from somebody new to the\n> > system are very much appreciated.\n> > \n> \n> Two things:\n> \n> 1) I disagree with Nico's assessment that, other than his, there can not\n> exist any type 2 packs that have bit 6 set to mean copy from result.\n\nCare to explain why?\n\nSince this code is mine I can tell you that no official GIT version ever \nproduced such a pack. The code to make use of that bit was quite \ninvolving and the end result wasn't great at all so I never published \nsaid code. This is also why current GIT accepts both pack version 2 and \n3 without any distinction using the same code in patch-delta.c on the \nbasis that no version 2 packs ever used that bit.\n\n\nNicolas\n"},{"id":"25562","messageId":"44E5D522.8030407@gmail.com","threadId":"5313","inReplyTo":"Pine.LNX.4.64.0608181041420.11359@localhost.localdomain","subject":"Re: Unresolved issues #3","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2006-08-18T14:56:34Z","receivedAt":"2006-08-18T14:56:34Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Nicolas Pitre wrote:\n> On Thu, 17 Aug 2006, A Large Angry SCM wrote:\n...\n>>\n>> 1) I disagree with Nico's assessment that, other than his, there can not\n>> exist any type 2 packs that have bit 6 set to mean copy from result.\n> \n> Care to explain why?\n> \n> Since this code is mine I can tell you that no official GIT version ever \n ^^^^^^^^^^^^^^^^^^^^^^^\n> produced such a pack. The code to make use of that bit was quite \n> involving and the end result wasn't great at all so I never published \n> said code. This is also why current GIT accepts both pack version 2 and \n> 3 without any distinction using the same code in patch-delta.c on the \n> basis that no version 2 packs ever used that bit.\n\nThat doesn't prove the non-existence of other code to do it.\n"},{"id":"25563","messageId":"Pine.LNX.4.64.0608181119410.11359@localhost.localdomain","threadId":"5313","inReplyTo":"44E5D522.8030407@gmail.com","subject":"Re: Unresolved issues #3","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-08-18T15:30:56Z","receivedAt":"2006-08-18T15:30:56Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 18 Aug 2006, A Large Angry SCM wrote:\n\n> Nicolas Pitre wrote:\n> > On Thu, 17 Aug 2006, A Large Angry SCM wrote:\n> ...\n> >>\n> >> 1) I disagree with Nico's assessment that, other than his, there can not\n> >> exist any type 2 packs that have bit 6 set to mean copy from result.\n> > \n> > Care to explain why?\n> > \n> > Since this code is mine I can tell you that no official GIT version ever \n> ^^^^^^^^^^^^^^^^^^^^^^^\n> > produced such a pack. The code to make use of that bit was quite \n> > involving and the end result wasn't great at all so I never published \n> > said code. This is also why current GIT accepts both pack version 2 and \n> > 3 without any distinction using the same code in patch-delta.c on the \n> > basis that no version 2 packs ever used that bit.\n> \n> That doesn't prove the non-existence of other code to do it.\n\nSo? If the official and primary code for GIT doesn't support it, what \nis the point? I'm telling you that if such packs exist they will simply \nbarf with all official GIT releases later than v1.1.6 making your \nargument pointless.\n\nI don't mind you documenting that historic intent for a bit that was \nnever officially used, but at least let's document it right.\n\n\nNicolas\n"},{"id":"25569","messageId":"44E5ED82.8090904@gmail.com","threadId":"5313","inReplyTo":"7vpseyelcw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #3","fromName":"Aneesh Kumar K.V","fromEmail":"aneesh.kumar@gmail.com","sentAt":"2006-08-18T16:40:34Z","receivedAt":"2006-08-18T16:40:34Z","isPatch":false,"sender":{"key":"aneesh.kumar@gmail.com","avatar":"https://gravatar.com/avatar/0621fc0b2f14ead1e9024382f16053a808c148596da30c1b92572fa075621f68?d=mp&s=160"},"body":"Junio C Hamano wrote:\n\n> * Jeff Garzik reports that the summary page of gitweb does not\n> look at anything other than \"master\" which is not appropriate\n> for his tree.\n> \n> Message-ID: <44D874F0.6000907@garzik.org>\n> \n> I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,\n> Aneesh) about this.\n> \n\n\nI just tried editing HEAD. For the project \n\nhttp://git.openssi.org/~kvaneesh/gitweb.cgi?p=ci-to-linus.git;a=summary\n\n$more HEAD\nref: refs/heads/from-linus\n$\n\nIs this solution fine ?. Or do we want to add a git-rep-config variable to indicate which branch to show.\n\n-aneesh \n"},{"id":"25570","messageId":"ec4r0h$u9m$1@sea.gmane.org","threadId":"5313","inReplyTo":"44E5ED82.8090904@gmail.com","subject":"Re: Unresolved issues #3","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-18T16:48:17Z","receivedAt":"2006-08-18T16:48:17Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aneesh Kumar K.V wrote:\n\n> Junio C Hamano wrote:\n> \n>> * Jeff Garzik reports that the summary page of gitweb does not\n>> look at anything other than \"master\" which is not appropriate\n>> for his tree.\n>> \n>> Message-ID: <44D874F0.6000907@garzik.org>\n>> \n>> I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,\n>> Aneesh) about this.\n> \n> I just tried editing HEAD. For the project \n> \n> http://git.openssi.org/~kvaneesh/gitweb.cgi?p=ci-to-linus.git;a=summary\n> \n> $more HEAD\n> ref: refs/heads/from-linus\n> $\n> \n> Is this solution fine ?. Or do we want to add a git-rep-config \n> variable to indicate which branch to show. \n\nErr, of course gitweb shows \"Last Change\" for HEAD, which usually is master.\nThe solution would be to show \"Last Change\" date to be the date of last\nchange of all/any branch.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25573","messageId":"ec4rsp$2vi$1@sea.gmane.org","threadId":"5313","inReplyTo":"ec4r0h$u9m$1@sea.gmane.org","subject":"Re: Unresolved issues #3","fromName":"Aneesh Kumar K.V","fromEmail":"aneesh.kumar@gmail.com","sentAt":"2006-08-18T17:03:21Z","receivedAt":"2006-08-18T17:03:21Z","isPatch":false,"sender":{"key":"aneesh.kumar@gmail.com","avatar":"https://gravatar.com/avatar/0621fc0b2f14ead1e9024382f16053a808c148596da30c1b92572fa075621f68?d=mp&s=160"},"body":"Jakub Narebski wrote:\n> Aneesh Kumar K.V wrote:\n> \n>> Junio C Hamano wrote:\n>>\n>>> * Jeff Garzik reports that the summary page of gitweb does not\n>>> look at anything other than \"master\" which is not appropriate\n>>> for his tree.\n>>>\n>>> Message-ID: <44D874F0.6000907@garzik.org>\n>>>\n>>> I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,\n>>> Aneesh) about this.\n>> I just tried editing HEAD. For the project \n>>\n>> http://git.openssi.org/~kvaneesh/gitweb.cgi?p=ci-to-linus.git;a=summary\n>>\n>> $more HEAD\n>> ref: refs/heads/from-linus\n>> $\n>>\n>> Is this solution fine ?. Or do we want to add a git-rep-config \n>> variable to indicate which branch to show. \n> \n> Err, of course gitweb shows \"Last Change\" for HEAD, which usually is master.\n> The solution would be to show \"Last Change\" date to be the date of last\n> change of all/any branch.\n> \n\nI didn't quiet understand that. AFAIU what jeff wanted is to make gitweb show some branch other than master\nby default in the summary page. I guess editing HEAD enables that.\n\n-aneesh\n"},{"id":"25575","messageId":"ec4s7p$3is$1@sea.gmane.org","threadId":"5313","inReplyTo":"ec4rsp$2vi$1@sea.gmane.org","subject":"Re: Unresolved issues #3","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-18T17:09:14Z","receivedAt":"2006-08-18T17:09:14Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Aneesh Kumar K.V wrote:\n\n> Jakub Narebski wrote:\n>> Aneesh Kumar K.V wrote:\n>> \n>>> Junio C Hamano wrote:\n>>>\n>>>> * Jeff Garzik reports that the summary page of gitweb does not\n>>>> look at anything other than \"master\" which is not appropriate\n>>>> for his tree.\n>>>>\n>>>> Message-ID: <44D874F0.6000907@garzik.org>\n>>>>\n>>>> I probably should bug gitweb gang (Jakub, Luben, Martin Waitz,\n>>>> Aneesh) about this.\n>>> I just tried editing HEAD. For the project \n>>>\n>>> http://git.openssi.org/~kvaneesh/gitweb.cgi?p=ci-to-linus.git;a=summary\n>>>\n>>> $more HEAD\n>>> ref: refs/heads/from-linus\n>>> $\n>>>\n>>> Is this solution fine ?. Or do we want to add a git-rep-config \n>>> variable to indicate which branch to show. \n>> \n>> Err, of course gitweb shows \"Last Change\" for HEAD, which usually is\n>> master. The solution would be to show \"Last Change\" date to be the date\n>> of last change of all/any branch.\n> \n> I didn't quiet understand that. AFAIU what jeff wanted is to make \n> gitweb show some branch other than master by default in the summary page.\n> I guess editing HEAD enables that. \n\nEditing head, well, having other branch checked out would be enough (checked\nout before push would be enough I guess for gitweb repository being\n\"published repository\", other that the copy you are working on).\n\nAFAIR the problem was that development was not made at \"master\", so \"Last\nChanges\" were last changes in master, no last changes as a whole. Last\nchanges date as a whole would be last change date of latest edited branch.\nAnd for this I'd rather have functioning git-show-refs, for performance (at\nleast with larger number of heads...). \n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"25580","messageId":"1155923876.10054.205.camel@cashmere.sps.mot.com","threadId":"5313","inReplyTo":"7vpseyelcw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #3","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-08-18T17:57:57Z","receivedAt":"2006-08-18T17:57:57Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Thu, 2006-08-17 at 23:09, Junio C Hamano wrote:\n> As everybody has probably noticed already, I am terrible at\n> maintaining \"the current issues\" list. The most recent issue of\n> this series was done when? Back on May 4th this year.\n> \n> Shame on me.\n\nI continue to think you are doing a fabulous job nonetheless!\n\n> \n> Here is a list of topics in the recent git traffic that I feel\n> inadequately addressed, in no particular order. I've commented\n> on some of them to give people a feel for what my priorities\n> are. Somebody might want to rehash the ones low on my priority\n> list to conclusion with a concrete proposal if they cared about\n> them enough.\n\nI have another:\n\ngit-daemon virtualization so that consistent HTTP and\nnative git protocols can appear to use consistent URLs\neven in the face of HTTP configurations aliasing them\nto somewhere else on the filesystem and for multiple\nvirtually hosted domain names.\n\n\nThanks,\njdl\n"},{"id":"25599","messageId":"44E68DCD.8010603@gmail.com","threadId":"5313","inReplyTo":"Pine.LNX.4.64.0608181119410.11359@localhost.localdomain","subject":"Re: Unresolved issues #3","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2006-08-19T04:04:29Z","receivedAt":"2006-08-19T04:04:29Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Nicolas Pitre wrote:\n> On Fri, 18 Aug 2006, A Large Angry SCM wrote:\n> \n>> Nicolas Pitre wrote:\n>>> On Thu, 17 Aug 2006, A Large Angry SCM wrote:\n>> ...\n>>>> 1) I disagree with Nico's assessment that, other than his, there can not\n>>>> exist any type 2 packs that have bit 6 set to mean copy from result.\n>>> Care to explain why?\n>>>\n>>> Since this code is mine I can tell you that no official GIT version ever \n>> ^^^^^^^^^^^^^^^^^^^^^^^\n>>> produced such a pack. The code to make use of that bit was quite \n>>> involving and the end result wasn't great at all so I never published \n>>> said code. This is also why current GIT accepts both pack version 2 and \n>>> 3 without any distinction using the same code in patch-delta.c on the \n>>> basis that no version 2 packs ever used that bit.\n>> That doesn't prove the non-existence of other code to do it.\n> \n> So? If the official and primary code for GIT doesn't support it, what \n> is the point? I'm telling you that if such packs exist they will simply \n> barf with all official GIT releases later than v1.1.6 making your \n> argument pointless.\n> \n> I don't mind you documenting that historic intent for a bit that was \n> never officially used, but at least let's document it right.\n\nHistoric fact. Between Thu May 19 08:56:22 2005 and Thu Feb 9 21:06:38\n2006 bit 6 of the first byte of a delta hunk was interpreted to mean\nthat the source of the copy was the result buffer. From Thu May 19\n08:56:22 2005 on, the code to decode delta hunks in type 2 packs was\navailable to everyone and anyone interested could make a pack encoder\nthat would create packs that the core Git code would correctly read. The\ncommit of Thu Feb 9 21:06:38 2006, d60fc, actually introduced a bug\nthat would treat valid type 2 packs as invalid.\n\nSince there was not any documentation that declared the bit as reserved,\nthe code was the documentation and it specified that bit 6 of the first\nbyte of a delta hunk was to be interpreted as meaning the the copy\nsource in the result buffer. The code did not and does not document intent.\n"},{"id":"25661","messageId":"7vy7tjxdas.fsf@assigned-by-dhcp.cox.net","threadId":"5313","inReplyTo":"1155923876.10054.205.camel@cashmere.sps.mot.com","subject":"Re: Unresolved issues #3","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-20T22:17:15Z","receivedAt":"2006-08-20T22:17:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Loeliger writes:\n\n> I have another:\n>\n> git-daemon virtualization so that consistent HTTP and\n> native git protocols can appear to use consistent URLs\n> even in the face of HTTP configurations aliasing them\n> to somewhere else on the filesystem and for multiple\n> virtually hosted domain names.\n\nGood point.\n\nHere are a handful others I have about git-daemon:\n\n * Possibly add --strict-symlink option we discussed a long time\n ago that prevents symbolic links inside the named whitelisted\n directory hierarchies to step outside.\n\n Nobody actually jumped up-and-down asking for it since we\n initially discussed this, so we may not need it after all.\n\n * The whitelist directories need to be specified with full path\n even when --base-path is used, which somewhat felt wrong. I\n do not have strong feeling about this anymore, though.\n\n * Extend $GIT_DIR/git-daemon-export-ok mechanism and have it\n read from $GIT_DIR/config.\n\n * Also extend the same in a way similar to the discussion we\n had between Aneesh, me and Jakub to control 'blame' and\n 'snapshot' in gitweb. I.e. allow the site-wide configuration\n to specify which services are enabled by default and which\n services can be overridden per repository, and allow per\n repository configuration to specify what's enabled and what's\n not.\n\n * Add git-upload-tar as a potential program that can be\n executed from git-daemon.\n\nIf we are to do the last three items, my thinking is to do\nsomething like this:\n\n * The config file can have:\n\n daemon.upload-pack = yes | no\n daemon.upload-tar = yes | no\n\n to enable or disable the services individually.\n\n * $GIT_DIR/git-daemon-export-ok is kept as a backward\n compatibility measure; it means upload-pack is enabled.\n\nIf we were to allow git-upload-tar from git-daemon:\n\n * Fix protocol exchange between git-upload-tar and git-tar-tree\n so that the downloader can name the symbolically\n like this:\n\n\tgit tar-tree --remote=git://git.kernel.org/pub/scm/git/git next\n\n Currently the downloader has to get the value of \"next\" at\n the remote server out-of-band and give an explicit object\n name.\n"},{"id":"25663","messageId":"Pine.LNX.4.64.0608201840310.11359@localhost.localdomain","threadId":"5313","inReplyTo":"44E68DCD.8010603@gmail.com","subject":"Re: Unresolved issues #3","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-08-20T23:10:23Z","receivedAt":"2006-08-20T23:10:23Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 18 Aug 2006, A Large Angry SCM wrote:\n\n> Nicolas Pitre wrote:\n> > On Fri, 18 Aug 2006, A Large Angry SCM wrote:\n> >> That doesn't prove the non-existence of other code to do it.\n> > \n> > So? If the official and primary code for GIT doesn't support it, what \n> > is the point? I'm telling you that if such packs exist they will simply \n> > barf with all official GIT releases later than v1.1.6 making your \n> > argument pointless.\n> > \n> > I don't mind you documenting that historic intent for a bit that was \n> > never officially used, but at least let's document it right.\n> \n> Historic fact. Between Thu May 19 08:56:22 2005 and Thu Feb 9 21:06:38\n> 2006 bit 6 of the first byte of a delta hunk was interpreted to mean\n> that the source of the copy was the result buffer. From Thu May 19\n> 08:56:22 2005 on, the code to decode delta hunks in type 2 packs was\n> available to everyone and anyone interested could make a pack encoder\n> that would create packs that the core Git code would correctly read. The\n> commit of Thu Feb 9 21:06:38 2006, d60fc, actually introduced a bug\n> that would treat valid type 2 packs as invalid.\n\nThe \"actually introduced a bug\" sentence is your own interpretation not \na _fact_.\n\nAnd I simply disagree with that interpretation of yours.\n\nI don't think this is worth arguing any further.\n\n\nNicolas\n"},{"id":"25664","messageId":"7vk653xa3a.fsf@assigned-by-dhcp.cox.net","threadId":"5313","inReplyTo":"Pine.LNX.4.64.0608201840310.11359@localhost.localdomain","subject":"Re: Unresolved issues #3","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-20T23:26:33Z","receivedAt":"2006-08-20T23:26:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Fri, 18 Aug 2006, A Large Angry SCM wrote:\n>\n>> Historic fact. Between Thu May 19 08:56:22 2005 and Thu Feb 9 21:06:38\n>> 2006 bit 6 of the first byte of a delta hunk was interpreted to mean\n>> that the source of the copy was the result buffer. From Thu May 19\n>> 08:56:22 2005 on, the code to decode delta hunks in type 2 packs was\n>> available to everyone and anyone interested could make a pack encoder\n>> that would create packs that the core Git code would correctly read. The\n>> commit of Thu Feb 9 21:06:38 2006, d60fc, actually introduced a bug\n>> that would treat valid type 2 packs as invalid.\n\nIt is more like the said commit made the pack format extensible\nby declaring the bit reserved for the future use, by declaring\nretroactively that a type 2 pack that used that bit invalid.\nAnd it was deemed a reasonable and safe decision because no\nofficial git ever produced a type 2 pack that used that bit,\n\nYes, that was a backward incompatible change, strictly speaking,\nand probably I should have made an announcement that looked\nsimilar to this by Linus:\n\n From: Linus Torvalds \n Subject: CAREFUL! No more delta object support!\n Date: Mon, 27 Jun 2005 18:14:40 -0700 (PDT)\n Message-ID: \n To: Git Mailing List \n\nSo you could argue I was incompetent not to make a big fuss\nabout this backward incompatibility back then, if you like.\n\nI did not think it was worth it back then, and I do not think it\nis worth it now, either. But if it makes you feel better, I\ncould retroactively make such an announcement about the\nunofficial bit 6.\n\nThe announcement would have read like this:\n\n The current git code does not support type #2 packs that\n uses delta with bit 6 to mean \"copy inside destination\n buffer\". Although the code that interpreted delta data\n supported bit 6 that way for a brief period of time, no\n official git ever released produced delta that used the\n bit that way.\n\n In other words, if you have created packs with your own,\n modified git, that took advantage of \"copy inside\n destination buffer\" feature in the delta interpretation\n code, such packs are not usable by the official git, so\n you need to unpack them using your own version of git\n and then repack with the official version of git.\n"},{"id":"25667","messageId":"7v3bbqyh4g.fsf@assigned-by-dhcp.cox.net","threadId":"5313","inReplyTo":"7vy7tjxdas.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] daemon: prepare for multiple services.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-21T02:09:19Z","receivedAt":"2006-08-21T02:09:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This adds an infrastructure to selectively enable and disable\nmore than one services in git-daemon. Currently upload-pack\nservice, which serves the git-fetch-pack and git-peek-remote\nclients, is the only service that is defined.\n\nSigned-off-by: Junio C Hamano \n---\n daemon.c | 113 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----\n 1 files changed, 106 insertions(+), 7 deletions(-)\n\ndiff --git a/daemon.c b/daemon.c\nindex 012936f..0a6cbb4 100644\n--- a/daemon.c\n+++ b/daemon.c\n@@ -229,13 +229,42 @@ static char *path_ok(char *dir)\n \treturn NULL;\t\t/* Fallthrough. Deny by default */\n }\n \n-static int upload(char *dir)\n+typedef int (*daemon_service_fn)(void);\n+struct daemon_service {\n+\tconst char *name;\n+\tconst char *config_name;\n+\tdaemon_service_fn fn;\n+\tint enabled;\n+\tint overridable;\n+};\n+\n+static struct daemon_service *service_looking_at;\n+static int service_enabled;\n+\n+static int git_daemon_config(const char *var, const char *value)\n+{\n+\tif (!strncmp(var, \"daemon.\", 7) &&\n+\t !strcmp(var + 7, service_looking_at->config_name)) {\n+\t\tservice_enabled = git_config_bool(var, value);\n+\t\treturn 0;\n+\t}\n+\n+\t/* we are not interested in parsing any other configuration here */\n+\treturn 0;\n+}\n+\n+static int run_service(char *dir, struct daemon_service *service)\n {\n-\t/* Timeout as string */\n-\tchar timeout_buf[64];\n \tconst char *path;\n+\tint enabled = service->enabled;\n+\n+\tloginfo(\"Request %s for '%s'\", service->name, dir);\n \n-\tloginfo(\"Request for '%s'\", dir);\n+\tif (!enabled && !service->overridable) {\n+\t\tlogerror(\"'%s': service not enabled.\", service->name);\n+\t\terrno = EACCES;\n+\t\treturn -1;\n+\t}\n \n \tif (!(path = path_ok(dir)))\n \t\treturn -1;\n@@ -257,12 +286,34 @@ static int upload(char *dir)\n \t\treturn -1;\n \t}\n \n+\tif (service->overridable) {\n+\t\tservice_looking_at = service;\n+\t\tservice_enabled = -1;\n+\t\tgit_config(git_daemon_config);\n+\t\tif (0 <= service_enabled)\n+\t\t\tenabled = service_enabled;\n+\t}\n+\tif (!enabled) {\n+\t\tlogerror(\"'%s': service not enabled for '%s'\",\n+\t\t\t service->name, path);\n+\t\terrno = EACCES;\n+\t\treturn -1;\n+\t}\n+\n \t/*\n \t * We'll ignore SIGTERM from now on, we have a\n \t * good client.\n \t */\n \tsignal(SIGTERM, SIG_IGN);\n \n+\treturn service->fn();\n+}\n+\n+static int upload_pack(void)\n+{\n+\t/* Timeout as string */\n+\tchar timeout_buf[64];\n+\n \tsnprintf(timeout_buf, sizeof timeout_buf, \"--timeout=%u\", timeout);\n \n \t/* git-upload-pack only ever reads stuff, so this is safe */\n@@ -270,10 +321,36 @@ static int upload(char *dir)\n \treturn -1;\n }\n \n+static struct daemon_service daemon_service[] = {\n+\t{ \"upload-pack\", \"uploadpack\", upload_pack, 1, 1 },\n+};\n+\n+static void enable_service(const char *name, int ena) {\n+\tint i;\n+\tfor (i = 0; i < ARRAY_SIZE(daemon_service); i++) {\n+\t\tif (!strcmp(daemon_service[i].name, name)) {\n+\t\t\tdaemon_service[i].enabled = ena;\n+\t\t\treturn;\n+\t\t}\n+\t}\n+\tdie(\"No such service %s\", name);\n+}\n+\n+static void make_service_overridable(const char *name, int ena) {\n+\tint i;\n+\tfor (i = 0; i < ARRAY_SIZE(daemon_service); i++) {\n+\t\tif (!strcmp(daemon_service[i].name, name)) {\n+\t\t\tdaemon_service[i].overridable = ena;\n+\t\t\treturn;\n+\t\t}\n+\t}\n+\tdie(\"No such service %s\", name);\n+}\n+\n static int execute(struct sockaddr *addr)\n {\n \tstatic char line[1000];\n-\tint pktlen, len;\n+\tint pktlen, len, i;\n \n \tif (addr) {\n \t\tchar addrbuf[256] = \"\";\n@@ -310,8 +387,14 @@ #endif\n \tif (len && line[len-1] == '\\n')\n \t\tline[--len] = 0;\n \n-\tif (!strncmp(\"git-upload-pack \", line, 16))\n-\t\treturn upload(line+16);\n+\tfor (i = 0; i < ARRAY_SIZE(daemon_service); i++) {\n+\t\tstruct daemon_service *s = &(daemon_service[i]);\n+\t\tint namelen = strlen(s->name);\n+\t\tif (!strncmp(\"git-\", line, 4) &&\n+\t\t !strncmp(s->name, line + 4, namelen) &&\n+\t\t line[namelen + 4] == ' ')\n+\t\t\treturn run_service(line + namelen + 5, s);\n+\t}\n \n \tlogerror(\"Protocol error: '%s'\", line);\n \treturn -1;\n@@ -791,6 +874,22 @@ int main(int argc, char **argv)\n \t\t\tlog_syslog = 1;\n \t\t\tcontinue;\n \t\t}\n+\t\tif (!strncmp(arg, \"--enable=\", 9)) {\n+\t\t\tenable_service(arg + 9, 1);\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (!strncmp(arg, \"--disable=\", 10)) {\n+\t\t\tenable_service(arg + 10, 0);\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (!strncmp(arg, \"--enable-override=\", 18)) {\n+\t\t\tmake_service_overridable(arg + 18, 1);\n+\t\t\tcontinue;\n+\t\t}\n+\t\tif (!strncmp(arg, \"--disable-override=\", 19)) {\n+\t\t\tmake_service_overridable(arg + 19, 0);\n+\t\t\tcontinue;\n+\t\t}\n \t\tif (!strcmp(arg, \"--\")) {\n \t\t\tok_paths = &argv[i+1];\n \t\t\tbreak;\n-- \n1.4.2.g0cac8\n"},{"id":"25668","messageId":"7vsljqx2jm.fsf@assigned-by-dhcp.cox.net","threadId":"5313","inReplyTo":"7vy7tjxdas.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] daemon: add upload-tar service.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-08-21T02:09:33Z","receivedAt":"2006-08-21T02:09:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This allows clients to ask for tarballs with:\n\n\tgit tar-tree --remote=git://server/repo refname\n\nBy default, the upload-tar service is not enabled. To enable\nit server-wide, the server can be started with:\n\n\tgit-daemon --enable=upload-tar\n\nThis service is by default overridable per repostiory, so\nalternatively, a repository can define \"daemon.uploadtar = true\"\nto enable it.\n\nSigned-off-by: Junio C Hamano \n---\n daemon.c | 7 +++++++\n 1 files changed, 7 insertions(+), 0 deletions(-)\n\ndiff --git a/daemon.c b/daemon.c\nindex 0a6cbb4..5549014 100644\n--- a/daemon.c\n+++ b/daemon.c\n@@ -321,8 +321,15 @@ static int upload_pack(void)\n \treturn -1;\n }\n \n+static int upload_tar(void)\n+{\n+\texecl_git_cmd(\"upload-tar\", \".\", NULL);\n+\treturn -1;\n+}\n+\n static struct daemon_service daemon_service[] = {\n \t{ \"upload-pack\", \"uploadpack\", upload_pack, 1, 1 },\n+\t{ \"upload-tar\", \"uploadtar\", upload_tar, 0, 1 },\n };\n \n static void enable_service(const char *name, int ena) {\n-- \n1.4.2.g0cac8\n"},{"id":"25670","messageId":"44E930FE.3030704@gmail.com","threadId":"5313","inReplyTo":"7vk653xa3a.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #3","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2006-08-21T04:05:18Z","receivedAt":"2006-08-21T04:05:18Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Nicolas Pitre writes:\n> \n>> On Fri, 18 Aug 2006, A Large Angry SCM wrote:\n>>\n>>> Historic fact. Between Thu May 19 08:56:22 2005 and Thu Feb 9 21:06:38\n>>> 2006 bit 6 of the first byte of a delta hunk was interpreted to mean\n>>> that the source of the copy was the result buffer. From Thu May 19\n>>> 08:56:22 2005 on, the code to decode delta hunks in type 2 packs was\n>>> available to everyone and anyone interested could make a pack encoder\n>>> that would create packs that the core Git code would correctly read. The\n>>> commit of Thu Feb 9 21:06:38 2006, d60fc, actually introduced a bug\n>>> that would treat valid type 2 packs as invalid.\n> \n> It is more like the said commit made the pack format extensible\n> by declaring the bit reserved for the future use, by declaring\n> retroactively that a type 2 pack that used that bit invalid.\n> And it was deemed a reasonable and safe decision because no\n> official git ever produced a type 2 pack that used that bit,\n> \n> Yes, that was a backward incompatible change, strictly speaking,\n> and probably I should have made an announcement that looked\n> similar to this by Linus:\n> \n> From: Linus Torvalds \n> Subject: CAREFUL! No more delta object support!\n> Date: Mon, 27 Jun 2005 18:14:40 -0700 (PDT)\n> Message-ID: \n> To: Git Mailing List \n> \n> So you could argue I was incompetent not to make a big fuss\n> about this backward incompatibility back then, if you like.\n> \n> I did not think it was worth it back then, and I do not think it\n> is worth it now, either. But if it makes you feel better, I\n> could retroactively make such an announcement about the\n> unofficial bit 6.\n> \n> The announcement would have read like this:\n> \n> The current git code does not support type #2 packs that\n> uses delta with bit 6 to mean \"copy inside destination\n> buffer\". Although the code that interpreted delta data\n> supported bit 6 that way for a brief period of time, no\n> official git ever released produced delta that used the\n> bit that way.\n> \n> In other words, if you have created packs with your own,\n> modified git, that took advantage of \"copy inside\n> destination buffer\" feature in the delta interpretation\n> code, such packs are not usable by the official git, so\n> you need to unpack them using your own version of git\n> and then repack with the official version of git.\n\nPlease read the commit message for commit d60fc. It's type _3_ pack\nfiles that redefined bit 6 to add the extra byte of copy length, not\ntype 2. Thus, no need to retroactively invalidate the type 2 pack files\nthat used copy from result.\n"},{"id":"25823","messageId":"46a038f90608231619j50e08880n7281d6c2c1a6667c@mail.gmail.com","threadId":"5313","inReplyTo":"7vpseyelcw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #3","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-08-23T23:19:59Z","receivedAt":"2006-08-23T23:19:59Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 8/18/06, Junio C Hamano wrote:\n> As everybody has probably noticed already, I am terrible at\n> maintaining \"the current issues\" list. The most recent issue of\n> this series was done when? Back on May 4th this year.\n>\n> Shame on me.\n\nHey, I think you're doing a great job. A small improvement may be to\ncopy these to the wiki for longer term, but we're all lazy about\nmaintaining them.\n\nPerhaps at least have a TODO page? How about what I just placed in\nhttp://git.or.cz/gitwiki/ToDo ? A link to the 'todo' head, and to a\nsearch for 'Unresolved Issues' in the list archives...\n\nShould give newcomers a hint of where things are, and how to gauge\ndirections and interests...\n\n\n\nmartin\n"},{"id":"25905","messageId":"ecnpmb$qpb$1@sea.gmane.org","threadId":"5313","inReplyTo":"7vpseyelcw.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #3","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-08-25T21:22:26Z","receivedAt":"2006-08-25T21:22:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"There was a thread about system-wide and per-user git configuration. Some\npatches were accepted... but it is nowhere documented. Not all ideas are\nincorporated in git.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28272","messageId":"7vfye20xjt.fsf@assigned-by-dhcp.cox.net","threadId":"5313","inReplyTo":"7vpseyelcw.fsf@assigned-by-dhcp.cox.net","subject":"Unresolved issues #4","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-06T06:26:46Z","receivedAt":"2006-10-06T06:26:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Recent issues I am aware of but haven't kept track of closely\nenough and as a result do not have a clue about X-<.\n\nFrom: A Large Angry SCM \nSubject: Notes on Using Git with Subprojects\nMessage-ID: <45196628.9010107@gmail.com>\n\n[jc: a very nice write-up of a subprojects workflow. I do not\n remember if it produced any actionable items, though]\n\nFrom: Franck Bui-Huu \nMessage-ID: <450EABD0.1040102@innova-card.com>\n\nRepeated requests against git-daemon makes it stuck\n\n[jc: does not reproduce easily for me; has anybody seen it?]\n\nFrom: Shawn Pearce \nMessage-ID: <20060926215745.GC8177@spearce.org>\n\ngit-mirror (reverse of git-push --all).\n\n[jc: any progress?]\n\nFrom: Junio C Hamano \nMessage-ID: <7v7izrzpk2.fsf@assigned-by-dhcp.cox.net>\n\nDeal with rfc2822-invalid author mail address in send-email.\n\n[jc: forgot to apply?]\n\nFrom: Nicolas Pitre \nSubject: [PATCH 8/6] let the GIT native protocol use offsets to delta base when\n\n[jc: applied all but I suspect git-push side hasn't been converted?]\n\nFrom: Shawn Pearce \nMessage-ID: <20060930045037.GB18479@spearce.org>\n\n\"git ref-log\" command to interact with ref-log?\n\n[jc: not much interest from users?]\n\nFrom: Stefan Richter \nMessage-ID: <4523EC14.6070806@s5r6.in-berlin.de>\n\nAsciiDoc 8 does not grok documents written for AsciiDoc 7 out of\nthe box.\n\n[jc: status?]\n\nFrom:\tJosh Triplett \nMessage-ID: <451A30E4.50801@freedesktop.org>\n\ngit-split\n\n[jc: no response to the initial review comments]\n"},{"id":"28282","messageId":"eg5co6$g9n$1@sea.gmane.org","threadId":"5313","inReplyTo":"7vfye20xjt.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #4","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-10-06T10:56:48Z","receivedAt":"2006-10-06T10:56:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Recent issues I am aware of but haven't kept track of closely\n> enough and as a result do not have a clue about X-<.\n> \n> From: A Large Angry SCM \n> Subject: Notes on Using Git with Subprojects\n> Message-ID: <45196628.9010107@gmail.com>\n> \n> [jc: a very nice write-up of a subprojects workflow. I do not\n> remember if it produced any actionable items, though]\n\nIt did produce two workflows: the original \"build time\"\nby A Large Angry SCM/Gitzilla, which I think is/will be\navailable at http://git.rsbx.net/Notes/Git_Subprojects.txt\nand second using linked objects and refs. Both I think not\nquite finished; perhaps some of the code could be put\nin 'pu'.\n\nPerhaps to be added to Subpro.txt in 'todo' branch,\nand/or to git wiki...\n\n> From: Shawn Pearce \n> Message-ID: <20060930045037.GB18479@spearce.org>\n> \n> \"git ref-log\" command to interact with ref-log?\n> \n> [jc: not much interest from users?]\n\nI thing it can increase number of reflog users. \n\n> From: Josh Triplett \n> Message-ID: <451A30E4.50801@freedesktop.org>\n> \n> git-split\n\nShould be git-split-hierarchy or git-split-by-directory\nI think. We could have also git-split-history, which would\nsplit current history into archive repository, and active\nrepository with archive repository grafted in; or add to\narchive repository if it exists, regraft active (current work)\nrepository and prune below new grafts. \n\n> [jc: no response to the initial review comments]\n\nIt is \"done once\" problem, and usable only for some repositories,\nso perhaps this is the cause of not many responses.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"28295","messageId":"1160150667.4297.53.camel@cashmere.sps.mot.com","threadId":"5313","inReplyTo":"7vfye20xjt.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #4","fromName":"Jon Loeliger","fromEmail":"jdl@freescale.com","sentAt":"2006-10-06T16:04:27Z","receivedAt":"2006-10-06T16:04:27Z","isPatch":false,"sender":{"key":"jdl@jdl.com","avatar":"https://gravatar.com/avatar/75ce9a10b151acd2c28ec4ab2136dba7b2ff1634530bd04b155981a749d08a64?d=mp&s=160"},"body":"On Fri, 2006-10-06 at 01:26, Junio C Hamano wrote:\n\n> From: Franck Bui-Huu \n> Message-ID: <450EABD0.1040102@innova-card.com>\n> \n> Repeated requests against git-daemon makes it stuck\n> \n> [jc: does not reproduce easily for me; has anybody seen it?]\n\nI've not seen that behavior either. However, I\nsuspect that this might be a poorly described\nissue with _clients_ that are out of date.\nSpecifically, if a client is older than 1.4.2.1,\nit shows up in the git-daemon log as just a\nsingle \"connection from \" line and no\nactual transfer then happens, making it perhaps\nappear \"stuck\".\n\njdl\n"},{"id":"28297","messageId":"20061006161101.GB20024@spearce.org","threadId":"5313","inReplyTo":"eg5co6$g9n$1@sea.gmane.org","subject":"Re: Unresolved issues #4","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-06T16:11:01Z","receivedAt":"2006-10-06T16:11:01Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> > From: Shawn Pearce \n> > Message-ID: <20060930045037.GB18479@spearce.org>\n> > \n> > \"git ref-log\" command to interact with ref-log?\n> > \n> > [jc: not much interest from users?]\n> \n> I thing it can increase number of reflog users. \n\nAgreed and I'd really like to see that command but I have not had the\ntime to do code it myself. What time I am able to make available\nfor Git in the near future needs to be for the window mmap rewrite\nontop of Nico's delta offset changes that are currently in next.\n\nIf nobody gets around to it I'll likely try to pick it up and do it,\nbut that probably won't be for at least a month, maybe two.\n\n-- \nShawn.\n"},{"id":"28298","messageId":"20061006161208.GC20024@spearce.org","threadId":"5313","inReplyTo":"7vfye20xjt.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #4","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-10-06T16:12:08Z","receivedAt":"2006-10-06T16:12:08Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> From: Shawn Pearce \n> Message-ID: <20060926215745.GC8177@spearce.org>\n> \n> git-mirror (reverse of git-push --all).\n> \n> [jc: any progress?]\n\nNo. Back burner. Waaaaaaay back. I have your comments and I'd\nlike to incorporate them and resubmit but I've had other things\ndemanding my time.\n\n-- \nShawn.\n"},{"id":"28303","messageId":"45268A08.6030700@gmail.com","threadId":"5313","inReplyTo":"7vfye20xjt.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues #4","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2006-10-06T16:53:28Z","receivedAt":"2006-10-06T16:53:28Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Recent issues I am aware of but haven't kept track of closely\n> enough and as a result do not have a clue about X-<.\n> \n> From: A Large Angry SCM \n> Subject: Notes on Using Git with Subprojects\n> Message-ID: <45196628.9010107@gmail.com>\n> \n> [jc: a very nice write-up of a subprojects workflow. I do not\n> remember if it produced any actionable items, though]\n> \n\nNo actionable items that I'm aware of.\n"}]}