git - игнорировать конфликты при rebase на некоторых файлах

Возможно ты хочешь merge=ours?

Лучше избався от этой фигни. Я хз как ты собираешся разрешать конфликт типа:
master -(branch)-> featureA-(commit generated)
master -(branch)-> featureB-(commit generated)
merge featureA into master (no conflicts)
merge featureB into master (conflict on generated files)
У мегя тажелый случай, ибо генерированый файл это .min.css и фиг его смержить возможно. Проще таки научится генерировать файлы когда нужно(при билде).

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

Да. Но для конкретных каталогов. Для всех файлов не нужно.

Можно попробовать сделать вроде такого в этих каталогах (git config один раз на репозиторий надо сделать):

git config merge.ours.driver true
echo '* merge=ours' >> .gitattributes 

значит ты просто перегенеришь эти файлы

Ну хрень в том что

не у всех установлены снтрументы для генерации.

а также
У меня по процедуре все мержи делаются в гребаном Stashe, т.е. не перегенерируешь. Хреново мне в моём случае в общем.

gitignore, move ?

Сработало! Еще бы как-нибудь сделать чтобы не пришлось у всех на машинах выполнять

git config merge.ours.driver true

А вот такого вроде нет, там надо сделать как минимум:

git config include.path ../.gitconfig

Это попытка устранить симптом, оставляя саму проблему. Git не зря называется SCM, source control management. Ключевое слово здесь source, то-есть исходный файл, который написал человек. Сгенерированный код берётся из исходного, ложить его в репозиторий не просто бессмысленно, но вредно. Это значит что у вас дыра в системе сборки, когда правится исходный файл или скрипт генерации, то сгенерированный файл остаётся старым пока хозяин не вспомнит, что нужно прогнать некие скрипты.

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

Ну и по сути игнорирование кода сгенерированного на другой стороне через merge=ours гарантированно ломает ревизию. Раньше гит хоть матерился на возможные конфликты, а теперь как только другие пользователи начнут использовать это ноу-хау с merge=ours, то у них будет молча создаваться нерабочая ревизия.

Вам нужно либо заставить других пользователей установить инструменты генерации и поправить систему сборки. Либо вынести артефакты сборки (бинари, сгенерированный код) куда-нибудь в отдельный проект за пределы основного дерева.

Зачем хранить в репе временные файлы? Почему бы не генерировать их при деплое?

Если так уж надо выкладывать генерённые файлы, то зачем выкладывать их в git? Не проще просто zip куда-нибудь положить?

Может лучше запилить .gitignore, а файлы генерить только по необходимости?

Он будет версионным?

КЛАСТЬ, а не ложить :). Генерация происходит очень разными инструментами - protobuff, самописный генератор на С++, Simulink итд.

Вот случай из жизни. Вчера были испытания протоипа на аэродроме. Дождик, охрененный ветер. Потребовалось внести изменния в одной строчке. Внесли, запустили все пошло. А если бы еще сначала надо бло бы запускать симулинк, генерить на нем, потом генерить другие файлы все бы заняло ЗНАЧИТЕЛЬНО больше времени. Да и симулинк просто не у всех стоит, т.к. тула страшная и дорогая. Да и запускается очень долго, особенно если ноут в режиме экономии потребления.

Сгенерированный код берётся из исходного, ложить его в репозиторий не просто бессмысленно, но вредно.

Это надо вайновцам ещё объяснить:

include/wine/server_protocol.h

   1 /*
   2  * Wine server protocol definitions
   3  *
   4  * This file is automatically generated; DO NO EDIT!
   5  * Edit server/protocol.def instead and re-run tools/make_requests
   6  */

dlls/dwrite/scripts.c

   1 /* Unicode Script IDs */
   2 /* generated from http://www.unicode.org/Public/9.0.0/ucd/Scripts.txt */
   3 /* DO NOT EDIT!! */

dlls/ntdll/tests/generated.c

   1 /* File generated automatically from tools/winapi/tests.dat; do not edit! */
   2 /* This file can be copied, modified and distributed without restriction. */

У меня в репизитории лежат автогенеренные файлы.

Заигнорить их и генерировать по требованию. Всё остальное — костыли.

Это уж как сделаете. Думаю, на github.io что-то подобное будет в самый раз.

Ну хрень в том что

не у всех установлены снтрументы для генерации.

Тот, кто может сгенерить, тот генерит локально в generated/. Кто не может, тот копирует из templates/generic/etc в generated/.
В .gitignore добавляется запись generated/

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

А потом человек захочет собрать старую версию, или из другого бранча. Если учесть, что и средства генерации тоже меняются, то совсем грустно.

Например, один внес изменения в данные, на основе которых генерится код, другой в другие данные, а третий вообще внес изменения в программу которая генерит. Изменения в программе самое страшное - одна строчка там может привестик полному изменению сгенеренных файлов.

А потом человек захочет собрать старую версию, или из другого бранча. Если учесть, что и средства генерации тоже меняются, то совсем грустно.

В старой версии или в другом бранче будут лежать актуальные templates/generic/etc.

Если же пользователь переключит бранч, но не создаст (или не скопирует темплейты из templates/generic/etc), то это ССЗБ. Но с таким же успехом он может оставить профайл приложения, который не совместим с этой версией.

p.s. Володя, твой пример надуманный.

А тут выхлоп вообще зависит от количества параметров, заданных пользователем при запуске приложения:

int main(int argc, const char** argv)
{
  return argc;
}