Re: git: b1f7154cb125 - main - gitignore: ignore vim swap files & .rej/.orig
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: >> https://urldefense.com/v3/__https://cgit.FreeBSD.org/src/commit/?id=b1f7154cb12517162a51d19ae19ec3f2dee88e11__;!!OToaGQ!4Lozvj8S2Opxre6qHuywX_aNhwm1heXl1CyQyb0N5f_fiBJEkTQGhLzE7KlqqP9C7A$ >> >> >> commit b1f7154cb12517162a51d19ae19ec3f2dee88e11 >> Author: Alexander V. Chernikov <melifaro@FreeBSD.org> >> AuthorDate: 2022-01-08 16:14:47 +0000 >> Commit: Alexander V. Chernikov <melifaro@FreeBSD.org> >> 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. P.S. And more directly to your question, find(1) still works :) -- Andriy Gapon