Re: [PATCH] gitignore: add top level patch ignore rule

From: Vitaliy Ivanov <vitalivanov@gmail.com>
Date: Jul 21, 2011, 13:22 UTC
Message-ID: <CAGTPOqcd5G=NG83wgnH80nqNsS1FYwtRp4QjaB=oU5NkPts_Hg@mail.gmail.com>
In-Reply-To: <4E282349.4040404@drmicha.warpmail.net>

On Thu, Jul 21, 2011 at 4:02 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Show 37 quoted lines

> Vitaliy Ivanov venit, vidit, dixit 21.07.2011 14:54:
>> Michael,
>>
>> On Wed, Jul 20, 2011 at 11:09 AM, Michael J Gruber
>> <git@drmicha.warpmail.net> 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

Show 11 quoted lines

>>>> 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