* Re: [Feature request] autoresolve modify/delete conflict via .gitattributes merge= attribute
2024-11-06 11:56 [Feature request] autoresolve modify/delete conflict via .gitattributes merge= attribute ilya Basin
@ 2024-11-07 0:34 ` brian m. carlson
0 siblings, 0 replies; 2+ messages in thread
From: brian m. carlson @ 2024-11-07 0:34 UTC (permalink / raw)
To: ilya Basin; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 2286 bytes --]
On 2024-11-06 at 11:56:06, ilya Basin wrote:
> Hi. This is also described in this SO question:
> https://stackoverflow.com/questions/58767528/how-to-specify-a-git-merge-ours-strategy-with-gitattributes-for-deleted-files
>
> Our proprietary IDE generates theme-cache/web/theme.compiled.css and the contents are different on different machines.
> This file was supposed to be in .gitignore, but it slipped into the repo.
> I was trying to remove the file, but other developers silently re-introduce it into the repo. Here's what happens:
> - The proprietary IDE re-generates the file and makes a local commit.
> - The IDE does "pull --rebase" which results in a "deleted by us" conflict
> - The IDE immediately re-generates the file, clearing the conflicted state
> - Even though it's in .gitignore, the file remains under version control because of the cherry-pick by rebase
>
> I was hoping that adding a certain merge= attribute for this file would help, but apparently it only considered when two files are merged, not when one is deleted.
In general, the recommended settings for the merge option are "text",
"binary", and a custom merge driver. "text" is useful when you have
things that may look binary to Git, but are not, and "binary" is useful
when you have things that look like text but are not usefully mergeable
(such as some PostScript or PDF files). Custom merge drivers can be
useful in some case, but they don't work with forges since they require
configuration, so they require a lot of setup and careful use.
You can certainly set other things, but they tend to be tricky, and I
can't think of a really great algorithm that will do what you want here,
so I'm not going to propose one.
What you could do is add something to your CI job that fails if the file
is checked in. Once that's that's activated, people will stop being
able to check it in, and once everyone has a version of the main branch
that doesn't have it checked in, the rebase will stop including it
because it will be ignored, so even if it gets re-created, it won't be
able to be added.
This will cause some minor short-term pain, but it should be enough to
get you in the right direction.
--
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread