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 <melif...@freebsd.org>
AuthorDate: 2022-01-08 16:14:47 +0000
Commit: Alexander V. Chernikov <melif...@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
