Re: git: b1f7154cb125 - main - gitignore: ignore vim swap files & .rej/.orig

From: Andriy Gapon <>
Date: Fri, 11 Feb 2022 06:49:08 UTC
On 11/02/2022 03:25, Andrew Gallatin wrote:
> On 1/17/22 04:35, Alexander V. Chernikov wrote:
>> The branch main has been updated by melifaro:
>> URL: 
>> commit b1f7154cb12517162a51d19ae19ec3f2dee88e11
>> Author:     Alexander V. Chernikov <>
>> AuthorDate: 2022-01-08 16:14:47 +0000
>> Commit:     Alexander V. Chernikov <>
>> CommitDate: 2022-01-17 09:35:15 +0000
>>      gitignore: ignore vim swap files & .rej/.orig
>>      Reviewed by:    cem, avg
>>      MFC after:      2 weeks
> Hi,
> I was wondering if you might consider reverting this change?
> Alternatively, can you teach me how to override this file
> locally without carrying a diff?
> I'm asking because this makes life painful for my workflow.
> Having git clean be able to handle .orig and .rej is incredibly
> handy when applying large patch sets.  It makes finding a rejected
> patch as simple as 'git clean -n | grep rej'.
> Also, when directories are removed *AND* they have an errant
> .orig or .rej file remaining in them, git rm will not garbage
> collect the directory.  This causes the build to fail.  I used
> to use the trick of 'git clean -nd' to find such directories, but
> now they are hidden.   This scenario just cost me hours of parsing
> make output, trying to figure out why my build had failed.

I cannot answer your direct question and I understand that the workflow you have 
is the workflow you are used to.

But... I personally prefer "modern style" patching and dealing with conflicts, 
etc.  Especially when dealing with a version control system and git in 
particular.  Those .orig and .rej files do not seem to be useful at all in the 
first place.

I would typically apply a patch either with git apply -3 (and git is configured 
with merge.conflictstyle diff3) or gpatch --merge=diff3 depending on where the 
patch came from (gpatch is the GNU patch from devel/patch).  For me it's much 
more convenient to deal with inline conflict markers.

And more directly to your question, find(1) still works :)

Andriy Gapon