Поддерживать множество локальных коммитов, работающих с git-svn

Question

Я использую git для разработки проекта, размещенного в Subversion, используя git-svn:

git svn clone svn://project/

Мой общий рабочий процесс состоял в том, чтобы многократно редактировать и фиксировать в основной ветке, а затем фиксировать в хранилище svn через:

git stash
git svn dcommit
git stash apply

Одной из локальных модификаций, которые сохраняет команда 'stash', которую я не хочу фиксировать в репозитории svn, является измененная строка подключения к базе данных. Какой самый удобный способ сохранить это локальное изменение без лишних шагов «тайника»?

Я подозреваю, что что-то вроде "тайника" или "стеганого одеяла" - это то, что я ищу, но я все еще достаточно нов, чтобы думать, что мне не хватает какой-то терминологии, которая привела бы к точному заклинанию. 1009 *

Обновление : Единственное найденное мной решение, которое, похоже, позволяет избежать серии git stash + git-svn action + git stash apply, - это обновление ссылки git-svn вручную:

(check in local-only change to 'master', then...)
$ cat .git/refs/master > .git/refs/remote/git-svn
$ git svn fetch (with at least one new SVN revision)

И это делает локальный коммит странным (вероятно, небезопасным) коммитом между двумя svn-ревизиями.

Answer 1

Один из возможных подходов состоит в том, чтобы иметь «локальную» ветвь с локальными изменениями и отделять от нее «рабочую» ветвь. В этой настройке вы можете:

git checkout work
git checkout -b work_tmp
git rebase --onto master local work_tmp
git checkout master
git merge work_tmp
git branch -D work_tmp
git svn dcommit master

(и, естественно, создайте для него скрипт оболочки)

Я только начал использовать это в проекте, и у этого метода могут быть недостатки.

Answer 2

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

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

Answer 3

Я использую stg (стеганый, но интегрированный с git) вместе с git svn.

У меня есть исправления в stg, которые исправляют систему сборки так, что я не хочу отправлять их в апстрим - так что это похоже на ваш патч в БД.

Чтобы применить патчи:

stg pop -a stg push patch-name-name-i-want-to-apply git svn dcommit

или перебазировать против последнего SVN:

git svn fetch stg rebase trunk (или как называется ваша ветка svn)

Answer 4

Не совсем хороший ответ на ваш вопрос, но, тем не менее, полезен:

В кругах django общепринятым является включение соединений с базой данных и т. Д. В локальный файл, который отсутствует в репозитории и называется localsettings.py

Этот файл уникален для каждой среды, в которой вы развертываете; Это помогает включить файл примера в репозиторий, скажем, localsettings.py.example

В противном случае включите все файлы конфигурации репозитория и внедрите инфраструктуру для запроса соответствующих файлов на основе имени хоста.