{"thread":{"id":"51525","subject":"[git for translators] How to always generate conflicts for merges?","startedAt":"2019-07-25T13:42:52Z","lastAt":"2019-07-26T20:47:23Z","messageCount":5,"participants":["Ilya Kantor","Santiago Torres Arias","Junio C Hamano","Sergey Lukashev"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"379273","messageId":"C9A27ED4-CBD9-4FCD-B78F-8A1010D24D06@gmail.com","threadId":"51525","inReplyTo":null,"subject":"[git for translators] How to always generate conflicts for merges?","fromName":"Ilya Kantor","fromEmail":"iliakan@gmail.com","sentAt":"2019-07-25T13:42:48Z","receivedAt":"2019-07-25T13:42:52Z","isPatch":false,"sender":{"key":"iliakan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349336?v=4"},"body":"Hi,\n\nWe're using Git to manage translations of an open-source book, and most of time it works well. But there's also a problem.\n\nWhen we pull changes from upstream (English) to translation (e.g. Japanese), git auto-merges them.\n\nSometimes there conflicts, but not all the time.\n\nFor example, when a new file is added to English, it just gets auto-merged into Japanese.\nBut all new changes must be human-controlled, translated. \n\nIs there a way to force git always generate a conflict, even if changes could be auto-merged?\n\n----\nIlya\nhttps://javascript.info"},{"id":"379275","messageId":"20190725142533.5rcwl5frvv3bjx4s@LykOS.localdomain","threadId":"51525","inReplyTo":"C9A27ED4-CBD9-4FCD-B78F-8A1010D24D06@gmail.com","subject":"Re: [git for translators] How to always generate conflicts for merges?","fromName":"Santiago Torres Arias","fromEmail":"santiago@nyu.edu","sentAt":"2019-07-25T14:25:34Z","receivedAt":"2019-07-25T15:23:52Z","isPatch":false,"sender":{"key":"santiago@nyu.edu","avatar":"https://avatars.githubusercontent.com/u/3579933?v=4"},"body":"Hi,\n\nI'm not completely sure if this is the best way to achieve this, but I\nyou could instruct a merge driver to mark all new files as unset.\n\nCheers!\n-Santiago.\n\nOn Thu, Jul 25, 2019 at 04:42:48PM +0300, Ilya Kantor wrote:\n> Hi,\n> \n> We're using Git to manage translations of an open-source book, and most of time it works well. But there's also a problem.\n> \n> When we pull changes from upstream (English) to translation (e.g. Japanese), git auto-merges them.\n> \n> Sometimes there conflicts, but not all the time.\n> \n> For example, when a new file is added to English, it just gets auto-merged into Japanese.\n> But all new changes must be human-controlled, translated. \n> \n> Is there a way to force git always generate a conflict, even if changes could be auto-merged?\n> \n> ----\n> Ilya\n> https://urldefense.proofpoint.com/v2/url?u=https-3A__javascript.info&d=DwIFAg&c=slrrB7dE8n7gBJbeO0g-IQ&r=yZMPY-APGKyVIX7HgQFZJA&m=fywBEjNJhlI37lKNhH6u90hEOBCF5PqmRunhDCRO0Fg&s=We1ibeYQn4Z4Gf53M4CUyENq_BHhavulOg20KJIRxOg&e= \n"},{"id":"379279","messageId":"xmqqtvbaoysd.fsf@gitster-ct.c.googlers.com","threadId":"51525","inReplyTo":"C9A27ED4-CBD9-4FCD-B78F-8A1010D24D06@gmail.com","subject":"Re: [git for translators] How to always generate conflicts for merges?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-07-25T16:37:54Z","receivedAt":"2019-07-25T16:37:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ilya Kantor writes:\n\n> We're using Git to manage translations of an open-source book, and\n> most of time it works well. But there's also a problem.\n>\n> When we pull changes from upstream (English) to translation\n> (e.g. Japanese), git auto-merges them.\n>\n> Sometimes there conflicts, but not all the time.\n>\n> For example, when a new file is added to English, it just gets\n> auto-merged into Japanese. But all new changes must be\n> human-controlled, translated.\n>\n> Is there a way to force git always generate a conflict, even if\n> changes could be auto-merged?\n\nI am not sure what the workflow here and if it makes sense. When\nyou have a file, \"chapter47.txt\", whose original is in English, the\ntranslation projects (there are N of them, one for each language)\nwill have their own \"chapter47.txt\" that has translated text in the\nsame place? It looks to me that, working that way, the project for\ntranslating into e.g. Japanese have no way to keep any of the\noriginal English version, in which case why are you even \"merging\"\nthe English version in the first place?\n\nI would have understood if the original \"chapter47.txt\" is translated\ninto \"chapter47_ja.txt\" and friends, like \"chapter47_fr.txt\", all of\nwhich sit next to the original \"chapter47.txt\". Then merging an\nupdated version of the original from time to time would make perfect\nsense to me---that would give you a way to see what changed in the\noriginal (e.g. \"git show --first-parent -m -p master chapter47.txt\")\nto guide you find the places you would need to make corresponding\nchanges to the variant of your language, e.g. \"chapter47_??.txt\".\n\n"},{"id":"379283","messageId":"15314A71-8121-428D-A62D-08E1C1AC0E1B@gmail.com","threadId":"51525","inReplyTo":"xmqqtvbaoysd.fsf@gitster-ct.c.googlers.com","subject":"Re: [git for translators] How to always generate conflicts for merges?","fromName":"Ilya Kantor","fromEmail":"iliakan@gmail.com","sentAt":"2019-07-25T17:42:09Z","receivedAt":"2019-07-25T17:42:17Z","isPatch":false,"sender":{"key":"iliakan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/349336?v=4"},"body":"Hi Junio,\n\nThere's a repo for each language, with the same file structure.\n\nFor example, English version (upstream):\nhttps://github.com/javascript-tutorial/en.javascript.info/blob/master/1-js/01-getting-started/1-intro/article.md\n\nJapanese:\nhttps://github.com/javascript-tutorial/ja.javascript.info/blob/master/1-js/01-getting-started/1-intro/article.md\n\nAs English version is updated, changes need to be delivered to translations.\nThat's done with \"git pull upstream master\" from translations.\n\nAs the text structure (paragraphs) is the same, usually merges give conflicts exactly in the places where English version changed.\n\nSometimes though, e.g. when a new chapter is added to upstream, the merge just goes through \"successfully\".\n\nThat's what I'd like to avoid, as all changes need to be human-controlled.\n\n---\nIlya Kantor\nhttps://javascript.info\n\n> On 25 Jul 2019, at 19:37, Junio C Hamano wrote:\n> \n> Ilya Kantor writes:\n> \n>> We're using Git to manage translations of an open-source book, and\n>> most of time it works well. But there's also a problem.\n>> \n>> When we pull changes from upstream (English) to translation\n>> (e.g. Japanese), git auto-merges them.\n>> \n>> Sometimes there conflicts, but not all the time.\n>> \n>> For example, when a new file is added to English, it just gets\n>> auto-merged into Japanese. But all new changes must be\n>> human-controlled, translated.\n>> \n>> Is there a way to force git always generate a conflict, even if\n>> changes could be auto-merged?\n> \n> I am not sure what the workflow here and if it makes sense. When\n> you have a file, \"chapter47.txt\", whose original is in English, the\n> translation projects (there are N of them, one for each language)\n> will have their own \"chapter47.txt\" that has translated text in the\n> same place? It looks to me that, working that way, the project for\n> translating into e.g. Japanese have no way to keep any of the\n> original English version, in which case why are you even \"merging\"\n> the English version in the first place?\n> \n> I would have understood if the original \"chapter47.txt\" is translated\n> into \"chapter47_ja.txt\" and friends, like \"chapter47_fr.txt\", all of\n> which sit next to the original \"chapter47.txt\". Then merging an\n> updated version of the original from time to time would make perfect\n> sense to me---that would give you a way to see what changed in the\n> original (e.g. \"git show --first-parent -m -p master chapter47.txt\")\n> to guide you find the places you would need to make corresponding\n> changes to the variant of your language, e.g. \"chapter47_??.txt\".\n> \n\n"},{"id":"379400","messageId":"318401564173651@iva7-56e9317134d0.qloud-c.yandex.net","threadId":"51525","inReplyTo":"15314A71-8121-428D-A62D-08E1C1AC0E1B@gmail.com","subject":"Re: [git for translators] How to always generate conflicts for merges?","fromName":"Sergey Lukashev","fromEmail":"lukashev.s@ya.ru","sentAt":"2019-07-26T20:40:51Z","receivedAt":"2019-07-26T20:47:23Z","isPatch":false,"sender":{"key":"lukashev.s@ya.ru","avatar":null},"body":"Hi everyone!\n\nAs I see it, in Junio's approach you more likely to have a translation and original out of sync because you have to figure out whether the changes in the original are actually reflected in the translation, which could be a tedious thing to do again and again.\n\nIn the approach that Ilya uses you HAVE TO manually fix just what has changed: you will have a content in the original language in places not yet translated. This approach abuses git a bit and, as I understand, works because all the repos with the translations were probably forked from the original repo so they are NOT unrelated.\n\nAs the answer to the original problem I would ask if it really matters whether you have a conflict or not. Just fix conflicts, commit and review all the new stuff that was added in the commits just merged and fix it too. The process is still human-controlled: if you do forget to translate something, it will be left untraslated and is likely to be spotted soon. You want to have a conflict where there ain't one (a new content that does not exist in your translation). A conflict is when something has changed in different wayS since a common ancestor.\n\n\n25.07.2019, 20:42, \"Ilya Kantor\" :\n> Hi Junio,\n>\n> There's a repo for each language, with the same file structure.\n>\n> For example, English version (upstream):\n> https://github.com/javascript-tutorial/en.javascript.info/blob/master/1-js/01-getting-started/1-intro/article.md\n>\n> Japanese:\n> https://github.com/javascript-tutorial/ja.javascript.info/blob/master/1-js/01-getting-started/1-intro/article.md\n>\n> As English version is updated, changes need to be delivered to translations.\n> That's done with \"git pull upstream master\" from translations.\n>\n> As the text structure (paragraphs) is the same, usually merges give conflicts exactly in the places where English version changed.\n>\n> Sometimes though, e.g. when a new chapter is added to upstream, the merge just goes through \"successfully\".\n>\n> That's what I'd like to avoid, as all changes need to be human-controlled.\n>\n> ---\n> Ilya Kantor\n> https://javascript.info\n>\n>>  On 25 Jul 2019, at 19:37, Junio C Hamano wrote:\n>>\n>>  Ilya Kantor writes:\n>>\n>>>  We're using Git to manage translations of an open-source book, and\n>>>  most of time it works well. But there's also a problem.\n>>>\n>>>  When we pull changes from upstream (English) to translation\n>>>  (e.g. Japanese), git auto-merges them.\n>>>\n>>>  Sometimes there conflicts, but not all the time.\n>>>\n>>>  For example, when a new file is added to English, it just gets\n>>>  auto-merged into Japanese. But all new changes must be\n>>>  human-controlled, translated.\n>>>\n>>>  Is there a way to force git always generate a conflict, even if\n>>>  changes could be auto-merged?\n>>\n>>  I am not sure what the workflow here and if it makes sense. When\n>>  you have a file, \"chapter47.txt\", whose original is in English, the\n>>  translation projects (there are N of them, one for each language)\n>>  will have their own \"chapter47.txt\" that has translated text in the\n>>  same place? It looks to me that, working that way, the project for\n>>  translating into e.g. Japanese have no way to keep any of the\n>>  original English version, in which case why are you even \"merging\"\n>>  the English version in the first place?\n>>\n>>  I would have understood if the original \"chapter47.txt\" is translated\n>>  into \"chapter47_ja.txt\" and friends, like \"chapter47_fr.txt\", all of\n>>  which sit next to the original \"chapter47.txt\". Then merging an\n>>  updated version of the original from time to time would make perfect\n>>  sense to me---that would give you a way to see what changed in the\n>>  original (e.g. \"git show --first-parent -m -p master chapter47.txt\")\n>>  to guide you find the places you would need to make corresponding\n>>  changes to the variant of your language, e.g. \"chapter47_??.txt\".\n\n\n"}]}