{"thread":{"id":"6891","subject":"Unresolved issues","startedAt":"2007-02-20T07:28:35Z","lastAt":"2007-02-28T18:06:26Z","messageCount":39,"participants":["Junio C Hamano","Andy Parkins","Linus Torvalds","Nicolas Pitre","Johannes Schindelin","David Lang","Theodore Tso","Martin Waitz","Robin Rosenberg","Brian Gernhardt","Shawn O. Pearce","Julian Phillips","Jakub Narebski","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"35085","messageId":"7virdx1e58.fsf@assigned-by-dhcp.cox.net","threadId":"6891","inReplyTo":null,"subject":"Unresolved issues","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-20T07:28:35Z","receivedAt":"2007-02-20T07:28:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are some issues recently raised on the list, some of them\nwith patches, that have not been resolved satisfactory.\n\n [gmane=http://thread.gmane.org/gmane.comp.version-control.git]\n\n* \"git status\" is not a read-only operation.\n\n It needs to do enough lstat(2) to run \"update-index --refresh\" to come\n up with the information it needs to give. We could do so internally\n without writing out the result to the index (there is a patch to do\n this) even if a repository is not writable.\n\n\t$gmane/39205\n $gmane/39206\n\n However, a big downside of this approach is that doing so\n unconditionally would mean the expensive lstat(2) is wasted\n afterwards.\n\n\t$gmane/39246\n\n Currently an workaround is to run git-runstatus and live with the fact\n that otherwise unmodified but stat-dirty paths to show up in the\n output. I think (iff somebody feels strongly about it) a possible\n compromise would be to see if we can update the index, and do what the\n current code does if we can, and otherwise fall back on the new code\n that does the internal \"update-index --refresh\".\n\n* \"git -p status\" does not honor color.\n\n The problem is that when git-runstatus is run, it already runs as an\n upstream process of a pipe and git_config_colorbool() would say \"oh,\n our output is not a terminal, and we did not start pager ourselves\".\n\n\t$gmane/39919\n\n A patch was proposed to propagate pager_in_use as an environment down\n to subprocesses,\n\n\t$gmane/39936\n\n but I think this would have unintended side effects when scripts want\n to run commands and redirect their output internally for their own use\n (they will get colorized output from lower level in their temporary\n files or v=$(cmd) redirect).\n\n* \"git log -r --raw -z -- path | grep -z SHA-1\" is not very useful. \n\n We would need a separate -Z option that means \"output records are\n separated with NUL, but output fields are not\".\n\n\t$gmane/39207\n\n This would help to solve \"someone mails me a blob, git please tell me\n what it is\" problem.\n\n\t$gmane/39925\n\n* \"git fetch\" between repositories with hundreds of refs.\n\n\t$gmane/39330\n\n There are partial rewrite of the most expensive parts of git-fetch in\n C parked in 'pu'. It might be good enough for public consumption\n without going the whole nine yards. I dunno. I am not very keen on\n rewriting all of \"git fetch\" in C right now, as people seem to be\n still interested in touching it (including \"git bundle\" topic).\n\n* core.autocrlf\n\n Linus and I laid out most of the infrastructure and the basic things\n already seem to work. We even added some tests ;-)\n\n commit 6716027108f426c83038b05baf3f20ceefe6fbd1\n commit 634ede32ae7d4c76e96e88f9cd5c1b3a70ea08ac\n commit d7f4633405acf3dc09798a759463c616c7c49dfd\n commit 6c510bee2013022fbce52f4b0ec0cc593fc0cc48\n\n What's still missing is support for .gitignore like \"these files are\n text\" information.\n\n One thing that might be tricky is what should be done while making a\n merge or checking out from a tree. Ideally, the information should be\n read from the tree that is being extracted, but that would make the\n code structure a little bit, eh, \"interesting\".\n\n* Use update-ref in cvsserver.\n\n It currently does it by hand, which is racy and does not leave traces\n in reflog.\n\n\t$gmane/39541\n\n* Dissociating a repository from its alternates\n\n I sent out a rather elaborate changes in the binary, but what Johannes\n suggests is much easier to implement.\n\n\t$gmane/39834\n\n Volunteers?\n\n* User-wide ignore list\n\n\t$gmane/39809\n\n I am not really sure if this is even a desirable feature, but assuming\n it is, one possible solution would be to do this:\n\n\t$gmane/39820\n\n But I am not going to do this myself; I suspect that it would be\n fairly simple and straightforward that some git-hacker-hopeful should\n be able to.\n\n* git-diff2\n\n It somehow feels a tad ugly that this is a separate command from\n git-diff, but I do not feel strongly enough to fix it myself.\n Currently parked in 'pu'.\n"},{"id":"35093","messageId":"200702200857.02779.andyparkins@gmail.com","threadId":"6891","inReplyTo":"7virdx1e58.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-20T08:57:00Z","receivedAt":"2007-02-20T08:57:00Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 February 20 07:28, Junio C Hamano wrote:\n\n> * Use update-ref in cvsserver.\n>\n> It currently does it by hand, which is racy and does not leave traces\n> in reflog.\n>\n> \t$gmane/39541\n\nI've got a patch for this - I thought I'd sent it and it left my mind - I'll \nsend when I get home.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"35125","messageId":"Pine.LNX.4.64.0702200934270.20368@woody.linux-foundation.org","threadId":"6891","inReplyTo":"7virdx1e58.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-20T17:41:44Z","receivedAt":"2007-02-20T17:41:44Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 19 Feb 2007, Junio C Hamano wrote:\n> \n> * core.autocrlf\n> \n> What's still missing is support for .gitignore like \"these files are\n> text\" information.\n\nWell, we could actually just do that in stages.\n\nWe might start off with just saying \"unlike .gitignore\", we only support \none top-level \".gitattributes\" file. That makes the problem space much \nsimpler, and then we can have code like\n\n\tenum file_type {\n\t\tFILE_AUTO,\n\t\tFILE_BINARY,\n\t\tFILE_TEXT\n\t};\n\n\tstatic enum file_type get_file_type(const char *pathname)\n\t{\n\t\tstatic int has_initialized = 0;\n\n\t\tif (!has_initialized) {\n\t\t\thas_initialized = 1;\n\t\t\tread_file_attributes_file();\n\t\t}\n\t\t... check the filename against our attribute rules ..\n\t}\n\nwhich would be fairly straightforward, and efficient.\n\nIt gets more complicated with per-directory attributes files, because then \nyou need to either open those files *all* the time (stupid and expensive \nif you have thousands of files and hundreds of directories), or you need \nto have some way to cache just the ones you need.\n\n(In fact, it might be perfectly fine to have just a *single* cache, which \nis keyed on the dirname of the pathname: if the dirname changes, just \nthrow the cache away, and read it in from all the subdirectories leading \nto that directory - you'd still re-read stuff, but all the common cases \nwill walk the directory structure in a nice pattern, so you'd have a very \nsimple cache that actually gets good cache hit behaviour)\n\n> One thing that might be tricky is what should be done while making a\n> merge or checking out from a tree. Ideally, the information should be\n> read from the tree that is being extracted, but that would make the\n> code structure a little bit, eh, \"interesting\".\n\nNo, that would be pretty horrid. So just tell everybody that it's based on \nthe working tree. I don't think it's likely to be a problem in practice.\n\n\t\tLinus\n"},{"id":"35137","messageId":"200702202010.02128.andyparkins@gmail.com","threadId":"6891","inReplyTo":"200702200857.02779.andyparkins@gmail.com","subject":"[PATCH] Use git-update-ref to update a ref during commit in git-cvsserver","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-20T20:10:01Z","receivedAt":"2007-02-20T20:10:01Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"Nicholas Pitre mentioned that updating a reference should be done with\ngit-update-ref.\n\nThis patch does that and includes the -m option to have the reflog\nupdated as a bonus.\n\nSigned-off-by: Andy Parkins \n---\nAs promised...\n\n git-cvsserver.perl | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/git-cvsserver.perl b/git-cvsserver.perl\nindex b4ef6bc..54d943a 100755\n--- a/git-cvsserver.perl\n+++ b/git-cvsserver.perl\n@@ -1216,9 +1216,9 @@ sub req_ci\n }\n \n close LOCKFILE;\n- my $reffile = \"$ENV{GIT_DIR}refs/heads/$state->{module}\";\n- unlink($reffile);\n- rename($lockfile, $reffile);\n+ my $reffile = \"refs/heads/$state->{module}\";\n+\t`git-update-ref -m \"git-cvsserver commit\" $reffile $commithash $parenthash`;\n+\tunlink($lockfile);\n chdir \"/\";\n \n print \"ok\\n\";\n-- \n1.5.0.rc4.gb4d2\n"},{"id":"35143","messageId":"7vfy90v729.fsf@assigned-by-dhcp.cox.net","threadId":"6891","inReplyTo":"Pine.LNX.4.64.0702200934270.20368@woody.linux-foundation.org","subject":"Re: Unresolved issues","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-20T21:43:26Z","receivedAt":"2007-02-20T21:43:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> (In fact, it might be perfectly fine to have just a *single* cache, which \n> is keyed on the dirname of the pathname: if the dirname changes, just \n> throw the cache away, and read it in from all the subdirectories leading \n> to that directory - you'd still re-read stuff, but all the common cases \n> will walk the directory structure in a nice pattern, so you'd have a very \n> simple cache that actually gets good cache hit behaviour)\n\nI'd agree that we can start with just a single one at the\ntoplevel and if somebody wants to extend it we can do so later.\n\n>> One thing that might be tricky is what should be done while making a\n>> merge or checking out from a tree. Ideally, the information should be\n>> read from the tree that is being extracted, but that would make the\n>> code structure a little bit, eh, \"interesting\".\n>\n> No, that would be pretty horrid. So just tell everybody that it's based on \n> the working tree. I don't think it's likely to be a problem in practice.\n\nExcept for the initial checkout...\n"},{"id":"35144","messageId":"alpine.LRH.0.82.0702201654310.31945@xanadu.home","threadId":"6891","inReplyTo":"200702202010.02128.andyparkins@gmail.com","subject":"Re: [PATCH] Use git-update-ref to update a ref during commit in git-cvsserver","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-20T21:57:18Z","receivedAt":"2007-02-20T21:57:18Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 20 Feb 2007, Andy Parkins wrote:\n\n> Nicholas Pitre mentioned that updating a reference should be done with\n> git-update-ref.\n> \n> This patch does that and includes the -m option to have the reflog\n> updated as a bonus.\n> \n> Signed-off-by: Andy Parkins \n> ---\n> As promised...\n\nWhat if git-update-ref fails? This may occur if the server repo was \nupdated and the client needs to \"cvs up\" again before commit.\n\n\nNicolas\n"},{"id":"35147","messageId":"Pine.LNX.4.64.0702201621050.4043@woody.linux-foundation.org","threadId":"6891","inReplyTo":"7vfy90v729.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-21T00:21:22Z","receivedAt":"2007-02-21T00:21:22Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\nOn Tue, 20 Feb 2007, Junio C Hamano wrote:\n> >\n> > No, that would be pretty horrid. So just tell everybody that it's based on \n> > the working tree. I don't think it's likely to be a problem in practice.\n> \n> Except for the initial checkout...\n\nYeah, that's true. That's indeed pretty nasty.\n\nThere's also a rather strange special case when you do merges: you can \ncertainly always use the .gitattributes of the working tree, but it will \ncause some interesting issues if new files were added with new patterns.\n\nHowever, we're a bit lucky here (or perhaps \"lucky\" is not the right word: \nwe basically have a good design) where all these actions come down to \"git \nread-tree\", regardless of whether it's checking out the end result of a \ntotally new clone, or a fast-forward update, or a merge. Or a \"git \ncheckout\" or \"git reset\". They all boil down to one thing:\n\n\tgit read-tree -u\n\nand it should be fairly easy to add some simple logic just to \n\"cmd_read_tree()\" to do the right thing. It has the \"main tree\" to use, \nand the logic could be as simple as\n\n\tfd = open(\".gitattributes\", O_RDONLY);\n\tif (fd < 0) {\n\t\t.. try in \"$tree:.gitattributes\" instead ..\n\n\nand it would do the right thing for all the common operations.\n\nAgain, the special case (as always) is\n - git cat-file\n - the file-level merger code (which uses the equivalent of git-cat-file)\nwhich would need to add their own logic for this.\n\n\t\tLinus\n"},{"id":"35148","messageId":"7vabz8uzjo.fsf@assigned-by-dhcp.cox.net","threadId":"6891","inReplyTo":"Pine.LNX.4.64.0702201621050.4043@woody.linux-foundation.org","subject":"Re: Unresolved issues","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-21T00:25:47Z","receivedAt":"2007-02-21T00:25:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Tue, 20 Feb 2007, Junio C Hamano wrote:\n>> >\n>> > No, that would be pretty horrid. So just tell everybody that it's based on \n>> > the working tree. I don't think it's likely to be a problem in practice.\n>> \n>> Except for the initial checkout...\n>\n> Yeah, that's true. That's indeed pretty nasty.\n>\n> There's also a rather strange special case when you do merges: you can \n> certainly always use the .gitattributes of the working tree, but it will \n> cause some interesting issues if new files were added with new patterns.\n\nLet alone the case where you need to merge .gitattributes file\nitself and the conflicting part says something conflicting about\nother paths that needed to be merged and the result need to be\nchecked out ;-).\n\n> However, we're a bit lucky here (or perhaps \"lucky\" is not the right word: \n> we basically have a good design) where all these actions come down to \"git \n> read-tree\", regardless of whether it's checking out the end result of a \n> totally new clone, or a fast-forward update, or a merge. Or a \"git \n> checkout\" or \"git reset\". They all boil down to one thing:\n>\n> \tgit read-tree -u\n>\n> and it should be fairly easy to add some simple logic just to \n> \"cmd_read_tree()\" to do the right thing. It has the \"main tree\" to use, \n> and the logic could be as simple as\n>\n> \tfd = open(\".gitattributes\", O_RDONLY);\n> \tif (fd < 0) {\n> \t\t.. try in \"$tree:.gitattributes\" instead ..\n>\n>\n> and it would do the right thing for all the common operations.\n\nYes. That is what I had in mind when I said \"initial checkout\".\n\n> Again, the special case (as always) is\n> - git cat-file\n> - the file-level merger code (which uses the equivalent of git-cat-file)\n> which would need to add their own logic for this.\n>\n> \t\tLinus\n\nAnd git-apply which is (as usual) on its own.\n"},{"id":"35149","messageId":"Pine.LNX.4.63.0702210136050.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6891","inReplyTo":"Pine.LNX.4.64.0702201621050.4043@woody.linux-foundation.org","subject":"Re: Unresolved issues","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-21T00:39:48Z","receivedAt":"2007-02-21T00:39:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 20 Feb 2007, Linus Torvalds wrote:\n\n> \n> On Tue, 20 Feb 2007, Junio C Hamano wrote:\n> > >\n> > > No, that would be pretty horrid. So just tell everybody that it's based on \n> > > the working tree. I don't think it's likely to be a problem in practice.\n> > \n> > Except for the initial checkout...\n> \n> Yeah, that's true. That's indeed pretty nasty.\n\nUm, I don't want to spoil the party, but was not the original idea of this \nauto-CRLF thing some sort of \"emulation\" of the CVS text checkout \nbehaviour?\n\nIn that case, .gitattributes (I mean a tracked one) would be wrong, wrong, \nwrong.\n\nIt's a local setup if you want auto-CRLF or not. So, why not just make it \na local setting (if in config or $GIT_DIR/info/gitattributes, I don't \ncare) which shell patterns are to be transformed on input and/or output?\n\nCiao,\nDscho\n"},{"id":"35151","messageId":"Pine.LNX.4.63.0702201648450.14284@qynat.qvtvafvgr.pbz","threadId":"6891","inReplyTo":"Pine.LNX.4.64.0702201648000.4043@woody.linux-foundation.org","subject":"Re: Unresolved issues","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-02-21T00:51:44Z","receivedAt":"2007-02-21T00:51:44Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"On Tue, 20 Feb 2007, Linus Torvalds wrote:\n\n> On Wed, 21 Feb 2007, Johannes Schindelin wrote:\n>>\n>> Um, I don't want to spoil the party, but was not the original idea of this\n>> auto-CRLF thing some sort of \"emulation\" of the CVS text checkout\n>> behaviour?\n>>\n>> In that case, .gitattributes (I mean a tracked one) would be wrong, wrong,\n>> wrong.\n>>\n>> It's a local setup if you want auto-CRLF or not. So, why not just make it\n>> a local setting (if in config or $GIT_DIR/info/gitattributes, I don't\n>> care) which shell patterns are to be transformed on input and/or output?\n>\n> That is a good point. We *could* just make it a \".git/config\" issue, which\n> has the nice benefit that you can just set up some user-wide rules rather\n> than making it be per-repo.\n\nsome of the things that .gitattributes is being talked being used for about for \nare local, some are per-repo\n\nper the prior discussion of how many places to check a local configuration \nshould override the per-repo setting.\n\nDavid Lang\n\n>\n> Of course, the config language may not be wonderful for this. But we could\n> certainly have something like\n>\n> \t[format \"crlf\"]\n> \t\tenable = true\n> \t\ttext = *.[ch]\n> \t\tbinary = *.jpg\n>\n> which would just override the built-in rules (where anything that doesn't\n> match is just \"auto-content\"). And make the default built-in ones be good\n> enough that in _practice_ you never even need this in the first place.\n>\n> \t\tLinus\n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"35150","messageId":"Pine.LNX.4.64.0702201648000.4043@woody.linux-foundation.org","threadId":"6891","inReplyTo":"Pine.LNX.4.63.0702210136050.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Unresolved issues","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-21T00:56:07Z","receivedAt":"2007-02-21T00:56:07Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 21 Feb 2007, Johannes Schindelin wrote:\n>\n> Um, I don't want to spoil the party, but was not the original idea of this \n> auto-CRLF thing some sort of \"emulation\" of the CVS text checkout \n> behaviour?\n> \n> In that case, .gitattributes (I mean a tracked one) would be wrong, wrong, \n> wrong.\n> \n> It's a local setup if you want auto-CRLF or not. So, why not just make it \n> a local setting (if in config or $GIT_DIR/info/gitattributes, I don't \n> care) which shell patterns are to be transformed on input and/or output?\n\nThat is a good point. We *could* just make it a \".git/config\" issue, which \nhas the nice benefit that you can just set up some user-wide rules rather \nthan making it be per-repo.\n\nOf course, the config language may not be wonderful for this. But we could \ncertainly have something like\n\n\t[format \"crlf\"]\n\t\tenable = true\n\t\ttext = *.[ch]\n\t\tbinary = *.jpg\n\nwhich would just override the built-in rules (where anything that doesn't \nmatch is just \"auto-content\"). And make the default built-in ones be good \nenough that in _practice_ you never even need this in the first place.\n\n\t\tLinus\n"},{"id":"35152","messageId":"Pine.LNX.4.63.0702210206390.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6891","inReplyTo":"Pine.LNX.4.64.0702201648000.4043@woody.linux-foundation.org","subject":"Re: Unresolved issues","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-21T01:12:50Z","receivedAt":"2007-02-21T01:12:50Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 20 Feb 2007, Linus Torvalds wrote:\n\n> On Wed, 21 Feb 2007, Johannes Schindelin wrote:\n> >\n> > Um, I don't want to spoil the party, but was not the original idea of this \n> > auto-CRLF thing some sort of \"emulation\" of the CVS text checkout \n> > behaviour?\n> > \n> > In that case, .gitattributes (I mean a tracked one) would be wrong, wrong, \n> > wrong.\n> > \n> > It's a local setup if you want auto-CRLF or not. So, why not just make it \n> > a local setting (if in config or $GIT_DIR/info/gitattributes, I don't \n> > care) which shell patterns are to be transformed on input and/or output?\n> \n> That is a good point. We *could* just make it a \".git/config\" issue, \n> which has the nice benefit that you can just set up some user-wide rules \n> rather than making it be per-repo.\n\nYes, that's a nice side effect.\n\n> Of course, the config language may not be wonderful for this.\n\nLike you wrote in your example, most shell patterns are no problem in the \nconfig.\n\n> And make the default built-in ones be good enough that in _practice_ you \n> never even need this in the first place.\n\nThis is really, really important. We already see many users using git, \nexpecting it somehow to figure out what they want without them having read \nTFM.\n\nAnyhow, I am right now talking with Junio (on IRC; my 2nd day wasting \ntime in chatspace ;-), among other things about the import/export filters. \nWe should at least keep in mind that this would be nice to have, and leave \na door open for them when we do this stuff.\n\nCiao,\nDscho\n"},{"id":"35154","messageId":"20070221014924.GC27391@thunk.org","threadId":"6891","inReplyTo":"Pine.LNX.4.63.0702210136050.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Unresolved issues","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-02-21T01:49:24Z","receivedAt":"2007-02-21T01:49:24Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Feb 21, 2007 at 01:39:48AM +0100, Johannes Schindelin wrote:\n> In that case, .gitattributes (I mean a tracked one) would be wrong, wrong, \n> wrong.\n\nWell, some of the uses of .gitattributes that I had propose was to\nassociate file types (and from the file types, a set of check-in,\ncheck-out, diff, and pretty-print helper progams) for things like\nOpenOffice files.\n\nFor those a tracked .gitattributes makes a lot of sense.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"35155","messageId":"alpine.LRH.0.82.0702202003370.31945@xanadu.home","threadId":"6891","inReplyTo":"Pine.LNX.4.64.0702201648000.4043@woody.linux-foundation.org","subject":"Re: Unresolved issues","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-21T01:51:31Z","receivedAt":"2007-02-21T01:51:31Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 20 Feb 2007, Linus Torvalds wrote:\n\n> \n> > It's a local setup if you want auto-CRLF or not. So, why not just make it \n> > a local setting (if in config or $GIT_DIR/info/gitattributes, I don't \n> > care) which shell patterns are to be transformed on input and/or output?\n> \n> That is a good point. We *could* just make it a \".git/config\" issue, which \n> has the nice benefit that you can just set up some user-wide rules rather \n> than making it be per-repo.\n> \n> Of course, the config language may not be wonderful for this. But we could \n> certainly have something like\n> \n> \t[format \"crlf\"]\n> \t\tenable = true\n> \t\ttext = *.[ch]\n> \t\tbinary = *.jpg\n\nI think this is not generic enough. For one thing this should not be \nused for crlf only. There is also the binary patch generation code that \nwants to know if a file is binary or not.\n\nWhat about:\n\n\t[filetype \"text\"]\n\t\tmatch=*.[ch]\n\t\tattribute=text\n\t\tcrlfmangle=true\n\n\t[filetype \"images\"]\n\t\tmatch=*.jpg\n\t\tattribute=binary\n\t\tmerge=special_jpg_merger\n\netc.\n\n\nNicolas\n"},{"id":"35156","messageId":"Pine.LNX.4.64.0702201758560.4043@woody.linux-foundation.org","threadId":"6891","inReplyTo":"alpine.LRH.0.82.0702202003370.31945@xanadu.home","subject":"Re: Unresolved issues","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-02-21T02:03:59Z","receivedAt":"2007-02-21T02:03:59Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 20 Feb 2007, Nicolas Pitre wrote:\n>\n> I think this is not generic enough. For one thing this should not be \n> used for crlf only. There is also the binary patch generation code that \n> wants to know if a file is binary or not.\n> \n> What about:\n> \n> \t[filetype \"text\"]\n> \t\tmatch=*.[ch]\n> \t\tattribute=text\n> \t\tcrlfmangle=true\n> \n> \t[filetype \"images\"]\n> \t\tmatch=*.jpg\n> \t\tattribute=binary\n> \t\tmerge=special_jpg_merger\n\nYes, that's a much nicer format - both more readable, and more generic. \n\nAlthough I'd just suggest skipping the \"crlfmangle\". Just document the \nfact that for \"attribute=text\", we mangle line-endings as per the rules \ndefined elsewhere (which is possibly different for input/output in \naddition for the normal unix/windows rule changes)\n\nAnd then you can just have multiple \"match=\" rules, so that you don't need \nto make one complex one. \n\n\t\tLinus\n"},{"id":"35161","messageId":"7vmz38t5r4.fsf@assigned-by-dhcp.cox.net","threadId":"6891","inReplyTo":"200702202010.02128.andyparkins@gmail.com","subject":"Re: [PATCH] Use git-update-ref to update a ref during commit in git-cvsserver","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-21T05:54:39Z","receivedAt":"2007-02-21T05:54:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> As promised...\n>\n> git-cvsserver.perl | 6 +++---\n> 1 files changed, 3 insertions(+), 3 deletions(-)\n>\n> diff --git a/git-cvsserver.perl b/git-cvsserver.perl\n> index b4ef6bc..54d943a 100755\n> --- a/git-cvsserver.perl\n> +++ b/git-cvsserver.perl\n> @@ -1216,9 +1216,9 @@ sub req_ci\n> }\n> \n> close LOCKFILE;\n> - my $reffile = \"$ENV{GIT_DIR}refs/heads/$state->{module}\";\n> - unlink($reffile);\n> - rename($lockfile, $reffile);\n> + my $reffile = \"refs/heads/$state->{module}\";\n> +\t`git-update-ref -m \"git-cvsserver commit\" $reffile $commithash $parenthash`;\n> +\tunlink($lockfile);\n> chdir \"/\";\n> \n> print \"ok\\n\";\n\nUsing its own lockfile to update ref by hand while running\nupdate-ref alongside it feels _very_ wrong. How about this one\ninstead?\n\n-- >8 --\n[PATCH] Make 'cvs ci' lockless\n\nThis makes \"ci\" codepath lockless by following the usual\n\"remember the tip, do your thing, then compare and swap at the\nend\" update pattern using update-ref. Incidentally, by updating\nthe code that reads where the tip of the head is to use\nshow-ref, it makes it safe to use in a repository whose refs are\npack-pruned.\n\nI noticed that other parts of the program are not yet pack-refs\nsafe, but tried to keep the changes to the minimum.\n\nNow I rarely use git-cvsserver myself, so I may be completely\nbreaking the check-in codepath. Buyers beware...\n\n---\n\n git-cvsserver.perl | 41 ++++++++++++++++-------------------------\n 1 files changed, 16 insertions(+), 25 deletions(-)\n\ndiff --git a/git-cvsserver.perl b/git-cvsserver.perl\nindex 9371788..471621b 100755\n--- a/git-cvsserver.perl\n+++ b/git-cvsserver.perl\n@@ -1031,36 +1031,35 @@ sub req_ci\n exit;\n }\n \n- my $lockfile = \"$state->{CVSROOT}/refs/heads/$state->{module}.lock\";\n- unless ( sysopen(LOCKFILE,$lockfile,O_EXCL|O_CREAT|O_WRONLY) )\n- {\n- $log->warn(\"lockfile '$lockfile' already exists, please try again\");\n- print \"error 1 Lock file '$lockfile' already exists, please try again\\n\";\n- exit;\n- }\n-\n # Grab a handle to the SQLite db and do any necessary updates\n my $updater = GITCVS::updater->new($state->{CVSROOT}, $state->{module}, $log);\n $updater->update();\n \n my $tmpdir = tempdir ( DIR => $TEMP_DIR );\n my ( undef, $file_index ) = tempfile ( DIR => $TEMP_DIR, OPEN => 0 );\n- $log->info(\"Lock successful, basing commit on '$tmpdir', index file is '$file_index'\");\n+ $log->info(\"Lockless commit start, basing commit on '$tmpdir', index file is '$file_index'\");\n \n $ENV{GIT_DIR} = $state->{CVSROOT} . \"/\";\n $ENV{GIT_INDEX_FILE} = $file_index;\n \n+ # Remember where the head was at the beginning.\n+ my $parenthash = `git show-ref -s refs/heads/$state->{module}`;\n+ chomp $parenthash;\n+ if ($parenthash !~ /^[0-9a-f]{40}$/) {\n+\t print \"error 1 pserver cannot find the current HEAD of module\";\n+\t exit;\n+ }\n+\n chdir $tmpdir;\n \n # populate the temporary index based\n- system(\"git-read-tree\", $state->{module});\n+ system(\"git-read-tree\", $parenthash);\n unless ($? == 0)\n {\n \tdie \"Error running git-read-tree $state->{module} $file_index $!\";\n }\n $log->info(\"Created index '$file_index' with for head $state->{module} - exit status $?\");\n \n-\n my @committedfiles = ();\n \n # foreach file specified on the command line ...\n@@ -1095,8 +1094,6 @@ sub req_ci\n {\n # fail everything if an up to date check fails\n print \"error 1 Up to date check failed for $filename\\n\";\n- close LOCKFILE;\n- unlink($lockfile);\n chdir \"/\";\n exit;\n }\n@@ -1139,16 +1136,12 @@ sub req_ci\n {\n print \"E No files to commit\\n\";\n print \"ok\\n\";\n- close LOCKFILE;\n- unlink($lockfile);\n chdir \"/\";\n return;\n }\n \n my $treehash = `git-write-tree`;\n- my $parenthash = `cat $ENV{GIT_DIR}refs/heads/$state->{module}`;\n chomp $treehash;\n- chomp $parenthash;\n \n $log->debug(\"Treehash : $treehash, Parenthash : $parenthash\");\n \n@@ -1165,13 +1158,16 @@ sub req_ci\n {\n $log->warn(\"Commit failed (Invalid commit hash)\");\n print \"error 1 Commit failed (unknown reason)\\n\";\n- close LOCKFILE;\n- unlink($lockfile);\n chdir \"/\";\n exit;\n }\n \n- print LOCKFILE $commithash;\n+ if (system(qw(git update-ref -m), \"cvsserver ci\",\n+\t \"refs/heads/$state->{module}\", $commithash, $parenthash)) {\n+\t $log->warn(\"update-ref for $state->{module} failed.\");\n+\t print \"error 1 Cannot commit -- update first\\n\";\n+\t exit;\n+ }\n \n $updater->update();\n \n@@ -1200,12 +1196,7 @@ sub req_ci\n }\n }\n \n- close LOCKFILE;\n- my $reffile = \"$ENV{GIT_DIR}refs/heads/$state->{module}\";\n- unlink($reffile);\n- rename($lockfile, $reffile);\n chdir \"/\";\n-\n print \"ok\\n\";\n }\n \n"},{"id":"35170","messageId":"200702210908.59579.andyparkins@gmail.com","threadId":"6891","inReplyTo":"7vmz38t5r4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Use git-update-ref to update a ref during commit in git-cvsserver","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-21T09:08:54Z","receivedAt":"2007-02-21T09:08:54Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2007 February 21 05:54, Junio C Hamano wrote:\n\n> This makes \"ci\" codepath lockless by following the usual\n> \"remember the tip, do your thing, then compare and swap at the\n> end\" update pattern using update-ref. Incidentally, by updating\n\nLooks much better than mine (obviously). I'll run it for a few days and \nreport back.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\nandyparkins@gmail.com\n"},{"id":"35173","messageId":"20070221104209.GM21842@admingilde.org","threadId":"6891","inReplyTo":"Pine.LNX.4.63.0702210136050.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Unresolved issues","fromName":"Martin Waitz","fromEmail":"tali@admingilde.org","sentAt":"2007-02-21T10:42:09Z","receivedAt":"2007-02-21T10:42:09Z","isPatch":false,"sender":{"key":"tali@admingilde.org","avatar":"https://gravatar.com/avatar/3f89b03eee362187effabe257898735b475673a12265c398ea9161259ae91553?d=mp&s=160"},"body":"hoi :)\n\nOn Wed, Feb 21, 2007 at 01:39:48AM +0100, Johannes Schindelin wrote:\n> In that case, .gitattributes (I mean a tracked one) would be wrong, wrong, \n> wrong.\n\nI don't think so.\n\n> It's a local setup if you want auto-CRLF or not. So, why not just make it \n> a local setting (if in config or $GIT_DIR/info/gitattributes, I don't \n> care) which shell patterns are to be transformed on input and/or output?\n\nThe file-type/whatever information about paths is per repository.\nWhether you want to do crlf conversion for \"text\" files is a local\nsetting. So I do think that a tracked .gitattributes makes sense.\n\nOf course you also need some local settings (e.g. in .git/config) to\nuse that information. Perhaps something like:\n\n[filetype \"text*\"]\n\tAutoCRLF = yes\n\n[filetype \"text/xml\"]\n\tMerge = xml-merge -whatever\n\n-- \nMartin Waitz\n"},{"id":"35177","messageId":"Pine.LNX.4.63.0702211348060.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6891","inReplyTo":"20070221104209.GM21842@admingilde.org","subject":"Re: Unresolved issues","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-21T12:55:16Z","receivedAt":"2007-02-21T12:55:16Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 21 Feb 2007, Martin Waitz wrote:\n\n> On Wed, Feb 21, 2007 at 01:39:48AM +0100, Johannes Schindelin wrote:\n> > In that case, .gitattributes (I mean a tracked one) would be wrong, \n> > wrong, wrong.\n> \n> I don't think so.\n\nWhat you conveniently \"forgot\" to quote was the case: if we want this to \ndecide on when to use crlf<->lf transformation, we should decide that \nlocally.\n\nBut you are probably right: the information if a file _is_ fair game for \ncrlf munging is probably something we might want to _be able_ to have \ntracked.\n\nBUT there are a whole lot of problems with that approach, as Junio pointed \nout, like merging attributes files, like what to do if a file is not \nchanged by a commit, but its attributes are, etc.\n\nSo, why not make the autodetection really brilliant at first, and _if_ we \nhit a hard case which cannot be autodetect, _then_ add .gitattributes \nwhich should _only_ force settings on misdetected files?\n\nCiao,\nDscho\n"},{"id":"35180","messageId":"200702211732.38268.robin.rosenberg.lists@dewire.com","threadId":"6891","inReplyTo":"Pine.LNX.4.64.0702201648000.4043@woody.linux-foundation.org","subject":"Re: Unresolved issues","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-02-21T16:32:37Z","receivedAt":"2007-02-21T16:32:37Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"onsdag 21 februari 2007 01:56 skrev Linus Torvalds:\n> \n> On Wed, 21 Feb 2007, Johannes Schindelin wrote:\n> >\n> > Um, I don't want to spoil the party, but was not the original idea of this \n> > auto-CRLF thing some sort of \"emulation\" of the CVS text checkout \n> > behaviour?\n> > \n> > In that case, .gitattributes (I mean a tracked one) would be wrong, wrong, \n> > wrong.\n> > \n> > It's a local setup if you want auto-CRLF or not. So, why not just make it \n> > a local setting (if in config or $GIT_DIR/info/gitattributes, I don't \n> > care) which shell patterns are to be transformed on input and/or output?\n> \n> That is a good point. We *could* just make it a \".git/config\" issue, which \n> has the nice benefit that you can just set up some user-wide rules rather \n> than making it be per-repo.\n> \n> Of course, the config language may not be wonderful for this. But we could \n> certainly have something like\n> \n> \t[format \"crlf\"]\n> \t\tenable = true\n> \t\ttext = *.[ch]\n> \t\tbinary = *.jpg\n\nThe decision whether to mangel at all shoule be local. Which files to mangle, if mangle is \"on\",\nshould be a per version (not like CVS' setting for all versions). Otherwise it won't\nbe propagated properly on push/pull, and people *will* get it wrong over and over. \n\nIt it's .gitattributes or similar it can be merged as any other file and conflicts can be resolved like\nany other file. For efficiency you can have one .gitattributes.\n\nHopefully it won't happen often because autodetection is soo good, but when it get's \nwrong it's important that it can be fixed and distributed properly.\n\n-- robin\n"},{"id":"35184","messageId":"09D527A1-43E2-41A1-AC46-71F64BC409C2@silverinsanity.com","threadId":"6891","inReplyTo":"Pine.LNX.4.63.0702211348060.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Unresolved issues","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2007-02-21T16:57:06Z","receivedAt":"2007-02-21T16:57:06Z","isPatch":false,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Feb 21, 2007, at 7:55 AM, Johannes Schindelin wrote:\n\n> What you conveniently \"forgot\" to quote was the case: if we want \n> this to\n> decide on when to use crlf<->lf transformation, we should decide that\n> locally.\n\nIt seems to me that a tracked .gitattributes file should have things \nlike\n\n*.txt: text\n*.gif: binary\n*.[ch]: text\n\nAnd the .git/config should have\n\n[attribute \"text\"]\n mangle = crlf\n\n[attribute \"binary\"]\n merge = none\n\nThe type of each file should be tracked, but what to do with each \ntype is a local issue. Trying to merge the two is madness.\n\n~~ Brian\n"},{"id":"35186","messageId":"20070221170539.GI25559@spearce.org","threadId":"6891","inReplyTo":"09D527A1-43E2-41A1-AC46-71F64BC409C2@silverinsanity.com","subject":"Re: Unresolved issues","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-02-21T17:05:39Z","receivedAt":"2007-02-21T17:05:39Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Brian Gernhardt wrote:\n> It seems to me that a tracked .gitattributes file should have things \n> like\n> \n> *.txt: text\n> *.gif: binary\n> *.[ch]: text\n> \n> And the .git/config should have\n> \n> [attribute \"text\"]\n> mangle = crlf\n> \n> [attribute \"binary\"]\n> merge = none\n> \n> The type of each file should be tracked, but what to do with each \n> type is a local issue. Trying to merge the two is madness.\n\nYes, exactly. :-)\n\nI would also recommend that we encourage use of standard MIME types\nto define the file types, but don't enforce it. Thus I can setup\nsomething like:\n\n cat >.gitattributes <>.git/config <\n---\n\n Junio C Hamano writes:\n\n > [gmane=http://thread.gmane.org/gmane.comp.version-control.git]\n >\n > * \"git status\" is not a read-only operation.\n >\n > It needs to do enough lstat(2) to run \"update-index --refresh\" to come\n > up with the information it needs to give. We could do so internally\n > without writing out the result to the index (there is a patch to do\n > this) even if a repository is not writable.\n >\n > $gmane/39205\n > $gmane/39206\n >\n > However, a big downside of this approach is that doing so\n > unconditionally would mean the expensive lstat(2) is wasted\n > afterwards.\n >\n > $gmane/39246\n >\n > Currently an workaround is to run git-runstatus and live with the fact\n > that otherwise unmodified but stat-dirty paths to show up in the\n > output. I think (iff somebody feels strongly about it) a possible\n > compromise would be to see if we can update the index, and do what the\n > current code does if we can, and otherwise fall back on the new code\n > that does the internal \"update-index --refresh\".\n\n I did not feel strongly enough about it, so here is another\n approach.\n\n git-commit.sh | 21 +++++++++++----------\n 1 files changed, 11 insertions(+), 10 deletions(-)\n\ndiff --git a/git-commit.sh b/git-commit.sh\nindex ec506d9..cfa1511 100755\n--- a/git-commit.sh\n+++ b/git-commit.sh\n@@ -13,10 +13,10 @@ git-rev-parse --verify HEAD >/dev/null 2>&1 || initial_commit=t\n case \"$0\" in\n *status)\n \tstatus_only=t\n-\tunmerged_ok_if_status=--unmerged ;;\n+\t;;\n *commit)\n \tstatus_only=\n-\tunmerged_ok_if_status= ;;\n+\t;;\n esac\n \n refuse_partial () {\n@@ -389,16 +389,17 @@ else\n \tUSE_INDEX=\"$THIS_INDEX\"\n fi\n \n-GIT_INDEX_FILE=\"$USE_INDEX\" \\\n-\tgit-update-index -q $unmerged_ok_if_status --refresh || exit\n-\n-################################################################\n-# If the request is status, just show it and exit.\n-\n-case \"$0\" in\n-*status)\n+case \"$status_only\" in\n+t)\n+\t# This will silently fail in a read-only repository, which is\n+\t# what we want.\n+\tGIT_INDEX_FILE=\"$USE_INDEX\" git-update-index -q --unmerged --refresh\n \trun_status\n \texit $?\n+\t;;\n+'')\n+\tGIT_INDEX_FILE=\"$USE_INDEX\" git-update-index -q --refresh || exit\n+\t;;\n esac\n \n ################################################################\n-- \n1.5.0.1.619.g04c5c\n"},{"id":"35220","messageId":"7vhctek30q.fsf_-_@assigned-by-dhcp.cox.net","threadId":"6891","inReplyTo":"7vmz36k33y.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] update-index: do not die too early in a read-only repository.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-22T08:30:45Z","receivedAt":"2007-02-22T08:30:45Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This delays the error exit from hold_lock_file_for_update() in\nupdate-index, so that \"update-index --refresh\" in a read-only\nrepository can still report what paths are stat-dirty before\nexiting.\n\nAlso it makes -q to squelch the error message.\n\nSigned-off-by: Junio C Hamano \n---\n builtin-update-index.c | 11 ++++++++++-\n 1 files changed, 10 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-update-index.c b/builtin-update-index.c\nindex 1ac613a..3fbdc67 100644\n--- a/builtin-update-index.c\n+++ b/builtin-update-index.c\n@@ -486,6 +486,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)\n \tint prefix_length = prefix ? strlen(prefix) : 0;\n \tchar set_executable_bit = 0;\n \tunsigned int refresh_flags = 0;\n+\tint lock_error = 0;\n \tstruct lock_file *lock_file;\n \n \tgit_config(git_default_config);\n@@ -493,7 +494,9 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)\n \t/* We can't free this memory, it becomes part of a linked list parsed atexit() */\n \tlock_file = xcalloc(1, sizeof(struct lock_file));\n \n-\tnewfd = hold_lock_file_for_update(lock_file, get_index_file(), 1);\n+\tnewfd = hold_lock_file_for_update(lock_file, get_index_file(), 0);\n+\tif (newfd < 0)\n+\t\tlock_error = errno;\n \n \tentries = read_cache();\n \tif (entries < 0)\n@@ -650,6 +653,12 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)\n \n finish:\n \tif (active_cache_changed) {\n+\t\tif (newfd < 0) {\n+\t\t\tif (refresh_flags & REFRESH_QUIET)\n+\t\t\t\texit(128);\n+\t\t\tdie(\"unable to create '%s.lock': %s\",\n+\t\t\t get_index_file(), strerror(lock_error));\n+\t\t}\n \t\tif (write_cache(newfd, active_cache, active_nr) ||\n \t\t close(newfd) || commit_lock_file(lock_file))\n \t\t\tdie(\"Unable to write new index file\");\n-- \n1.5.0.1.619.g04c5c\n"},{"id":"35481","messageId":"Pine.LNX.4.64.0702260112160.12555@beast.quantumfyre.co.uk","threadId":"6891","inReplyTo":"7virdx1e58.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-02-26T01:33:47Z","receivedAt":"2007-02-26T01:33:47Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Mon, 19 Feb 2007, Junio C Hamano wrote:\n\n> * \"git fetch\" between repositories with hundreds of refs.\n>\n> \t$gmane/39330\n>\n> There are partial rewrite of the most expensive parts of git-fetch in\n> C parked in 'pu'. It might be good enough for public consumption\n> without going the whole nine yards. I dunno. I am not very keen on\n> rewriting all of \"git fetch\" in C right now, as people seem to be\n> still interested in touching it (including \"git bundle\" topic).\n\nThe current changes in jc/fetch take things from \"unusable\" to \"a bit \nslow\", which I think could quite easily be considered a separate task from \n\"a bit slow\" to \"something that even Linus would consider reasonable\". So \nmy opinion would be to get the current improvements in so that they can be \ncombined with the other good work happening in this area, and wait for \nthings to settle before going the last mile (after all anyone converting \nfrom Subversion or CVS probably won't find 30s to be slow anyway ... ;)).\n\nI would be happy to work on this if you would rather spend your time on \nmore generally useful things ...\n\n-- \nJulian\n\n ---\nStewie Griffin: [thinks] How wonderful it will be to have mother back!\nBrian Griffin: [thinks] I heard that.\nStewie Griffin: [thinks] Damn!\n"},{"id":"35488","messageId":"7vtzx9oaeb.fsf@assigned-by-dhcp.cox.net","threadId":"6891","inReplyTo":"Pine.LNX.4.64.0702260112160.12555@beast.quantumfyre.co.uk","subject":"Re: Unresolved issues","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-26T03:39:08Z","receivedAt":"2007-02-26T03:39:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Phillips writes:\n\n> On Mon, 19 Feb 2007, Junio C Hamano wrote:\n>\n>> * \"git fetch\" between repositories with hundreds of refs.\n>>\n>> \t$gmane/39330\n>>\n>> There are partial rewrite of the most expensive parts of git-fetch in\n>> C parked in 'pu'. It might be good enough for public consumption\n>> without going the whole nine yards. I dunno. I am not very keen on\n>> rewriting all of \"git fetch\" in C right now, as people seem to be\n>> still interested in touching it (including \"git bundle\" topic).\n>\n> The current changes in jc/fetch take things from \"unusable\" to \"a bit\n> slow\", which I think could quite easily be considered a separate task\n> from \"a bit slow\" to \"something that even Linus would consider\n> reasonable\". So my opinion would be to get the current improvements\n> in so that they can be combined with the other good work happening in\n> this area, and wait for things to settle before going the last mile\n> (after all anyone converting from Subversion or CVS probably won't\n> find 30s to be slow anyway ... ;)).\n\nI was kind of waiting for dust from Santi's code shuffling to\nsettle down, because the series moderately conflicts with it. I\nwanted to take Santi's patch first as it was supposed to be a\nclean-up without any functionality changes, although it was kind\nof painful to really make sure there is no regression.\n\nIf what jc/fetch topic tries to do helps real users, let's merge\nit in 'next' first, as Santi's change is not supposed to bring\nany improvements by itself even when it proves regression-free.\n\nIn the short term, this means we have to ask Santi to rebase his\npatch instead of the other way around as I planned first, which\nis a bit unfortunate.\n"},{"id":"35490","messageId":"Pine.LNX.4.64.0702260455020.16708@beast.quantumfyre.co.uk","threadId":"6891","inReplyTo":"7vtzx9oaeb.fsf@assigned-by-dhcp.cox.net","subject":"Re: Unresolved issues","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-02-26T05:10:33Z","receivedAt":"2007-02-26T05:10:33Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 25 Feb 2007, Junio C Hamano wrote:\n\n> Julian Phillips writes:\n>\n>> On Mon, 19 Feb 2007, Junio C Hamano wrote:\n>>\n>>> * \"git fetch\" between repositories with hundreds of refs.\n>>>\n>>> \t$gmane/39330\n>>>\n>>> There are partial rewrite of the most expensive parts of git-fetch in\n>>> C parked in 'pu'. It might be good enough for public consumption\n>>> without going the whole nine yards. I dunno. I am not very keen on\n>>> rewriting all of \"git fetch\" in C right now, as people seem to be\n>>> still interested in touching it (including \"git bundle\" topic).\n>>\n>> The current changes in jc/fetch take things from \"unusable\" to \"a bit\n>> slow\", which I think could quite easily be considered a separate task\n>> from \"a bit slow\" to \"something that even Linus would consider\n>> reasonable\". So my opinion would be to get the current improvements\n>> in so that they can be combined with the other good work happening in\n>> this area, and wait for things to settle before going the last mile\n>> (after all anyone converting from Subversion or CVS probably won't\n>> find 30s to be slow anyway ... ;)).\n>\n> I was kind of waiting for dust from Santi's code shuffling to\n> settle down, because the series moderately conflicts with it. I\n> wanted to take Santi's patch first as it was supposed to be a\n> clean-up without any functionality changes, although it was kind\n> of painful to really make sure there is no regression.\n\nIndeed. I was thinking pretty much the same. It seems unnecessary to \nmake Santi rebase his patch without any evidence that the jc/fetch topic \nis actually urgently needed by anyone.\n\nI was advocating a two step approach, but I didn't mean to give the \nimpressions that I wanted the topic merged now. I envisioned both steps \nas being after the current active work that is affecting git-fetch. \nThanks to the power of git I have got myself a master+jc/fetch branch so \nI'm happy - so unless there is anyone else out there working with stupidly \nlarge numbers of refs I'm quite happy to let Santi's work go in first. \nI'll even have a go at rebasing the fetch improvements ontop of Santi's \nwork ...\n\n>\n> If what jc/fetch topic tries to do helps real users, let's merge\n> it in 'next' first, as Santi's change is not supposed to bring\n> any improvements by itself even when it proves regression-free.\n>\n> In the short term, this means we have to ask Santi to rebase his\n> patch instead of the other way around as I planned first, which\n> is a bit unfortunate.\n\nUnless there is someone else out there that wants jc/fetch badly, I would \nsay \"after you\" ...\n\n-- \nJulian\n\n ---\n This report is filled with omissions.\n"},{"id":"35491","messageId":"7v8xelo52x.fsf@assigned-by-dhcp.cox.net","threadId":"6891","inReplyTo":"Pine.LNX.4.64.0702260455020.16708@beast.quantumfyre.co.uk","subject":"Re: Unresolved issues","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-26T05:33:58Z","receivedAt":"2007-02-26T05:33:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Phillips writes:\n\n>> I was kind of waiting for dust from Santi's code shuffling to\n>> settle down, because the series moderately conflicts with it. I\n>> wanted to take Santi's patch first as it was supposed to be a\n>> clean-up without any functionality changes, although it was kind\n>> of painful to really make sure there is no regression.\n>\n> Indeed. I was thinking pretty much the same. It seems unnecessary to\n> make Santi rebase his patch without any evidence that the jc/fetch\n> topic is actually urgently needed by anyone.\n\nSorry, too late --- it's a done deal. Partial C rewrite of\ngit-fetch is now in 'next'.\n"},{"id":"35603","messageId":"200702271248.59652.andyparkins@gmail.com","threadId":"6891","inReplyTo":"200702210908.59579.andyparkins@gmail.com","subject":"[PATCH 1/2] Make 'cvs ci' lockless in git-cvsserver by using git-update-ref","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-27T12:48:59Z","receivedAt":"2007-02-27T12:48:59Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"This makes \"ci\" codepath lockless by following the usual\n\"remember the tip, do your thing, then compare and swap at the\nend\" update pattern using update-ref. Incidentally, by updating\nthe code that reads where the tip of the head is to use\nshow-ref, it makes it safe to use in a repository whose refs are\npack-pruned.\n\nI noticed that other parts of the program are not yet pack-refs\nsafe, but tried to keep the changes to the minimum.\n\nSigned-off-by: Junio C Hamano \n---\nThis patch is actually yours (with one extra removal of lock file reference\nthat you'd missed, and a change of shortlog), but I don't know how to send\nan email that comes from me but attributes authorship to you.\n\n\n git-cvsserver.perl | 43 ++++++++++++++++---------------------------\n 1 files changed, 16 insertions(+), 27 deletions(-)\n\ndiff --git a/git-cvsserver.perl b/git-cvsserver.perl\nindex 84520e7..8e12f81 100755\n--- a/git-cvsserver.perl\n+++ b/git-cvsserver.perl\n@@ -1031,36 +1031,35 @@ sub req_ci\n exit;\n }\n \n- my $lockfile = \"$state->{CVSROOT}/refs/heads/$state->{module}.lock\";\n- unless ( sysopen(LOCKFILE,$lockfile,O_EXCL|O_CREAT|O_WRONLY) )\n- {\n- $log->warn(\"lockfile '$lockfile' already exists, please try again\");\n- print \"error 1 Lock file '$lockfile' already exists, please try again\\n\";\n- exit;\n- }\n-\n # Grab a handle to the SQLite db and do any necessary updates\n my $updater = GITCVS::updater->new($state->{CVSROOT}, $state->{module}, $log);\n $updater->update();\n \n my $tmpdir = tempdir ( DIR => $TEMP_DIR );\n my ( undef, $file_index ) = tempfile ( DIR => $TEMP_DIR, OPEN => 0 );\n- $log->info(\"Lock successful, basing commit on '$tmpdir', index file is '$file_index'\");\n+ $log->info(\"Lockless commit start, basing commit on '$tmpdir', index file is '$file_index'\");\n \n $ENV{GIT_DIR} = $state->{CVSROOT} . \"/\";\n $ENV{GIT_INDEX_FILE} = $file_index;\n \n+ # Remember where the head was at the beginning.\n+ my $parenthash = `git show-ref -s refs/heads/$state->{module}`;\n+ chomp $parenthash;\n+ if ($parenthash !~ /^[0-9a-f]{40}$/) {\n+\t print \"error 1 pserver cannot find the current HEAD of module\";\n+\t exit;\n+ }\n+\n chdir $tmpdir;\n \n # populate the temporary index based\n- system(\"git-read-tree\", $state->{module});\n+ system(\"git-read-tree\", $parenthash);\n unless ($? == 0)\n {\n \tdie \"Error running git-read-tree $state->{module} $file_index $!\";\n }\n $log->info(\"Created index '$file_index' with for head $state->{module} - exit status $?\");\n \n-\n my @committedfiles = ();\n \n # foreach file specified on the command line ...\n@@ -1095,8 +1094,6 @@ sub req_ci\n {\n # fail everything if an up to date check fails\n print \"error 1 Up to date check failed for $filename\\n\";\n- close LOCKFILE;\n- unlink($lockfile);\n chdir \"/\";\n exit;\n }\n@@ -1139,16 +1136,12 @@ sub req_ci\n {\n print \"E No files to commit\\n\";\n print \"ok\\n\";\n- close LOCKFILE;\n- unlink($lockfile);\n chdir \"/\";\n return;\n }\n \n my $treehash = `git-write-tree`;\n- my $parenthash = `cat $ENV{GIT_DIR}refs/heads/$state->{module}`;\n chomp $treehash;\n- chomp $parenthash;\n \n $log->debug(\"Treehash : $treehash, Parenthash : $parenthash\");\n \n@@ -1165,8 +1158,6 @@ sub req_ci\n {\n $log->warn(\"Commit failed (Invalid commit hash)\");\n print \"error 1 Commit failed (unknown reason)\\n\";\n- close LOCKFILE;\n- unlink($lockfile);\n chdir \"/\";\n exit;\n }\n@@ -1179,14 +1170,17 @@ sub req_ci\n \t\t{\n \t\t\t$log->warn(\"Commit failed (update hook declined to update ref)\");\n \t\t\tprint \"error 1 Commit failed (update hook declined)\\n\";\n-\t\t\tclose LOCKFILE;\n-\t\t\tunlink($lockfile);\n \t\t\tchdir \"/\";\n \t\t\texit;\n \t\t}\n \t}\n \n- print LOCKFILE $commithash;\n+\tif (system(qw(git update-ref -m), \"cvsserver ci\",\n+\t\t\t\"refs/heads/$state->{module}\", $commithash, $parenthash)) {\n+\t\t$log->warn(\"update-ref for $state->{module} failed.\");\n+\t\tprint \"error 1 Cannot commit -- update first\\n\";\n+\t\texit;\n+\t}\n \n $updater->update();\n \n@@ -1215,12 +1209,7 @@ sub req_ci\n }\n }\n \n- close LOCKFILE;\n- my $reffile = \"$ENV{GIT_DIR}refs/heads/$state->{module}\";\n- unlink($reffile);\n- rename($lockfile, $reffile);\n chdir \"/\";\n-\n print \"ok\\n\";\n }\n \n-- \n1.5.0.2.778.gdcb06\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35604","messageId":"200702271249.09596.andyparkins@gmail.com","threadId":"6891","inReplyTo":"200702210908.59579.andyparkins@gmail.com","subject":"[PATCH 2/2] cvsserver: Remove trailing \"\\n\" from commithash in checkin function","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-27T12:49:09Z","receivedAt":"2007-02-27T12:49:09Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"The commithash for updating the ref is obtained from a call to\ngit-commit-tree. However, it was returned (and stored) with the\ntrailing newline. This meant that the later call to git-update-ref that\nwas trying to update to $commithash was including the newline in the\nparameter - obviously that hash would never exist, and so git-update-ref\nwould always fail.\n\nThe solution is to chomp() the commithash as soon as it is returned by\ngit-commit-tree.\n\nSigned-off-by: Andy Parkins \n---\n git-cvsserver.perl | 1 +\n 1 files changed, 1 insertions(+), 0 deletions(-)\n\ndiff --git a/git-cvsserver.perl b/git-cvsserver.perl\nindex 8e12f81..f4b8bd2 100755\n--- a/git-cvsserver.perl\n+++ b/git-cvsserver.perl\n@@ -1152,6 +1152,7 @@ sub req_ci\n close $msg_fh;\n \n my $commithash = `git-commit-tree $treehash -p $parenthash < $msg_filename`;\n+\tchomp($commithash);\n $log->info(\"Commit hash : $commithash\");\n \n unless ( $commithash =~ /[a-zA-Z0-9]{40}/ )\n-- \n1.5.0.2.778.gdcb06\n"},{"id":"35613","messageId":"es1d3n$kt6$1@sea.gmane.org","threadId":"6891","inReplyTo":"200702271248.59652.andyparkins@gmail.com","subject":"Re: [PATCH 1/2] Make 'cvs ci' lockless in git-cvsserver by using git-update-ref","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-27T13:55:09Z","receivedAt":"2007-02-27T13:55:09Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n> ---\n> This patch is actually yours (with one extra removal of lock file reference\n> that you'd missed, and a change of shortlog), but I don't know how to send\n> an email that comes from me but attributes authorship to you.\n\nYou just leave From: header in the body of message...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"35619","messageId":"alpine.LRH.0.82.0702270933060.29426@xanadu.home","threadId":"6891","inReplyTo":"200702271248.59652.andyparkins@gmail.com","subject":"Re: [PATCH 1/2] Make 'cvs ci' lockless in git-cvsserver by using git-update-ref","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-27T14:35:25Z","receivedAt":"2007-02-27T14:35:25Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 27 Feb 2007, Andy Parkins wrote:\n\n> This patch is actually yours (with one extra removal of lock file reference\n> that you'd missed, and a change of shortlog), but I don't know how to send\n> an email that comes from me but attributes authorship to you.\n\nStart your email body with a \"From: \" and the address of the person.\n\n\nNicolas\n"},{"id":"35661","messageId":"Pine.LNX.4.63.0702272107560.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6891","inReplyTo":"Pine.LNX.4.64.0702260112160.12555@beast.quantumfyre.co.uk","subject":"Re: Unresolved issues","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-27T20:10:01Z","receivedAt":"2007-02-27T20:10:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 26 Feb 2007, Julian Phillips wrote:\n\n> On Mon, 19 Feb 2007, Junio C Hamano wrote:\n> \n> > * \"git fetch\" between repositories with hundreds of refs.\n> \n> I would be happy to work on this if you would rather spend your time on \n> more generally useful things ...\n\nI would be grateful indeed if you worked on a builtin fetch. But beware, I \nthink it is quite some work...\n\nThe good thing: We have some tests involving git-fetch, so if all the \ntests pass, chances are that the builtin fetch works correctly.\n\n(Of course, we do not have tests for HTTP, SSH and GIT fetch... Anyone?)\n\nCiao,\nDscho\n"},{"id":"35727","messageId":"45E4C0BC.5090506@catalyst.net.nz","threadId":"6891","inReplyTo":"7vmz38t5r4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Use git-update-ref to update a ref during commit in git-cvsserver","fromName":"Martin Langhoff","fromEmail":"martin@catalyst.net.nz","sentAt":"2007-02-27T23:37:32Z","receivedAt":"2007-02-27T23:37:32Z","isPatch":true,"sender":{"key":"martin@laptop.org","avatar":null},"body":"Hi Junio, Andy,\n\nsorry for the long delay, I'm catching up with a sizable backlog at work\nand in my foss projects.\n\nI like Junio's patch -- it fixes cvsserver to work with packed refs\n(which needed to be done!) and does things lockless, which is a great bonus.\n\nThe meat of the matter is\n\nJunio C Hamano wrote:\n> - print LOCKFILE $commithash;\n> + if (system(qw(git update-ref -m), \"cvsserver ci\",\n> +\t \"refs/heads/$state->{module}\", $commithash, $parenthash)) {\n> +\t $log->warn(\"update-ref for $state->{module} failed.\");\n> +\t print \"error 1 Cannot commit -- update first\\n\";\n> +\t exit;\n> + }\n>\n> $updater->update();\n\nRunning the commit lockless makes it a little bit more likely that we'll\nfail the commit after all files have been sent. Some older CVS clients\nhave broken error handling in the late stages of the commit, but we\ncannot really fix that - and such cvs clients are so broken that they\nprobably don't deserve our attention.\n\nThe other area I checked is that we don't get a nasty race condition\nbetween the update-ref and calling $updater->update() - but it is safe.\n\nSo ack from this corner and thanks for the patch!\n\ncheers,\n\n\nmartin\n-- \n-----------------------------------------------------------------------\nMartin @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington\nWEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St\nOFFICE: +64(4)916-7224 UK: 0845 868 5733 ext 7224 MOB: +64(21)364-017\n Make things as simple as possible, but no simpler - Einstein\n-----------------------------------------------------------------------\n"},{"id":"35729","messageId":"7v1wkbb1yf.fsf@assigned-by-dhcp.cox.net","threadId":"6891","inReplyTo":"200702271248.59652.andyparkins@gmail.com","subject":"Re: [PATCH 1/2] Make 'cvs ci' lockless in git-cvsserver by using git-update-ref","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-27T23:44:24Z","receivedAt":"2007-02-27T23:44:24Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> This patch is actually yours (with one extra removal of lock file reference\n> that you'd missed, and a change of shortlog), but I don't know how to send\n> an email that comes from me but attributes authorship to you.\n\nThe extra one was introduced by a later patch to honor the\nupdate hook since I wrote the original patch you forward ported.\n\nThanks. Will apply.\n"},{"id":"35730","messageId":"7vwt239nbm.fsf@assigned-by-dhcp.cox.net","threadId":"6891","inReplyTo":"200702271249.09596.andyparkins@gmail.com","subject":"Re: [PATCH 2/2] cvsserver: Remove trailing \"\\n\" from commithash in checkin function","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-27T23:45:49Z","receivedAt":"2007-02-27T23:45:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> The commithash for updating the ref is obtained from a call to\n> git-commit-tree. However, it was returned (and stored) with the\n> trailing newline. This meant that the later call to git-update-ref that\n> was trying to update to $commithash was including the newline in the\n> parameter - obviously that hash would never exist, and so git-update-ref\n> would always fail.\n>\n> The solution is to chomp() the commithash as soon as it is returned by\n> git-commit-tree.\n>\n> Signed-off-by: Andy Parkins \n> my $commithash = `git-commit-tree $treehash -p $parenthash < $msg_filename`;\n> +\tchomp($commithash);\n> $log->info(\"Commit hash : $commithash\");\n> \n\nThanks. Do we need to compensate with a trailing LF in the $log\nline?\n"},{"id":"35785","messageId":"200702280844.45949.andyparkins@gmail.com","threadId":"6891","inReplyTo":"7v1wkbb1yf.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/2] Make 'cvs ci' lockless in git-cvsserver by using git-update-ref","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-28T08:44:44Z","receivedAt":"2007-02-28T08:44:44Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 February 27 23:44, Junio C Hamano wrote:\n\n> The extra one was introduced by a later patch to honor the\n> update hook since I wrote the original patch you forward ported.\n\nApologies. I must have applied your patch in the wrong place on my branch. \nIt did seem unlikely that you would have made a mistake.\n\n\nAndy\n\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35786","messageId":"200702280845.42910.andyparkins@gmail.com","threadId":"6891","inReplyTo":"7vwt239nbm.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 2/2] cvsserver: Remove trailing \"\\n\" from commithash in checkin function","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-02-28T08:45:41Z","receivedAt":"2007-02-28T08:45:41Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Tuesday 2007 February 27 23:45, Junio C Hamano wrote:\n\n> Thanks. Do we need to compensate with a trailing LF in the $log\n> line?\n\nInterestingly, no. I checked that, and the log has always had an unnecessary \nblank line in it - which is of course now removed.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"35860","messageId":"7v1wka2m3h.fsf@assigned-by-dhcp.cox.net","threadId":"6891","inReplyTo":"200702280844.45949.andyparkins@gmail.com","subject":"Re: [PATCH 1/2] Make 'cvs ci' lockless in git-cvsserver by using git-update-ref","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-28T18:06:26Z","receivedAt":"2007-02-28T18:06:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Tuesday 2007 February 27 23:44, Junio C Hamano wrote:\n>\n>> The extra one was introduced by a later patch to honor the\n>> update hook since I wrote the original patch you forward ported.\n>\n> Apologies. I must have applied your patch in the wrong place on my branch. \n> It did seem unlikely that you would have made a mistake.\n\nApologies if I sounded I was complaining -- not at all.\nI was _thanking_ you for the forward porting of my patch so I\ndid not have to do that ;-).\n"}]}