git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [git for translators] How to always generate conflicts for merges?

From
Ilya Kantor <iliakan@gmail.com>
Date
Jul 25, 2019, 17:42 UTC
Message-ID
<15314A71-8121-428D-A62D-08E1C1AC0E1B@gmail.com>
In-Reply-To
<xmqqtvbaoysd.fsf@gitster-ct.c.googlers.com>
Hi Junio,
There's a repo for each language, with the same file structure.

For example, English version (upstream): https://github.com/javascript-tutorial/en.javascript.info/blob/master/1-js/01-getting-started/1-intro/article.md

Japanese: https://github.com/javascript-tutorial/ja.javascript.info/blob/master/1-js/01-getting-started/1-intro/article.md

As English version is updated, changes need to be delivered to translations. That's done with "git pull upstream master" from translations.

As the text structure (paragraphs) is the same, usually merges give conflicts exactly in the places where English version changed.
Sometimes though, e.g. when a new chapter is added to upstream, the merge just goes through "successfully".
That's what I'd like to avoid, as all changes need to be human-controlled.

--- Ilya Kantor https://javascript.info

Show 37 quoted lines
> On 25 Jul 2019, at 19:37, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Ilya Kantor <iliakan@gmail.com> writes:
> 
>> 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.
>> 
>> When we pull changes from upstream (English) to translation
>> (e.g. Japanese), git auto-merges them.
>> 
>> Sometimes there conflicts, but not all the time.
>> 
>> For example, when a new file is added to English, it just gets
>> auto-merged into Japanese.  But all new changes must be
>> human-controlled, translated.
>> 
>> Is there a way to force git always generate a conflict, even if
>> changes could be auto-merged?
> 
> I am not sure what the workflow here and if it makes sense.  When
> you have a file, "chapter47.txt", whose original is in English, the
> translation projects (there are N of them, one for each language)
> will have their own "chapter47.txt" that has translated text in the
> same place?  It looks to me that, working that way, the project for
> translating into e.g. Japanese have no way to keep any of the
> original English version, in which case why are you even "merging"
> the English version in the first place?
> 
> I would have understood if the original "chapter47.txt" is translated
> into "chapter47_ja.txt" and friends, like "chapter47_fr.txt", all of
> which sit next to the original "chapter47.txt".  Then merging an
> updated version of the original from time to time would make perfect
> sense to me---that would give you a way to see what changed in the
> original (e.g. "git show --first-parent -m -p master chapter47.txt")
> to guide you find the places you would need to make corresponding
> changes to the variant of your language, e.g. "chapter47_??.txt".
> 
Previous: Junio C HamanoNext: Sergey Lukashev
Message 4 of 5 in “[git for translators] How to always generate conflicts for merges?”
  1. Ilya KantorJul 25, 2019
  2. Santiago Torres AriasJul 25, 2019
  3. Junio C HamanoJul 25, 2019
  4. Ilya KantorJul 25, 2019
  5. Sergey LukashevJul 26, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.