git, оставить несколько правок для себя
gitignore ?
подробнее. Мне надо поменять две строчки в одном из файлов (которые тречатся гитом). Как тут поможет gitignore?
а, хрень спорол, оно для слегка другого юзкейса.
но впрочем man gitignore подсказывает решение git update-index --assume-unchanged
Оно должно подойти для случая, если это редкоменяемый конфиг.
но впрочем man gitignore подсказывает решение git update-index --assume-unchanged
Оно должно подойти для случая, если это редкоменяемый конфиг.
Я такие штуки вообще ни в какой коммит обычно не добавляю.
git update-index --assume-unchanged config.cfg
во, отлично, видимо то, что нужно. Я думал есть какое-то "классическое" решение через коммиты и мерджи, но такой костыль видимо идеально мне подойдет.
отлично, спасибо!
и они тебе не мешаются под рукой? Откатывать там "все взад"?
Неа. В интеллиджей, например, есть такая штука, как changesets.
ну так бы и написал, что юзаешь доп. средства. Это не то же самое, что "не создаю коммит".
Это означает, что ты не просто отказываешься от действия, а заменяешь его на какое-то другое, ещё более сложное.
еще вариант — доразработать проект так, чтобы он позволял переопределять конфигурацию через переменные окружения
этот вариант есть, но не хочется руки свои совать-с 
точнее как, система конфигурации имеется своя, как ее выносить во вне — хз, тупо костыли лепить лень. короче меня устроит решение выше.
точнее как, система конфигурации имеется своя, как ее выносить во вне — хз, тупо костыли лепить лень. короче меня устроит решение выше.
A подумал, можно заюзать aufs для невидимого для git набора изменений. К сожалению, там будет не отдельный патчсет, а целиком новый файл. Каждый раз при обновлении файла потребуется накладывать заново старый патч. Но это можно автоматизировать.
Получается так:
1. Клонируешь проект в папку ${APath}/MyProject
2. Создаёшь папку ${APath}/ProjectOverlay
3. Открываешь файл из MyProject, правишь и сохраняешь под соответствующим именем в ProjectOverlay
4. Создаёшь папку ${APath}/WorkPatchSet
5. Записываешь в неё патч для получения одного конфига из другого.
6. Создаёшь там же скрипт для накатывания этого патча по необходимости, который выдаёт сообщение об ошибке, если патч не накатывается.
7. В .git/hooks прописываешь хук на апдейт, который вызывает скрипт из пункта 6.
8. При желании делаешь отдельный git проект для ${APath}/WorkPathSet, чтобы менеджить патчи и скрипты
9. Создаёшь папку ${APath}/WorkOverlay
10. Монтируешь через aufs в неё MyProject на rw, а поверх него ProjectOverlay на ro.
Получается так:
1. Клонируешь проект в папку ${APath}/MyProject
2. Создаёшь папку ${APath}/ProjectOverlay
3. Открываешь файл из MyProject, правишь и сохраняешь под соответствующим именем в ProjectOverlay
4. Создаёшь папку ${APath}/WorkPatchSet
5. Записываешь в неё патч для получения одного конфига из другого.
6. Создаёшь там же скрипт для накатывания этого патча по необходимости, который выдаёт сообщение об ошибке, если патч не накатывается.
7. В .git/hooks прописываешь хук на апдейт, который вызывает скрипт из пункта 6.
8. При желании делаешь отдельный git проект для ${APath}/WorkPathSet, чтобы менеджить патчи и скрипты
9. Создаёшь папку ${APath}/WorkOverlay
10. Монтируешь через aufs в неё MyProject на rw, а поверх него ProjectOverlay на ro.
нечитал, но плюсодин 
Нафига так извращаться, если уж хочешь так делать, можно делать средствами самого гита, например завести named stash и накатывать его после апдейта/делать git reset --hard на эти файлы перед коммитом.
Основная проблема как раз во второй половине (про которую ты ничего не сказал что делать перед коммитом? Что делать, если есть локальные изменения в этом файле помимо тех, что должны быть реально локальными? У нас нет возможности "откатить" патч, чтобы получить оригинальный файл + изменения не в патче.
Вариант с update-index --assume-unchaged по крайней мере оставляет их в working copy, так что если ты обнаружил что они у тебя есть, ну, отлично, git stash --patch тру-локальные изменения, коммитишь остальное, накатываешь стеш обратно. Автоматический вариант с гитом или aufs молча переписывающими файлы нафиг как бы хуже.
Кстати! Я тут подумал! По идее же вроде cherry-pick позволяет делать такую штуку. Типа, у тебя есть бранч dev и dev-local. В dev-local есть коммит А в котором есть изменения конфига, коммиты B-C-D-... есть в обоих, добытые черри-пиком.
Но вообще дофига геморроя с непонятной целью. Конфигурации в принципе не место в том же месте файловой системы где лежит source tree или исполняемые файлы, как бы.
Основная проблема как раз во второй половине (про которую ты ничего не сказал что делать перед коммитом? Что делать, если есть локальные изменения в этом файле помимо тех, что должны быть реально локальными? У нас нет возможности "откатить" патч, чтобы получить оригинальный файл + изменения не в патче.
Вариант с update-index --assume-unchaged по крайней мере оставляет их в working copy, так что если ты обнаружил что они у тебя есть, ну, отлично, git stash --patch тру-локальные изменения, коммитишь остальное, накатываешь стеш обратно. Автоматический вариант с гитом или aufs молча переписывающими файлы нафиг как бы хуже.
Кстати! Я тут подумал! По идее же вроде cherry-pick позволяет делать такую штуку. Типа, у тебя есть бранч dev и dev-local. В dev-local есть коммит А в котором есть изменения конфига, коммиты B-C-D-... есть в обоих, добытые черри-пиком.
Но вообще дофига геморроя с непонятной целью. Конфигурации в принципе не место в том же месте файловой системы где лежит source tree или исполняемые файлы, как бы.
tl;dr
лучше этого не хотеть а сразу сделать нормально
например инклудить/использовать локальный конфиг или директорию с кусками конфига
лучше этого не хотеть а сразу сделать нормально
например инклудить/использовать локальный конфиг или директорию с кусками конфига
Я бы для этих целей воспользовался stgit. Локальные "коммиты" держать наверху стека и никогда не "коммитить" их в смысле полноценных коммитов. Все остальные изменения вставлять глубже по стеку, и переодически скидывать в нормальные коммиты и пушить.
Вобщем, еще одно извращение к уже перечисленному списку. А так правильно тебе сказали: "лучше этого не хотеть а сразу сделать нормально".
Вобщем, еще одно извращение к уже перечисленному списку. А так правильно тебе сказали: "лучше этого не хотеть а сразу сделать нормально".
1. Клонируешь проект в папку ${APath}/MyProjectкакое-то излишнее задротство на пустом месте.
2. Создаёшь папку ${APath}/ProjectOverlay
3. Открываешь файл из MyProject, правишь и сохраняешь под соответствующим именем в ProjectOverlay
4. Создаёшь папку ${APath}/WorkPatchSet
5. Записываешь в неё патч для получения одного конфига из другого.
6. Создаёшь там же скрипт для накатывания этого патча по необходимости, который выдаёт сообщение об ошибке, если патч не накатывается.
7. В .git/hooks прописываешь хук на апдейт, который вызывает скрипт из пункта 6.
8. При желании делаешь отдельный git проект для ${APath}/WorkPathSet, чтобы менеджить патчи и скрипты
9. Создаёшь папку ${APath}/WorkOverlay
10. Монтируешь через aufs в неё MyProject на rw, а поверх него ProjectOverlay на ro.
хорошая мысль про отдельный git для конфигов, но слабо представляю, когда такое нужно
man 5 gitattributes
/filter
http://www.kernel.org/pub/software/scm/git/docs/gitattribut...
Или с помощью кастомного diff-драйвера http://stackoverflow.com/a/10421385/1016033
/filter
http://www.kernel.org/pub/software/scm/git/docs/gitattribut...
Или с помощью кастомного diff-драйвера http://stackoverflow.com/a/10421385/1016033
ок, diff = nodiff это прикольно.
но фильтр как-то туго натягивается на этот случай,
только если хранить оригинальый файл и выставить clean = cat %f.orig
но фильтр как-то туго натягивается на этот случай,
только если хранить оригинальый файл и выставить clean = cat %f.orig
nodiff кажется просто не показывает изменения, но не препятствует их коммиту. Но ХЗ, я не проверял.
да, изменения коммитятся. git diff --stat тоже их видит.
filter.orig.clean = cat %f.orig работает как надо.
git checkout -f эти скрытые изменения продалбывает.
filter.orig.clean = cat %f.orig работает как надо.
git checkout -f эти скрытые изменения продалбывает.
гит бездонный!
гит как емакс, только гит!
Сальвадор Дали. Гит на емаксе без емакса. Репродукция.
имелось в виду, что в гите нет нормальной системы контроля версий?
Сальвадор Дали. Гит на емаксе без емакса. Репродукция.
Кандинский "Композиция Git"
а чем плох вариант завести поверх master свою ветку local со своими локальными правками и вносить свои правки в ветке поверх local, а перед пушем rebase-ить свои правки с local-а на master?
Заебёшься.
Типа, мы говорим о желании прописать sql connect string локально чтобы оно не попадало в репозиторий. Трудозатраты на поддержание этого средствами гита вместо хранения той херни там где правильно её хранить == "заебёшься".
Типа, мы говорим о желании прописать sql connect string локально чтобы оно не попадало в репозиторий. Трудозатраты на поддержание этого средствами гита вместо хранения той херни там где правильно её хранить == "заебёшься".
+1, надо бы подробнее. Какие конкретно команды вводить. Как сделать так, чтобы тот самый коммит не мешался под руками при ребейсе.
окей, а как тогда правильно раздавать изменения в файл конфигов?
Интересно, а можно сделать так, что для одной ветки файл untracked и в игноре (и не аплодится в орижн а для другой - трекается? При этом нет никаких конфликтов, в том плане, что попеременный чекаут из одной в другую ветку не удаляет файл в рабочей директории, где он соответствует последней зачекаученной версии из той ветки, которая этот файл содержит.
Разбить конфиг на config.user и config.default. Раздавать изменения только во втором.
Оставить комментарий
Serab
Допустим такая ситуация: подключился к разработке проекта, там некоторую конфигурацию надо поправить под себя, но пушить это не надо. Как наиболее логично это все завернуть? Т.е. чтобы моя dev-ветка локальная содержала коммит, который бы не мержился в мою видимую всем dev-ветку? Или что-то в этом духе.