{"thread":{"id":"22633","subject":"[PATCH 1/2] hash-object: support --stdin-paths with --no-filters","startedAt":"2010-02-12T17:52:34Z","lastAt":"2010-02-14T13:42:35Z","messageCount":11,"participants":["Erik Faye-Lund","Dmitry Potapov","Eric Wong","Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"134367","messageId":"1265997155-3592-1-git-send-email-kusmabite@gmail.com","threadId":"22633","inReplyTo":null,"subject":"[PATCH 1/2] hash-object: support --stdin-paths with --no-filters","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-12T17:52:34Z","receivedAt":"2010-02-12T17:52:34Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"Signed-off-by: Erik Faye-Lund \n---\n builtin-hash-object.c | 8 ++++----\n t/t1007-hash-object.sh | 4 ----\n 2 files changed, 4 insertions(+), 8 deletions(-)\n\ndiff --git a/builtin-hash-object.c b/builtin-hash-object.c\nindex 6a5f5b5..080af1a 100644\n--- a/builtin-hash-object.c\n+++ b/builtin-hash-object.c\n@@ -33,6 +33,8 @@ static void hash_object(const char *path, const char *type, int write_object,\n \thash_fd(fd, type, write_object, vpath);\n }\n \n+static int no_filters;\n+\n static void hash_stdin_paths(const char *type, int write_objects)\n {\n \tstruct strbuf buf = STRBUF_INIT, nbuf = STRBUF_INIT;\n@@ -44,7 +46,8 @@ static void hash_stdin_paths(const char *type, int write_objects)\n \t\t\t\tdie(\"line is badly quoted\");\n \t\t\tstrbuf_swap(&buf, &nbuf);\n \t\t}\n-\t\thash_object(buf.buf, type, write_objects, buf.buf);\n+\t\thash_object(buf.buf, type, write_objects,\n+\t\t no_filters ? NULL : buf.buf);\n \t}\n \tstrbuf_release(&buf);\n \tstrbuf_release(&nbuf);\n@@ -60,7 +63,6 @@ static const char *type;\n static int write_object;\n static int hashstdin;\n static int stdin_paths;\n-static int no_filters;\n static const char *vpath;\n \n static const struct option hash_object_options[] = {\n@@ -100,8 +102,6 @@ int cmd_hash_object(int argc, const char **argv, const char *prefix)\n \t\t\terrstr = \"Can't specify files with --stdin-paths\";\n \t\telse if (vpath)\n \t\t\terrstr = \"Can't use --stdin-paths with --path\";\n-\t\telse if (no_filters)\n-\t\t\terrstr = \"Can't use --stdin-paths with --no-filters\";\n \t}\n \telse {\n \t\tif (hashstdin > 1)\ndiff --git a/t/t1007-hash-object.sh b/t/t1007-hash-object.sh\nindex fd98e44..1509fe3 100755\n--- a/t/t1007-hash-object.sh\n+++ b/t/t1007-hash-object.sh\n@@ -65,10 +65,6 @@ test_expect_success \"Can't use --path with --stdin-paths\" '\n \techo example | test_must_fail git hash-object --stdin-paths --path=foo\n '\n \n-test_expect_success \"Can't use --stdin-paths with --no-filters\" '\n-\techo example | test_must_fail git hash-object --stdin-paths --no-filters\n-'\n-\n test_expect_success \"Can't use --path with --no-filters\" '\n \ttest_must_fail git hash-object --no-filters --path=foo\n '\n-- \n1.7.0.rc2\n"},{"id":"134368","messageId":"1265997155-3592-2-git-send-email-kusmabite@gmail.com","threadId":"22633","inReplyTo":"1265997155-3592-1-git-send-email-kusmabite@gmail.com","subject":"[PATCH 2/2] git-svn: support fetch with autocrlf on","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-12T17:52:35Z","receivedAt":"2010-02-12T17:52:35Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"If I enable core.autocrlf and perform a \"git svn rebase\" that fetches\na change containing CRLFs, the git-svn meta-data gets corrupted.\n\nCommit d3c9634e worked around this by setting core.autocrlf to \"false\"\nin the per-repo config when initing the clone. However if the config\nvariable was changed, the breakage would still occur. This made it\npainful to work with git-svn on repos with mostly checked in LFs on\nWindows.\n\nThis patch tries to fix the same problem while allowing core.autocrlf\nto be enabled, by disabling filters when when hashing.\n\ngit-svn is currently the only call-site for hash_and_insert_object\n(apart from the test-suite), so changing it should be safe.\n\nSigned-off-by: Erik Faye-Lund \n---\n\nWith this patch applied, I guess we can also revert d3c9634e. I didn't\ndo this in this series, because I'm lazy and selfish and thus only\nchanged the code I needed to get what I wanted to work ;)\n\nI've been running git-svn with these patches with core.autocrlf enabled\nsince December, and never seen the breakage that I saw before d3c9634e.\n\n perl/Git.pm | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/perl/Git.pm b/perl/Git.pm\nindex e8df55d..2378da4 100644\n--- a/perl/Git.pm\n+++ b/perl/Git.pm\n@@ -842,7 +842,7 @@ sub _open_hash_and_insert_object_if_needed {\n \n \t($self->{hash_object_pid}, $self->{hash_object_in},\n \t $self->{hash_object_out}, $self->{hash_object_ctx}) =\n-\t\tcommand_bidi_pipe(qw(hash-object -w --stdin-paths));\n+\t\tcommand_bidi_pipe(qw(hash-object -w --stdin-paths --no-filters));\n }\n \n sub _close_hash_and_insert_object {\n-- \n1.7.0.rc2\n"},{"id":"134371","messageId":"37fcd2781002121037n4c98890eq5d635fc3bad5928a@mail.gmail.com","threadId":"22633","inReplyTo":"1265997155-3592-1-git-send-email-kusmabite@gmail.com","subject":"Re: [PATCH 1/2] hash-object: support --stdin-paths with --no-filters","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-02-12T18:37:08Z","receivedAt":"2010-02-12T18:37:08Z","isPatch":true,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"Hi Erik,\n\nI don't remember why I made --no-filters incompatible with --stdin-paths\nwhen I added it. So your patch makes perfect sense to me. However, I\nthink you should correct synopsis in Documentation/git-hash-object.txt,\nso it will be clear that these two options can be used together now.\nAlso, it would be nice if you add a test case to make sure that it works\nas expected and will not broken in the future..\n\n\nThanks,\nDmitry\n"},{"id":"134426","messageId":"20100213122532.GA31653@dcvr.yhbt.net","threadId":"22633","inReplyTo":"1265997155-3592-2-git-send-email-kusmabite@gmail.com","subject":"Re: [PATCH 2/2] git-svn: support fetch with autocrlf on","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2010-02-13T12:25:32Z","receivedAt":"2010-02-13T12:25:32Z","isPatch":true,"sender":{"key":"e@80x24.org","avatar":null},"body":"Erik Faye-Lund wrote:\n> If I enable core.autocrlf and perform a \"git svn rebase\" that fetches\n> a change containing CRLFs, the git-svn meta-data gets corrupted.\n> \n> Commit d3c9634e worked around this by setting core.autocrlf to \"false\"\n> in the per-repo config when initing the clone. However if the config\n> variable was changed, the breakage would still occur. This made it\n> painful to work with git-svn on repos with mostly checked in LFs on\n> Windows.\n> \n> This patch tries to fix the same problem while allowing core.autocrlf\n> to be enabled, by disabling filters when when hashing.\n> \n> git-svn is currently the only call-site for hash_and_insert_object\n> (apart from the test-suite), so changing it should be safe.\n> \n> Signed-off-by: Erik Faye-Lund \n> ---\n> \n> With this patch applied, I guess we can also revert d3c9634e. I didn't\n> do this in this series, because I'm lazy and selfish and thus only\n> changed the code I needed to get what I wanted to work ;)\n> \n> I've been running git-svn with these patches with core.autocrlf enabled\n> since December, and never seen the breakage that I saw before d3c9634e.\n\nHi Erik,\n\nHow does reverting d3c9634e affect dcommit? I've never dealt with (or\neven looked at) autocrlf, so I'll put my trust in you and Dscho with\nanything related to it.\n\n-- \nEric Wong\n"},{"id":"134429","messageId":"40aa078e1002130616u478397c0xf757d5424630e6cf@mail.gmail.com","threadId":"22633","inReplyTo":"20100213122532.GA31653@dcvr.yhbt.net","subject":"Re: [PATCH 2/2] git-svn: support fetch with autocrlf on","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-13T14:16:52Z","receivedAt":"2010-02-13T14:16:52Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Sat, Feb 13, 2010 at 1:25 PM, Eric Wong wrote:\n> Erik Faye-Lund wrote:\n>> If I enable core.autocrlf and perform a \"git svn rebase\" that fetches\n>> a change containing CRLFs, the git-svn meta-data gets corrupted.\n>>\n>> Commit d3c9634e worked around this by setting core.autocrlf to \"false\"\n>> in the per-repo config when initing the clone. However if the config\n>> variable was changed, the breakage would still occur. This made it\n>> painful to work with git-svn on repos with mostly checked in LFs on\n>> Windows.\n>>\n>> This patch tries to fix the same problem while allowing core.autocrlf\n>> to be enabled, by disabling filters when when hashing.\n>>\n>> git-svn is currently the only call-site for hash_and_insert_object\n>> (apart from the test-suite), so changing it should be safe.\n>>\n>> Signed-off-by: Erik Faye-Lund \n>> ---\n>>\n>> With this patch applied, I guess we can also revert d3c9634e. I didn't\n>> do this in this series, because I'm lazy and selfish and thus only\n>> changed the code I needed to get what I wanted to work ;)\n>>\n>> I've been running git-svn with these patches with core.autocrlf enabled\n>> since December, and never seen the breakage that I saw before d3c9634e.\n>\n> Hi Erik,\n>\n> How does reverting d3c9634e affect dcommit?  I've never dealt with (or\n> even looked at) autocrlf, so I'll put my trust in you and Dscho with\n> anything related to it.\n>\n\nI don't think it affects svn dcommit in any way, except from the\nimplicit svn rebase that svn dcommit performs. d3c9634e sets\ncore.autocrlf to \"false\" on init, but re-enabling it hasn't shown any\nproblems in my end. I'm using git-svn with these patches and\ncore.autocrlf enabled every day at my day-job.\n\nI'd say that reverting d3c9634e would be the Right Thing To Do(tm),\nbecause it makes git svn clone work just as bad as git clone, when\ncloning a repo with CRLFs in it ;)\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"134501","messageId":"alpine.DEB.1.00.1002140054300.20986@pacific.mpi-cbg.de","threadId":"22633","inReplyTo":"20100213122532.GA31653@dcvr.yhbt.net","subject":"Re: [PATCH 2/2] git-svn: support fetch with autocrlf on","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-02-13T23:55:28Z","receivedAt":"2010-02-13T23:55:28Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 13 Feb 2010, Eric Wong wrote:\n\n> Erik Faye-Lund wrote:\n> > If I enable core.autocrlf and perform a \"git svn rebase\" that fetches\n> > a change containing CRLFs, the git-svn meta-data gets corrupted.\n> > \n> > Commit d3c9634e worked around this by setting core.autocrlf to \"false\" \n> > in the per-repo config when initing the clone. However if the config \n> > variable was changed, the breakage would still occur. This made it \n> > painful to work with git-svn on repos with mostly checked in LFs on \n> > Windows.\n> > \n> > This patch tries to fix the same problem while allowing core.autocrlf \n> > to be enabled, by disabling filters when when hashing.\n> > \n> > git-svn is currently the only call-site for hash_and_insert_object \n> > (apart from the test-suite), so changing it should be safe.\n> > \n> > Signed-off-by: Erik Faye-Lund \n> > ---\n> > \n> > With this patch applied, I guess we can also revert d3c9634e. I didn't\n> > do this in this series, because I'm lazy and selfish and thus only\n> > changed the code I needed to get what I wanted to work ;)\n> > \n> > I've been running git-svn with these patches with core.autocrlf enabled\n> > since December, and never seen the breakage that I saw before d3c9634e.\n> \n> Hi Erik,\n> \n> How does reverting d3c9634e affect dcommit? I've never dealt with (or\n> even looked at) autocrlf, so I'll put my trust in you and Dscho with\n> anything related to it.\n\nI have no idea how reverting said commit affects dcommit, and I do not \nhave the time to check, sorry!\n\nCiao,\nDscho\n"},{"id":"134504","messageId":"alpine.DEB.1.00.1002140055550.20986@pacific.mpi-cbg.de","threadId":"22633","inReplyTo":"40aa078e1002130616u478397c0xf757d5424630e6cf@mail.gmail.com","subject":"Re: [PATCH 2/2] git-svn: support fetch with autocrlf on","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-02-13T23:59:00Z","receivedAt":"2010-02-13T23:59:00Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 13 Feb 2010, Erik Faye-Lund wrote:\n\n> I don't think it affects svn dcommit in any way, except from the \n> implicit svn rebase that svn dcommit performs. d3c9634e sets \n> core.autocrlf to \"false\" on init, but re-enabling it hasn't shown any \n> problems in my end. I'm using git-svn with these patches and \n> core.autocrlf enabled every day at my day-job.\n\nTo elicit a warm and fuzzy feeling about your patch, you will have to \nanalyze the code paaths of dcommit, and how crlf affects them. Then you \nwill have to describe why dcommit does not have a problem with crlf with \nyour patches anymore.\n\nRemember, the idea of a commit message is to optimize the overall time \nbalance, i.e. avoid the many to perform what the one can do for them. And \nsince you have to do that analysis for yourself anyway, it makes sense to \nwrite up the result in the commit message.\n\nThanks,\nDscho\n"},{"id":"134505","messageId":"40aa078e1002131627x10fb9dfaq479b731f16d816aa@mail.gmail.com","threadId":"22633","inReplyTo":"alpine.DEB.1.00.1002140055550.20986@pacific.mpi-cbg.de","subject":"Re: [PATCH 2/2] git-svn: support fetch with autocrlf on","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-14T00:27:53Z","receivedAt":"2010-02-14T00:27:53Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Sun, Feb 14, 2010 at 12:59 AM, Johannes Schindelin\n wrote:\n> Hi,\n>\n> On Sat, 13 Feb 2010, Erik Faye-Lund wrote:\n>\n>> I don't think it affects svn dcommit in any way, except from the\n>> implicit svn rebase that svn dcommit performs. d3c9634e sets\n>> core.autocrlf to \"false\" on init, but re-enabling it hasn't shown any\n>> problems in my end. I'm using git-svn with these patches and\n>> core.autocrlf enabled every day at my day-job.\n>\n> To elicit a warm and fuzzy feeling about your patch, you will have to\n> analyze the code paaths of dcommit, and how crlf affects them. Then you\n> will have to describe why dcommit does not have a problem with crlf with\n> your patches anymore.\n>\n> Remember, the idea of a commit message is to optimize the overall time\n> balance, i.e. avoid the many to perform what the one can do for them. And\n> since you have to do that analysis for yourself anyway, it makes sense to\n> write up the result in the commit message.\n>\n\nI'm sorry, but I'm confused. What missed from my commit message?\n\nThe question of dcommit was a question that Eric asked, and I'm not\nreally sure why he did. I tried to explain why in my reply. d3c9634e\nnever was about dcommit the way I understand it, but about clone:\nhttp://code.google.com/p/msysgit/issues/detail?id=232\n\nIf there's something that isn't sufficiently explained in the commit\nmessage, I'd like to know so I can improve it for the next round...\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"134506","messageId":"alpine.DEB.1.00.1002140140510.20986@pacific.mpi-cbg.de","threadId":"22633","inReplyTo":"40aa078e1002131627x10fb9dfaq479b731f16d816aa@mail.gmail.com","subject":"Re: [PATCH 2/2] git-svn: support fetch with autocrlf on","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2010-02-14T00:46:31Z","receivedAt":"2010-02-14T00:46:31Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 14 Feb 2010, Erik Faye-Lund wrote:\n\n> On Sun, Feb 14, 2010 at 12:59 AM, Johannes Schindelin\n> wrote:\n>\n> > On Sat, 13 Feb 2010, Erik Faye-Lund wrote:\n> >\n> >> I don't think it affects svn dcommit in any way, except from the \n> >> implicit svn rebase that svn dcommit performs. d3c9634e sets \n> >> core.autocrlf to \"false\" on init, but re-enabling it hasn't shown any \n> >> problems in my end. I'm using git-svn with these patches and \n> >> core.autocrlf enabled every day at my day-job.\n> >\n> > To elicit a warm and fuzzy feeling about your patch, you will have to \n> > analyze the code paaths of dcommit, and how crlf affects them. Then \n> > you will have to describe why dcommit does not have a problem with \n> > crlf with your patches anymore.\n> >\n> > Remember, the idea of a commit message is to optimize the overall time \n> > balance, i.e. avoid the many to perform what the one can do for them. \n> > And since you have to do that analysis for yourself anyway, it makes \n> > sense to write up the result in the commit message.\n> >\n> \n> I'm sorry, but I'm confused. What missed from my commit message?\n\nI had the impression that you sent a mail asking to revert the commit that \nhardcoded autocrlf to false for git svn. For that commit, you would have \nto provide the information I requested.\n\n> The question of dcommit was a question that Eric asked, and I'm not \n> really sure why he did. I tried to explain why in my reply. d3c9634e \n> never was about dcommit the way I understand it, but about clone: \n> http://code.google.com/p/msysgit/issues/detail?id=232\n\nWell, technically, you are right, it is only about clone.\n\nBut.\n\nIf you set autocrlf to false in every git svn clone, then of course, \ndcommit is very much affected by the setting. Along with all other git svn \noperations.\n\nAnd since your patches aimed at undoing that patch, i.e. no longer setting \nautocrlf to false upon git svn clone, you have to show that git svn in \ngeneral can handle autocrlf = true (or = input) just fine.\n\nAnd by \"to show\" I do not mean just test it. That is not good enough, \nbecause your workflow is more than just likely to miss out on ways other \npeople use git svn. You have the source code, and you can look all git \ncalls and analyze them for potential autocrlf problems.\n\nCiao,\nDscho\n"},{"id":"134507","messageId":"40aa078e1002131704g90463bbq864138fee8d4ce01@mail.gmail.com","threadId":"22633","inReplyTo":"alpine.DEB.1.00.1002140140510.20986@pacific.mpi-cbg.de","subject":"Re: [PATCH 2/2] git-svn: support fetch with autocrlf on","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-14T01:04:30Z","receivedAt":"2010-02-14T01:04:30Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Sun, Feb 14, 2010 at 1:46 AM, Johannes Schindelin\n wrote:\n> Hi,\n>\n> On Sun, 14 Feb 2010, Erik Faye-Lund wrote:\n>\n>> On Sun, Feb 14, 2010 at 12:59 AM, Johannes Schindelin\n>> wrote:\n>>\n>> > On Sat, 13 Feb 2010, Erik Faye-Lund wrote:\n>> >\n>> >> I don't think it affects svn dcommit in any way, except from the\n>> >> implicit svn rebase that svn dcommit performs. d3c9634e sets\n>> >> core.autocrlf to \"false\" on init, but re-enabling it hasn't shown any\n>> >> problems in my end. I'm using git-svn with these patches and\n>> >> core.autocrlf enabled every day at my day-job.\n>> >\n>> > To elicit a warm and fuzzy feeling about your patch, you will have to\n>> > analyze the code paaths of dcommit, and how crlf affects them. Then\n>> > you will have to describe why dcommit does not have a problem with\n>> > crlf with your patches anymore.\n>> >\n>> > Remember, the idea of a commit message is to optimize the overall time\n>> > balance, i.e. avoid the many to perform what the one can do for them.\n>> > And since you have to do that analysis for yourself anyway, it makes\n>> > sense to write up the result in the commit message.\n>> >\n>>\n>> I'm sorry, but I'm confused. What missed from my commit message?\n>\n> I had the impression that you sent a mail asking to revert the commit that\n> hardcoded autocrlf to false for git svn. For that commit, you would have\n> to provide the information I requested.\n>\n\nNo. I sent a patch series that fixes this issue properly instead of\njust disabling core.autocrlf. I added a comment that mentioned that\nthe hack possibly could be reverted. I didn't ask anyone to revert it.\n\n>> The question of dcommit was a question that Eric asked, and I'm not\n>> really sure why he did. I tried to explain why in my reply. d3c9634e\n>> never was about dcommit the way I understand it, but about clone:\n>> http://code.google.com/p/msysgit/issues/detail?id=232\n>\n> Well, technically, you are right, it is only about clone.\n>\n> But.\n>\n> If you set autocrlf to false in every git svn clone, then of course,\n> dcommit is very much affected by the setting. Along with all other git svn\n> operations.\n>\n\nWouldn't any such changes be bugs that d3c9634e introduced?\n\n> And since your patches aimed at undoing that patch, i.e. no longer setting\n> autocrlf to false upon git svn clone, you have to show that git svn in\n> general can handle autocrlf = true (or = input) just fine.\n>\n\nMy patch aimed at allowing me to use core.autocrlf. I don't care what\nthe default for core.autocrlf in a git-svn clone is, I'm just sick of\naccidentally checking in CRLFs into my company's SVN repo because\nenabling core.autocrlf corrupts my local repo.\n\n> And by \"to show\" I do not mean just test it. That is not good enough,\n> because your workflow is more than just likely to miss out on ways other\n> people use git svn. You have the source code, and you can look all git\n> calls and analyze them for potential autocrlf problems.\n>\n\nWhat makes you think that I haven't properly analyzed the issue? I'm\nwondering especially about this, considering that you yourself\ndescribed your fix as \"so obvious it did not even need testing\"...\nWhat's the required amount of analysis here?\n\nI'm sorry if I misunderstand you here, but I'm still not understanding\nwhat's lacking...\n\nI guess \"This patch tries to fix the same problem while allowing\ncore.autocrlf to be enabled, by disabling filters when when hashing\"\ncould be rewritten into something like this:\n\n\"This patch tries to fix the same problem while allowing core.autocrlf\nto be enabled, by making sure that filters aren't applied while\nimporting files into the git-repo\"\n\nPerhaps I should add a paragraph explaining why the issue triggered in\nthe first place (before d3c9634e)?\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"134540","messageId":"40aa078e1002140542v6372b7daj712119830d119dcb@mail.gmail.com","threadId":"22633","inReplyTo":"37fcd2781002121037n4c98890eq5d635fc3bad5928a@mail.gmail.com","subject":"Re: [PATCH 1/2] hash-object: support --stdin-paths with --no-filters","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-02-14T13:42:35Z","receivedAt":"2010-02-14T13:42:35Z","isPatch":true,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Feb 12, 2010 at 7:37 PM, Dmitry Potapov wrote:\n> Hi Erik,\n>\n> I don't remember why I made --no-filters incompatible with --stdin-paths\n> when I added it. So your patch makes perfect sense to me. However, I\n> think you should correct synopsis in Documentation/git-hash-object.txt,\n> so it will be clear that these two options can be used together now.\n> Also, it would be nice if you add a test case to make sure that it works\n> as expected and will not broken in the future..\n>\n\nThanks. I've fixed the synopsis and added a test for the next round.\n\n-- \nErik \"kusma\" Faye-Lund\n"}]}