Относительно того, как они работают, мне было интересно работать на низком уровне:

Что вызовет конфликт слияния?Используется ли контекст также инструментами для применения патча?Как они справляются с изменениями, которые на самом деле не изменяют поведение исходного кода? Например, поменять местами определения функций.

Что касается безопасности, то, честно говоря, огромный репозиторий ядра Linux является свидетельством их безопасности. Но меня интересуют следующие моменты:

Существуют ли какие-либо предостережения / ограничения в отношении инструментов, о которых пользователь должен знать?Доказано ли, что алгоритмы не дают неправильных результатов?Если нет, существуют ли реализации / документы, предлагающие интеграционное тестирование, которые хотя бы доказывают, что они эмпирически не содержат ошибок? Что-то вроде содержания этих статейBrianKorver а такжеJamesCoplien.Опять же, репозитория Linux должно хватить относительно предыдущего пункта, но мне было интересно узнать что-то более общее. Исходный код, даже если он был изменен, не сильно изменится (особенно из-за реализованного алгоритма и синтаксических ограничений), но можно ли обобщить безопасность на общие текстовые файлы?редактировать

Хорошо, люди, я редактирую, так как вопрос расплывчат, а ответы не касаются деталей.

Git / diff / patch детали

Унифицированный формат diff, который Git, по-видимому, использует по умолчанию, в основном выводит три вещи: изменение, контекст, окружающий изменение, и номера строк, относящиеся к контексту. Каждая из этих вещей может или не может быть изменена одновременно, поэтому Git в основном имеет дело с 8 возможными случаями.

Например, если строки были добавлены или удалены перед контекстом, номера строк будут другими; но если контекст и изменения все те же, тогда diff может использовать сам контекст для выравнивания текстов и применения патча (я не знаю, так ли это на самом деле). Теперь, что произойдет в других случаях? Я хотел бы узнать подробности того, как Git решает применить изменения автоматически и когда он решает выдать ошибку и позволить пользователю разрешить конфликт.

надежность

Я почти уверен, что Git полностью надежен, поскольку он имеет полную историю коммитов и может пересекать историю. Что я хотел бы, так это несколько указателей на академические исследования и ссылки на это, если они существуют.

Все еще относящиеся к этой теме, мы знаем, что Git / diff рассматривает файлы как общие текстовые файлы и работает со строками. Кроме того, алгоритм LCS, используемый diff, сгенерирует патч, пытающийся минимизировать количество изменений.

Итак, вот что я хотел бы знать:

Почему LCS используется вместо других алгоритмов строковой метрики?Если используется LCS, почему бы не использовать модифицированные версии метрики, которые действительно учитывают грамматические аспекты базового языка?Если используется такая метрика, которая учитывает грамматические аспекты, могут ли они дать преимущества? Преимуществами в этом случае может быть что угодно, например, очиститель «бревна вины».

Опять же, это могут быть огромные темы, и приветствуются академические статьи.