Проблема git-svn с git add --patch, приводящая к конфликтам

Question

В основном, когда я хочу совершить две отдельные изменения в том же файле, что и в результате операции git add --patch <file>, git svn rebase позже набрасывает 1-2 конфликта при поступлении второго при использовании git add для второго изменения.

поэтому я в основном делаю это (я на главной ветви и принес репозиторий SVN):

git checkout -b feature 
... make two unrelated changes to file test.txt... 
git add --patch test.txt 
... add first change but ignore second one 
git commit -m "change1" 
git stash 
git checkout master 
git merge feature 
git svn rebase 
git svn dcommit 
git checkout feature 
git stash apply 

Теперь здесь есть два способа сделать это, сначала один, который работает:

git add --patch test.txt 
... select everything (which is the second change in this case) 
git commit -m "change 2" 
git checkout master 
git merge feature 
git svn rebase 
git svn dcommit 

вот тот, который не работает:

git add test.txt #notice there's no --patch 
git commit -m "change 2" 
git checkout master 
git merge feature 
git svn rebase #yields a conflict 

Так почему же, что при использовании git add --patch для второго изменения, я могу передать в svn-репозиторий без проблем, но когда вы просто используете git add для второго изменения, это приводит к конфликту? Я новичок в git, так что это может быть глупый вопрос, но, как я вижу, обе команды должны делать то же самое.

Answer 1

Почему вы создаете ветку для своих двух коммитов, а затем сливаете назад? Я предполагаю, что это может привести к проблемам, поскольку слияния в git работают по-другому, чем они работают в svn.

это должно работать («должен», но я уверен, что он делает):

# on master, no need to create a branch 
$ git add -p file 
$ git commit -m "first set of changes" 
$ git add file 
$ git commit -m "the remaining changes" 
# apply your commit on top of eventually new changes upstream 
$ git svn rebase 
# commit your 2 commits to svn 
$ git svn dcommit 

---

в Svn ветвях только копии каталога (чаще всего каталога ствола), и слияния не отличаются от обычных коммитов (кроме нового свойства svn:mergeinfo, начинающегося с svn 1.6)

коммиты в git разные, каждая фиксация сохраняет ссылку на его родительский фиксатор. svn не нуждается в этом, так как он может просто использовать REV-1. merge commit in git, таким образом, имеют несколько родителей (объединяющая ветвь и объединенная ветвь)

Я не знаю, что произойдет, если вы dcommit git для svn, но скорее всего, это произойдет только с фиксацией слияния, без истории (сообщение что-то вроде «объединенной ветки« bla »в« master »).

при запуске svn commit только ваши новые изменения отправляются на сервер, чтобы сэкономить полосу пропускания. Теперь слияние в git работает по-разному, и разница в предыдущих версиях будет вероятно, не так, как вы ожидаете, поэтому git svn dcommit терпит неудачу.

он даже говорит об этом в документации git svn: не объединяйте ветви с помощью g это и dcommit их СВН, то, скорее всего, испортите свою историю

Запуск GIT слияния или GIT тянуть НЕ рекомендуется на ветке вы планируете dcommit с. Subversion не представляют собой слияния в любой разумной или полезной модой; поэтому пользователи, использующие Subversion, не видят слияния , которые вы сделали. Кроме того, если вы объедините или вытащите из ветки git, которая является зеркалом ветви SVN, dcommit может совершить неправильную ветку. git svn docs