On Thu, Jul 21, 2011 at 4:02 PM, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: > Vitaliy Ivanov venit, vidit, dixit 21.07.2011 14:54: >> Michael, >> >> On Wed, Jul 20, 2011 at 11:09 AM, Michael J Gruber >> <git@xxxxxxxxxxxxxxxxxxxx> wrote: >>> Vitaliy Ivanov venit, vidit, dixit 20.07.2011 00:17: >>>> Add top level ignore rule for patches created by format-patch command. >>> >>> Please don't. >>> >>> The tracked ignore file is for ignoring products and artefacts of our >>> build process. format-patch is not part of this process, and the >>> existence of *.patch files depends on your workflow. But what is much >>> worse: In >>> >>> git status >>> git format-patch rev-spec >>> git send-email *.patch >>> >>> it is very easy to send out the wrong patches (along with the right >>> ones), because your patch hides them from status. Also, I can't clean >>> them up with "git clean -f" any more. I would have to use "git clean -f >>> -x" which would clean the build products also (and force a rebuild). >>> >>> So, your patch makes a format-patch based workflow much worse. What >>> problem does it try to solve? >> >> I will not insist. You may know it better but git as is a public >> project where anyone can create and send patches. So it seems to me >> basic workflow for sharing changes. > > Well sure it is. We do that and discuss the merits of patches. > > I do use format-patch/send-email, and as I explained, your patch would > make that more difficult. If there is something that it makes better > that may outweigh it. Can you explain what improvement this (ignoring > *.patch) introduces? I'm not sure how listing all the patches that you have under "git status" will help you not to send a wrong one. Also we are talking about /*.patch rule and not *.patch as with such rule: [vitaliy.ivanov@vivanov git]$ git ls-files -i --exclude-standard contrib/patches/docbook-xsl-manpages-charmap.patch t/t4100/t-apply-1.patch t/t4100/t-apply-2.patch t/t4100/t-apply-3.patch t/t4100/t-apply-4.patch t/t4100/t-apply-5.patch t/t4100/t-apply-6.patch t/t4100/t-apply-7.patch t/t4100/t-apply-8.patch t/t4100/t-apply-9.patch t/t4109/patch1.patch t/t4109/patch2.patch t/t4109/patch3.patch t/t4109/patch4.patch t/t4110/patch1.patch t/t4110/patch2.patch t/t4110/patch3.patch t/t4110/patch4.patch t/t4110/patch5.patch >>>> On the way, reorganize ignore rules and add comments. >>> >>> How and why do you reorganize? >> >> Just to be able to find specific rule faster. Global rules are now all >> together same is for top level root rules. > > That may be a sensible cleanup, and it's good to describe that in the > commit message. Also, in general, we try to separate reorganisation > patches from those which introduce functional changes. (One may argue > whether adding *.patch falls into the latter category, though.) Yeah, I should agree here. I can resend it w/o adding new rules but simple reorganization and, of course, description for this change. Vitaliy -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html