{"thread":{"id":"62458","subject":"[Feature request] autoresolve modify/delete conflict via .gitattributes merge= attribute","startedAt":"2024-11-06T11:56:09Z","lastAt":"2024-11-07T00:34:57Z","messageCount":2,"participants":["ilya Basin","brian m. carlson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"506711","messageId":"f1a8afe2-df78-40d9-9866-d49dc4057806@gmail.com","threadId":"62458","inReplyTo":null,"subject":"[Feature request] autoresolve modify/delete conflict via .gitattributes merge= attribute","fromName":"ilya Basin","fromEmail":"basinilya@gmail.com","sentAt":"2024-11-06T11:56:06Z","receivedAt":"2024-11-06T11:56:09Z","isPatch":false,"sender":{"key":"basinilya@gmail.com","avatar":null},"body":"Hi. This is also described in this SO question:\nhttps://stackoverflow.com/questions/58767528/how-to-specify-a-git-merge-ours-strategy-with-gitattributes-for-deleted-files\n\nOur proprietary IDE generates theme-cache/web/theme.compiled.css and the contents are different on different machines.\nThis file was supposed to be in .gitignore, but it slipped into the repo.\nI was trying to remove the file, but other developers silently re-introduce it into the repo. Here's what happens:\n- The proprietary IDE re-generates the file and makes a local commit.\n- The IDE does \"pull --rebase\" which results in a \"deleted by us\" conflict\n- The IDE immediately re-generates the file, clearing the conflicted state\n- Even though it's in .gitignore, the file remains under version control because of the cherry-pick by rebase\n\nI 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.\n\n"},{"id":"506765","messageId":"ZywLGNsTqykDFfMH@tapette.crustytoothpaste.net","threadId":"62458","inReplyTo":"f1a8afe2-df78-40d9-9866-d49dc4057806@gmail.com","subject":"Re: [Feature request] autoresolve modify/delete conflict via .gitattributes merge= attribute","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2024-11-07T00:34:32Z","receivedAt":"2024-11-07T00:34:57Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2024-11-06 at 11:56:06, ilya Basin wrote:\n> Hi. This is also described in this SO question:\n> https://stackoverflow.com/questions/58767528/how-to-specify-a-git-merge-ours-strategy-with-gitattributes-for-deleted-files\n> \n> Our proprietary IDE generates theme-cache/web/theme.compiled.css and the contents are different on different machines.\n> This file was supposed to be in .gitignore, but it slipped into the repo.\n> I was trying to remove the file, but other developers silently re-introduce it into the repo. Here's what happens:\n> - The proprietary IDE re-generates the file and makes a local commit.\n> - The IDE does \"pull --rebase\" which results in a \"deleted by us\" conflict\n> - The IDE immediately re-generates the file, clearing the conflicted state\n> - Even though it's in .gitignore, the file remains under version control because of the cherry-pick by rebase\n> \n> 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.\n\nIn general, the recommended settings for the merge option are \"text\",\n\"binary\", and a custom merge driver.  \"text\" is useful when you have\nthings that may look binary to Git, but are not, and \"binary\" is useful\nwhen you have things that look like text but are not usefully mergeable\n(such as some PostScript or PDF files).  Custom merge drivers can be\nuseful in some case, but they don't work with forges since they require\nconfiguration, so they require a lot of setup and careful use.\n\nYou can certainly set other things, but they tend to be tricky, and I\ncan't think of a really great algorithm that will do what you want here,\nso I'm not going to propose one.\n\nWhat you could do is add something to your CI job that fails if the file\nis checked in.  Once that's that's activated, people will stop being\nable to check it in, and once everyone has a version of the main branch\nthat doesn't have it checked in, the rebase will stop including it\nbecause it will be ignored, so even if it gets re-created, it won't be\nable to be added.\n\nThis will cause some minor short-term pain, but it should be enough to\nget you in the right direction.\n-- \nbrian m. carlson (they/them or he/him)\nToronto, Ontario, CA\n"}]}