{"thread":{"id":"27859","subject":"[PATCH] gitignore: add top level patch ignore rule","startedAt":"2011-07-19T22:17:57Z","lastAt":"2011-07-22T13:20:27Z","messageCount":8,"participants":["Vitaliy Ivanov","Michael J Gruber","Marc Branchaud"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"171711","messageId":"1311113877.2643.2.camel@vitaliy-Vostro-1400","threadId":"27859","inReplyTo":null,"subject":"[PATCH] gitignore: add top level patch ignore rule","fromName":"Vitaliy Ivanov","fromEmail":"vitalivanov@gmail.com","sentAt":"2011-07-19T22:17:57Z","receivedAt":"2011-07-19T22:17:57Z","isPatch":true,"sender":{"key":"vitalivanov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2084293?v=4"},"body":"Add top level ignore rule for patches created by format-patch command.\nOn the way, reorganize ignore rules and add comments.\n\nSigned-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>\n---\n .gitignore |   43 ++++++++++++++++++++++++++++++-------------\n 1 files changed, 30 insertions(+), 13 deletions(-)\n\ndiff --git a/.gitignore b/.gitignore\nindex 8572c8c..47afe77 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -1,3 +1,15 @@\n+#\n+# NOTE! Don't add files that are generated in specific\n+# subdirectories here. Add them in the \".gitignore\" file\n+# in that subdirectory instead.\n+#\n+# NOTE! Please use 'git ls-files -i --exclude-standard'\n+# command after changing this file, to see if there are\n+# any tracked files which get ignored after the change.\n+\n+#\n+# Top-level files\n+#\n /GIT-BUILD-OPTIONS\n /GIT-CFLAGS\n /GIT-LDFLAGS\n@@ -187,21 +199,10 @@\n /test-svn-fe\n /test-treap\n /common-cmds.h\n-*.tar.gz\n-*.dsc\n-*.deb\n /git.spec\n-*.exe\n-*.[aos]\n-*.py[co]\n-.depend/\n-*.gcda\n-*.gcno\n-*.gcov\n /coverage-untested-functions\n /cover_db/\n /cover_db_html/\n-*+\n /config.mak\n /autom4te.cache\n /config.cache\n@@ -213,6 +214,24 @@\n /tags\n /TAGS\n /cscope*\n+/Debug/\n+/Release/\n+/*.patch\n+\n+#\n+# Normal rules\n+#\n+*.tar.gz\n+*.dsc\n+*.deb\n+*.exe\n+*.[aos]\n+*.py[co]\n+.depend/\n+*.gcda\n+*.gcno\n+*.gcov\n+*+\n *.obj\n *.lib\n *.sln\n@@ -222,5 +241,3 @@\n *.user\n *.idb\n *.pdb\n-/Debug/\n-/Release/\n-- \n1.7.4.1\n"},{"id":"171725","messageId":"4E268D2F.50201@drmicha.warpmail.net","threadId":"27859","inReplyTo":"1311113877.2643.2.camel@vitaliy-Vostro-1400","subject":"Re: [PATCH] gitignore: add top level patch ignore rule","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-07-20T08:09:19Z","receivedAt":"2011-07-20T08:09:19Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Vitaliy Ivanov venit, vidit, dixit 20.07.2011 00:17:\n> Add top level ignore rule for patches created by format-patch command.\n\nPlease don't.\n\nThe tracked ignore file is for ignoring products and artefacts of our\nbuild process. format-patch is not part of this process, and the\nexistence of *.patch files depends on your workflow. But what is much\nworse: In\n\ngit status\ngit format-patch rev-spec\ngit send-email *.patch\n\nit is very easy to send out the wrong patches (along with the right\nones), because your patch hides them from status. Also, I can't clean\nthem up with \"git clean -f\" any more. I would have to use \"git clean -f\n-x\" which would clean the build products also (and force a rebuild).\n\nSo, your patch makes a format-patch based workflow much worse. What\nproblem does it try to solve?\n\n> On the way, reorganize ignore rules and add comments.\n\nHow and why do you reorganize?\n\n> \n> Signed-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>\n> ---\n>  .gitignore |   43 ++++++++++++++++++++++++++++++-------------\n>  1 files changed, 30 insertions(+), 13 deletions(-)\n> \n> diff --git a/.gitignore b/.gitignore\n> index 8572c8c..47afe77 100644\n> --- a/.gitignore\n> +++ b/.gitignore\n> @@ -1,3 +1,15 @@\n> +#\n> +# NOTE! Don't add files that are generated in specific\n> +# subdirectories here. Add them in the \".gitignore\" file\n> +# in that subdirectory instead.\n> +#\n> +# NOTE! Please use 'git ls-files -i --exclude-standard'\n> +# command after changing this file, to see if there are\n> +# any tracked files which get ignored after the change.\n> +\n> +#\n> +# Top-level files\n> +#\n>  /GIT-BUILD-OPTIONS\n>  /GIT-CFLAGS\n>  /GIT-LDFLAGS\n> @@ -187,21 +199,10 @@\n>  /test-svn-fe\n>  /test-treap\n>  /common-cmds.h\n> -*.tar.gz\n> -*.dsc\n> -*.deb\n>  /git.spec\n> -*.exe\n> -*.[aos]\n> -*.py[co]\n> -.depend/\n> -*.gcda\n> -*.gcno\n> -*.gcov\n>  /coverage-untested-functions\n>  /cover_db/\n>  /cover_db_html/\n> -*+\n>  /config.mak\n>  /autom4te.cache\n>  /config.cache\n> @@ -213,6 +214,24 @@\n>  /tags\n>  /TAGS\n>  /cscope*\n> +/Debug/\n> +/Release/\n> +/*.patch\n> +\n> +#\n> +# Normal rules\n> +#\n> +*.tar.gz\n> +*.dsc\n> +*.deb\n> +*.exe\n> +*.[aos]\n> +*.py[co]\n> +.depend/\n> +*.gcda\n> +*.gcno\n> +*.gcov\n> +*+\n>  *.obj\n>  *.lib\n>  *.sln\n> @@ -222,5 +241,3 @@\n>  *.user\n>  *.idb\n>  *.pdb\n> -/Debug/\n> -/Release/\n"},{"id":"171788","messageId":"CAGTPOqeF6LneWCg_du5dDfzFp7QV_jGg1t4u23sziTN+uHQyXA@mail.gmail.com","threadId":"27859","inReplyTo":"4E268D2F.50201@drmicha.warpmail.net","subject":"Re: [PATCH] gitignore: add top level patch ignore rule","fromName":"Vitaliy Ivanov","fromEmail":"vitalivanov@gmail.com","sentAt":"2011-07-21T12:54:49Z","receivedAt":"2011-07-21T12:54:49Z","isPatch":true,"sender":{"key":"vitalivanov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2084293?v=4"},"body":"Michael,\n\nOn Wed, Jul 20, 2011 at 11:09 AM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Vitaliy Ivanov venit, vidit, dixit 20.07.2011 00:17:\n>> Add top level ignore rule for patches created by format-patch command.\n>\n> Please don't.\n>\n> The tracked ignore file is for ignoring products and artefacts of our\n> build process. format-patch is not part of this process, and the\n> existence of *.patch files depends on your workflow. But what is much\n> worse: In\n>\n> git status\n> git format-patch rev-spec\n> git send-email *.patch\n>\n> it is very easy to send out the wrong patches (along with the right\n> ones), because your patch hides them from status. Also, I can't clean\n> them up with \"git clean -f\" any more. I would have to use \"git clean -f\n> -x\" which would clean the build products also (and force a rebuild).\n>\n> So, your patch makes a format-patch based workflow much worse. What\n> problem does it try to solve?\n\nI will not insist. You may know it better but git as is a public\nproject where anyone can create and send patches. So it seems to me\nbasic workflow for sharing changes.\n\n>\n>> On the way, reorganize ignore rules and add comments.\n>\n> How and why do you reorganize?\n\nJust to be able to find specific rule faster. Global rules are now all\ntogether same is for top level root rules.\n\n>\n>>\n>> Signed-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>\n>> ---\n>>  .gitignore |   43 ++++++++++++++++++++++++++++++-------------\n>>  1 files changed, 30 insertions(+), 13 deletions(-)\n>>\n>> diff --git a/.gitignore b/.gitignore\n>> index 8572c8c..47afe77 100644\n>> --- a/.gitignore\n>> +++ b/.gitignore\n>> @@ -1,3 +1,15 @@\n>> +#\n>> +# NOTE! Don't add files that are generated in specific\n>> +# subdirectories here. Add them in the \".gitignore\" file\n>> +# in that subdirectory instead.\n>> +#\n>> +# NOTE! Please use 'git ls-files -i --exclude-standard'\n>> +# command after changing this file, to see if there are\n>> +# any tracked files which get ignored after the change.\n>> +\n>> +#\n>> +# Top-level files\n>> +#\n>>  /GIT-BUILD-OPTIONS\n>>  /GIT-CFLAGS\n>>  /GIT-LDFLAGS\n>> @@ -187,21 +199,10 @@\n>>  /test-svn-fe\n>>  /test-treap\n>>  /common-cmds.h\n>> -*.tar.gz\n>> -*.dsc\n>> -*.deb\n>>  /git.spec\n>> -*.exe\n>> -*.[aos]\n>> -*.py[co]\n>> -.depend/\n>> -*.gcda\n>> -*.gcno\n>> -*.gcov\n>>  /coverage-untested-functions\n>>  /cover_db/\n>>  /cover_db_html/\n>> -*+\n>>  /config.mak\n>>  /autom4te.cache\n>>  /config.cache\n>> @@ -213,6 +214,24 @@\n>>  /tags\n>>  /TAGS\n>>  /cscope*\n>> +/Debug/\n>> +/Release/\n>> +/*.patch\n>> +\n>> +#\n>> +# Normal rules\n>> +#\n>> +*.tar.gz\n>> +*.dsc\n>> +*.deb\n>> +*.exe\n>> +*.[aos]\n>> +*.py[co]\n>> +.depend/\n>> +*.gcda\n>> +*.gcno\n>> +*.gcov\n>> +*+\n>>  *.obj\n>>  *.lib\n>>  *.sln\n>> @@ -222,5 +241,3 @@\n>>  *.user\n>>  *.idb\n>>  *.pdb\n>> -/Debug/\n>> -/Release/\n>\n>\n"},{"id":"171778","messageId":"4E282349.4040404@drmicha.warpmail.net","threadId":"27859","inReplyTo":"CAGTPOqeF6LneWCg_du5dDfzFp7QV_jGg1t4u23sziTN+uHQyXA@mail.gmail.com","subject":"Re: [PATCH] gitignore: add top level patch ignore rule","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-07-21T13:02:01Z","receivedAt":"2011-07-21T13:02:01Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Vitaliy Ivanov venit, vidit, dixit 21.07.2011 14:54:\n> Michael,\n> \n> On Wed, Jul 20, 2011 at 11:09 AM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>> Vitaliy Ivanov venit, vidit, dixit 20.07.2011 00:17:\n>>> Add top level ignore rule for patches created by format-patch command.\n>>\n>> Please don't.\n>>\n>> The tracked ignore file is for ignoring products and artefacts of our\n>> build process. format-patch is not part of this process, and the\n>> existence of *.patch files depends on your workflow. But what is much\n>> worse: In\n>>\n>> git status\n>> git format-patch rev-spec\n>> git send-email *.patch\n>>\n>> it is very easy to send out the wrong patches (along with the right\n>> ones), because your patch hides them from status. Also, I can't clean\n>> them up with \"git clean -f\" any more. I would have to use \"git clean -f\n>> -x\" which would clean the build products also (and force a rebuild).\n>>\n>> So, your patch makes a format-patch based workflow much worse. What\n>> problem does it try to solve?\n> \n> I will not insist. You may know it better but git as is a public\n> project where anyone can create and send patches. So it seems to me\n> basic workflow for sharing changes.\n\nWell sure it is. We do that and discuss the merits of patches.\n\nI do use format-patch/send-email, and as I explained, your patch would\nmake that more difficult. If there is something that it makes better\nthat may outweigh it. Can you explain what improvement this (ignoring\n*.patch) introduces?\n\n>>\n>>> On the way, reorganize ignore rules and add comments.\n>>\n>> How and why do you reorganize?\n> \n> Just to be able to find specific rule faster. Global rules are now all\n> together same is for top level root rules.\n\nThat may be a sensible cleanup, and it's good to describe that in the\ncommit message. Also, in general, we try to separate reorganisation\npatches from those which introduce functional changes. (One may argue\nwhether adding *.patch falls into the latter category, though.)\n\n[patch snipped]\n\nMichael\n"},{"id":"171801","messageId":"CAGTPOqcd5G=NG83wgnH80nqNsS1FYwtRp4QjaB=oU5NkPts_Hg@mail.gmail.com","threadId":"27859","inReplyTo":"4E282349.4040404@drmicha.warpmail.net","subject":"Re: [PATCH] gitignore: add top level patch ignore rule","fromName":"Vitaliy Ivanov","fromEmail":"vitalivanov@gmail.com","sentAt":"2011-07-21T13:22:51Z","receivedAt":"2011-07-21T13:22:51Z","isPatch":true,"sender":{"key":"vitalivanov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2084293?v=4"},"body":"On Thu, Jul 21, 2011 at 4:02 PM, Michael J Gruber\n<git@drmicha.warpmail.net> wrote:\n> Vitaliy Ivanov venit, vidit, dixit 21.07.2011 14:54:\n>> Michael,\n>>\n>> On Wed, Jul 20, 2011 at 11:09 AM, Michael J Gruber\n>> <git@drmicha.warpmail.net> wrote:\n>>> Vitaliy Ivanov venit, vidit, dixit 20.07.2011 00:17:\n>>>> Add top level ignore rule for patches created by format-patch command.\n>>>\n>>> Please don't.\n>>>\n>>> The tracked ignore file is for ignoring products and artefacts of our\n>>> build process. format-patch is not part of this process, and the\n>>> existence of *.patch files depends on your workflow. But what is much\n>>> worse: In\n>>>\n>>> git status\n>>> git format-patch rev-spec\n>>> git send-email *.patch\n>>>\n>>> it is very easy to send out the wrong patches (along with the right\n>>> ones), because your patch hides them from status. Also, I can't clean\n>>> them up with \"git clean -f\" any more. I would have to use \"git clean -f\n>>> -x\" which would clean the build products also (and force a rebuild).\n>>>\n>>> So, your patch makes a format-patch based workflow much worse. What\n>>> problem does it try to solve?\n>>\n>> I will not insist. You may know it better but git as is a public\n>> project where anyone can create and send patches. So it seems to me\n>> basic workflow for sharing changes.\n>\n> Well sure it is. We do that and discuss the merits of patches.\n>\n> I do use format-patch/send-email, and as I explained, your patch would\n> make that more difficult. If there is something that it makes better\n> that may outweigh it. Can you explain what improvement this (ignoring\n> *.patch) introduces?\n\nI'm not sure how listing all the patches that you have under \"git\nstatus\" will help you not to send a wrong one.\nAlso we are talking about /*.patch rule and not *.patch as with such rule:\n\n[vitaliy.ivanov@vivanov git]$ git ls-files -i --exclude-standard\ncontrib/patches/docbook-xsl-manpages-charmap.patch\nt/t4100/t-apply-1.patch\nt/t4100/t-apply-2.patch\nt/t4100/t-apply-3.patch\nt/t4100/t-apply-4.patch\nt/t4100/t-apply-5.patch\nt/t4100/t-apply-6.patch\nt/t4100/t-apply-7.patch\nt/t4100/t-apply-8.patch\nt/t4100/t-apply-9.patch\nt/t4109/patch1.patch\nt/t4109/patch2.patch\nt/t4109/patch3.patch\nt/t4109/patch4.patch\nt/t4110/patch1.patch\nt/t4110/patch2.patch\nt/t4110/patch3.patch\nt/t4110/patch4.patch\nt/t4110/patch5.patch\n\n>>>> On the way, reorganize ignore rules and add comments.\n>>>\n>>> How and why do you reorganize?\n>>\n>> Just to be able to find specific rule faster. Global rules are now all\n>> together same is for top level root rules.\n>\n> That may be a sensible cleanup, and it's good to describe that in the\n> commit message. Also, in general, we try to separate reorganisation\n> patches from those which introduce functional changes. (One may argue\n> whether adding *.patch falls into the latter category, though.)\n\nYeah, I should agree here. I can resend it w/o adding new rules but\nsimple reorganization and, of course, description for this change.\n\nVitaliy\n"},{"id":"171792","messageId":"4E2829D6.9010409@drmicha.warpmail.net","threadId":"27859","inReplyTo":"CAGTPOqcd5G=NG83wgnH80nqNsS1FYwtRp4QjaB=oU5NkPts_Hg@mail.gmail.com","subject":"Re: [PATCH] gitignore: add top level patch ignore rule","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-07-21T13:29:58Z","receivedAt":"2011-07-21T13:29:58Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Vitaliy Ivanov venit, vidit, dixit 21.07.2011 15:22:\n> On Thu, Jul 21, 2011 at 4:02 PM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>> Vitaliy Ivanov venit, vidit, dixit 21.07.2011 14:54:\n>>> Michael,\n>>>\n>>> On Wed, Jul 20, 2011 at 11:09 AM, Michael J Gruber\n>>> <git@drmicha.warpmail.net> wrote:\n>>>> Vitaliy Ivanov venit, vidit, dixit 20.07.2011 00:17:\n>>>>> Add top level ignore rule for patches created by format-patch command.\n>>>>\n>>>> Please don't.\n>>>>\n>>>> The tracked ignore file is for ignoring products and artefacts of our\n>>>> build process. format-patch is not part of this process, and the\n>>>> existence of *.patch files depends on your workflow. But what is much\n>>>> worse: In\n>>>>\n>>>> git status\n>>>> git format-patch rev-spec\n>>>> git send-email *.patch\n>>>>\n>>>> it is very easy to send out the wrong patches (along with the right\n>>>> ones), because your patch hides them from status. Also, I can't clean\n>>>> them up with \"git clean -f\" any more. I would have to use \"git clean -f\n>>>> -x\" which would clean the build products also (and force a rebuild).\n>>>>\n>>>> So, your patch makes a format-patch based workflow much worse. What\n>>>> problem does it try to solve?\n>>>\n>>> I will not insist. You may know it better but git as is a public\n>>> project where anyone can create and send patches. So it seems to me\n>>> basic workflow for sharing changes.\n>>\n>> Well sure it is. We do that and discuss the merits of patches.\n>>\n>> I do use format-patch/send-email, and as I explained, your patch would\n>> make that more difficult. If there is something that it makes better\n>> that may outweigh it. Can you explain what improvement this (ignoring\n>> *.patch) introduces?\n> \n> I'm not sure how listing all the patches that you have under \"git\n> status\" will help you not to send a wrong one.\n\nWell, in order to get this patch in, you will have to explain what it is\ngood for (not that I'd decide that, but that's my recommendation for\nyou). I've asked twice and I'm still waiting for an explanation.\n\nOTOH, I've explained in detail why I consider this change bad. Please\nreread my first reply.\n\n> Also we are talking about /*.patch rule and not *.patch as with such rule:\n\nSure.\n\nMichael\n"},{"id":"171787","messageId":"4E283C9E.2050000@xiplink.com","threadId":"27859","inReplyTo":"CAGTPOqcd5G=NG83wgnH80nqNsS1FYwtRp4QjaB=oU5NkPts_Hg@mail.gmail.com","subject":"Re: [PATCH] gitignore: add top level patch ignore rule","fromName":"Marc Branchaud","fromEmail":"marcnarc@xiplink.com","sentAt":"2011-07-21T14:50:06Z","receivedAt":"2011-07-21T14:50:06Z","isPatch":true,"sender":{"key":"marcnarc@xiplink.com","avatar":"https://avatars.githubusercontent.com/u/14980203?v=4"},"body":"On 11-07-21 09:22 AM, Vitaliy Ivanov wrote:\n> On Thu, Jul 21, 2011 at 4:02 PM, Michael J Gruber\n> <git@drmicha.warpmail.net> wrote:\n>> Vitaliy Ivanov venit, vidit, dixit 21.07.2011 14:54:\n>>> Michael,\n>>>\n>>> On Wed, Jul 20, 2011 at 11:09 AM, Michael J Gruber\n>>> <git@drmicha.warpmail.net> wrote:\n>>>> Vitaliy Ivanov venit, vidit, dixit 20.07.2011 00:17:\n>>>>> Add top level ignore rule for patches created by format-patch command.\n>>>>\n>>>> Please don't.\n>>>>\n>>>> The tracked ignore file is for ignoring products and artefacts of our\n>>>> build process. format-patch is not part of this process, and the\n>>>> existence of *.patch files depends on your workflow. But what is much\n>>>> worse: In\n>>>>\n>>>> git status\n>>>> git format-patch rev-spec\n>>>> git send-email *.patch\n>>>>\n>>>> it is very easy to send out the wrong patches (along with the right\n>>>> ones), because your patch hides them from status. Also, I can't clean\n>>>> them up with \"git clean -f\" any more. I would have to use \"git clean -f\n>>>> -x\" which would clean the build products also (and force a rebuild).\n>>>>\n>>>> So, your patch makes a format-patch based workflow much worse. What\n>>>> problem does it try to solve?\n>>>\n>>> I will not insist. You may know it better but git as is a public\n>>> project where anyone can create and send patches. So it seems to me\n>>> basic workflow for sharing changes.\n>>\n>> Well sure it is. We do that and discuss the merits of patches.\n>>\n>> I do use format-patch/send-email, and as I explained, your patch would\n>> make that more difficult. If there is something that it makes better\n>> that may outweigh it. Can you explain what improvement this (ignoring\n>> *.patch) introduces?\n> \n> I'm not sure how listing all the patches that you have under \"git\n> status\" will help you not to send a wrong one.\n\nSeeing various patch files in \"git status\" bothered me as well.\n\nSo I put all my patches in a top-level patches/ directory, along with a\npatches/.gitignore file that ignores everything there.\n\nIf that doesn't meet your needs, you could instead add a core.excludesfile\nentry to your ~/.gitconfig, and in there ignore *.patch files.\n\nSo given those alternatives, I'm not convinced your patch is suitable for all\ngit users.\n\n\t\tM.\n"},{"id":"171839","messageId":"CAGTPOqdQNBMueCxjvwKHFmdX4YgPSuHwV2GKT5DVysndqgPo=Q@mail.gmail.com","threadId":"27859","inReplyTo":"4E283C9E.2050000@xiplink.com","subject":"Re: [PATCH] gitignore: add top level patch ignore rule","fromName":"Vitaliy Ivanov","fromEmail":"vitalivanov@gmail.com","sentAt":"2011-07-22T13:20:27Z","receivedAt":"2011-07-22T13:20:27Z","isPatch":true,"sender":{"key":"vitalivanov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2084293?v=4"},"body":"On Thu, Jul 21, 2011 at 5:50 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:\n> On 11-07-21 09:22 AM, Vitaliy Ivanov wrote:\n>> On Thu, Jul 21, 2011 at 4:02 PM, Michael J Gruber\n>> <git@drmicha.warpmail.net> wrote:\n>>> Vitaliy Ivanov venit, vidit, dixit 21.07.2011 14:54:\n>>>> Michael,\n>>>>\n>>>> On Wed, Jul 20, 2011 at 11:09 AM, Michael J Gruber\n>>>> <git@drmicha.warpmail.net> wrote:\n>>>>> Vitaliy Ivanov venit, vidit, dixit 20.07.2011 00:17:\n>>>>>> Add top level ignore rule for patches created by format-patch command.\n>>>>>\n>>>>> Please don't.\n>>>>>\n>>>>> The tracked ignore file is for ignoring products and artefacts of our\n>>>>> build process. format-patch is not part of this process, and the\n>>>>> existence of *.patch files depends on your workflow. But what is much\n>>>>> worse: In\n>>>>>\n>>>>> git status\n>>>>> git format-patch rev-spec\n>>>>> git send-email *.patch\n>>>>>\n>>>>> it is very easy to send out the wrong patches (along with the right\n>>>>> ones), because your patch hides them from status. Also, I can't clean\n>>>>> them up with \"git clean -f\" any more. I would have to use \"git clean -f\n>>>>> -x\" which would clean the build products also (and force a rebuild).\n>>>>>\n>>>>> So, your patch makes a format-patch based workflow much worse. What\n>>>>> problem does it try to solve?\n>>>>\n>>>> I will not insist. You may know it better but git as is a public\n>>>> project where anyone can create and send patches. So it seems to me\n>>>> basic workflow for sharing changes.\n>>>\n>>> Well sure it is. We do that and discuss the merits of patches.\n>>>\n>>> I do use format-patch/send-email, and as I explained, your patch would\n>>> make that more difficult. If there is something that it makes better\n>>> that may outweigh it. Can you explain what improvement this (ignoring\n>>> *.patch) introduces?\n>>\n>> I'm not sure how listing all the patches that you have under \"git\n>> status\" will help you not to send a wrong one.\n>\n> Seeing various patch files in \"git status\" bothered me as well.\n>\n> So I put all my patches in a top-level patches/ directory, along with a\n> patches/.gitignore file that ignores everything there.\n>\n> If that doesn't meet your needs, you could instead add a core.excludesfile\n> entry to your ~/.gitconfig, and in there ignore *.patch files.\n>\n> So given those alternatives, I'm not convinced your patch is suitable for all\n> git users.\n\nSure. It's not a problem. And thanks for describing workarounds here.\nActually, this issue is not bothering me a lot but I know that's a\nusual practice to put patches to git ignore list.\nThat's why I proposed it to the list.\n\n\nVitaliy\n"}]}