Лучшее место / фаза для разрешения окончания строки символов '^ M' или '\ r'

Question

Мне нужно провести рефакторинг файла, заменив коды сообщений обновленными значениями.Мой оригинальный файл присутствует на сервере Ubuntu, к которому я могу подключиться и получить доступ к файлам Windows.Я клонировал его через git в Ubuntu Server, затем переместил файл в Windows и в Windows, с помощью небольшой программы на Java, изменил значение и записал его.Затем откройте файл в Windows и файл для копирования, вставьте файл на сервер Ubuntu (поскольку копирование заменяет или перемещает замену файла, покажите git diff, когда все содержимое будет изменено).

Ниже приведен код Java, который я использовал для рефакторинга.

        ruleInBR = new BufferedReader(new FileReader(ruleIn));
        ruleOutBW = new BufferedWriter(new FileWriter(ruleOut));
        csvOutBW = new BufferedWriter(new FileWriter(csvOut));

        String readRule = "";
        int lineNo = 1;

        while((readRule = ruleInBR.readLine()) != null)
        {
            if(details.get(lineNo) != null)
            {
                AlterValuePair<String> avPair = details.get(lineNo);
                String renamedRule = readRule.replace(avPair.getOldValue(),avPair.getNewValue());
                String trimRenamedRule = renamedRule.replace("\r","");
                csvOutBW.write(lineNo + ", " + avPair.getOldValue() + ", " + avPair.getNewValue() +"\n");
                ruleOutBW.write(trimRenamedRule + "\n");
                count++;
            }
            else {
                String trimReadRule = readRule.replace("\r","");
                ruleOutBW.write(trimReadRule +"\n");

            }
            lineNo++;
        }

Но в GitDiff я сталкиваюсь с проблемами присутствия git diff для '^ M' или 'Что я на самом деле не сделал, и насколько я знаю, я знаю, что это потому, что я открыл и работал с некоторыми редакторами, которые заканчивают эти строки.Поскольку рефакторинг файла вызовет проблемы при компиляции в Ubuntu из-за неожиданного символа.Я использовал следующие подходы, которые я изучил ранее и нашел в Переполнении стека.

Я адаптировал следующие варианты в vim

1. set ff = unix / set fileformat = unix
2. set ff = dos / set fileformat = dos
3. % s / \ r \ n / \ n / или% s / \ r // или% s / \ r // g
4. dos2unix fileName
5. perl -pi -e 's / \ r //' или perl -pi -e 's / \ r \ n / \ n /'

Но во всех этих случаях он изменял весь файл как новый файл, и в git diff он показывает все новые изменения, а старые, которые я не менял, изменяются.Есть ли способы решить эту проблему?

У меня есть следующие вопросы из переполнения стека:

1. gVim, показывающий возврат каретки (^ M), даже когда режим файлаявно DOS
2. Преобразование концов строки DOS в окончания строк Linux в vim
3. ^ M в конце каждой строки в vim
4. Удалить строку в текстовом файле с помощью java.BufferedReader
5. https://its.ucsc.edu/unix-timeshare/tutorials/clean-ctrl-m.html
6. https://www.garron.me/en/bits/get-rid-m-characters-vim.html

Но нетиз них мне помогли в позитивном ключе.

ОБНОВЛЕНИЕ

Наконец, после выполнения инструкции из другого вопроса переполнения стека, в котором говорится об пропуске на уровне фиксации, который будет пропущендобавление пробелов и это немного решило мои проблемы, но у этого также есть некоторые недостатки, потому что у него есть некоторые части тех же файлов, которые не зафиксированы (фактически принадлежат тем, которые пропущены в пробеле).

Я не знаюна самом деле, как справиться с этим, как я должен внести изменения внесколько ветвей и все это может или не может пройти через эту проблему.Есть ли какой-нибудь простой способ, вместо того, чтобы делать на уровне git commit.Где я должен игнорировать пробелы и фиксировать и хранить незафиксированные изменения каждый раз, когда я фиксирую это следующим образом.

Кстати, ссылка переполнения стека: Добавить только изменения без пробелов

Answer 1

Итак, ваша временная шкала, как подтверждается в комментариях, о том, что происходило:

1) извлеченные файлы в Unix.Файл имеет конец строки Unix (LF).

2), скопированный в Windows.В файле по-прежнему есть окончания строк Unix.

3) пробегал файл Java для изменения некоторых значений.Когда вы читаете файл, вы пытаетесь удалить CR из него, даже если он не содержит CR в первую очередь (только LF);но даже если он содержит CR, он не будет работать, потому что вы получите строку без окончаний строки, как указано в BufferedReader.readLine документации.Вы пишете строки в новый файл с \n;Java понимает \n как «терминатор конца строки», что заставляет Java-на-Windows записывать окончания строк Windows (CR LF) в каждой записанной строке (в обеих ветвях if - т.е. как в измененных строках, так и вте, которые вы просто намереваетесь скопировать без изменений).Теперь файл содержит окончания Windows (CR LF) во всех его строках.

4) скопировал преобразованный файл обратно в Unix.Концы строк - это Windows (CR LF).

5) зафиксировал файл.Поскольку вы зафиксировали файл в Linux, я предполагаю, что git не был настроен для удаления их во время фиксации.Таким образом, файл фиксируется с каждой измененной строкой: некоторые строки существенно, но некоторые строки тривиально (только с изменением ограничителя строки).

Теперь вы находитесь в ситуации, когда вы пытаетесь получить Unixразделители строк возвращаются, вы эффективно изменяете весь файл - потому что каждая строка должна быть изменена, даже немного.

Другие опции:

Если вы уже отодвинули изменения, очевидноеможно было бы git revert сделать этот коммит (который также будет выглядеть как изменение всего файла, но, по крайней мере, очевидно, что это возврат), затем либо перезапустить программу Java на Unix-машине , либосделайте dos2unix file после копирования обратно на Unix-машину, но перед фиксацией.

Если вы не нажали изменения, вы можете получить git reset --hard HEAD^ вместо возврата.