Я использую git-svn
работать с репозиторием SVN. Мои рабочие копии были созданы с помощью git svn clone -s http://foo.bar/myproject
так, чтобы моя рабочая копия следовала схеме каталога по умолчанию SVN (соединительная линия, теги, ответвления).
Недавно я работал над ответвлением, которое было создано с помощью git-svn branch myremotebranch
и проверил использование git checkout --track -b mybranch myremotebranch
. Я должен был работать от нескольких местоположений, таким образом, от ответвления I git-svn dcommit
- файлы редактора к репозиторию SVN вполне регулярно.
После окончания моих изменений я переключился назад на ведущее устройство и выполнил слияние, фиксировал слияние и попробовал к dcommit успешное слияние к удаленной соединительной линии.
Кажется, как будто после слияния удаленное отслеживание для ведущего устройства переключилось на ответвление, я продолжал работать:
# git checkout master
# git merge mybranch
... (successful)
# git add .
# git commit -m '...'
# git svn dcommit
Committing to http://foo.bar/myproject/branches/myremotebranch ...
#
Есть ли способ, которым я могу обновить ведущее устройство так, чтобы он следовал remotes/trunk
как перед слиянием?
Я использую мерзавца 1.7.0.5, если это - какая-либо справка.
Было бы полезно, если Вы могли бы также объяснить, почему это произошло, таким образом, я могу избежать проблемы, происходящей снова.Спасибо!
Править:
Вот мой ток .git/config
:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
autocrlf = false
[svn-remote "svn"]
url = http://foo.bar/myproject
fetch = trunk:refs/remotes/trunk
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
[branch "mybranch"]
remote = .
merge = refs/remotes/myremotebranch
Таким образом, кажется, что соединительная линия указывает на корректное место. Однако переключение на ответвление затем обратно ведущему устройству не помогает; git svn dcommit
в ведущем устройстве все еще пытается продвинуть к myremotebranch
.
Когда в стволе нет изменений, git выполняет быстрое слияние и просто устанавливает локальную «главную» ветвь на фиксацию в вашей ветке. Git-svn не знает, как фиксировать слияния с быстрой перемоткой назад в ствол, на самом деле он думает, что "master" теперь указывает на ветку svn.
Чтобы обойти это, используйте git merge --no-ff
при слиянии. Это заставит git создать коммит слияния, который затем можно будет передать svn.
Если вы еще не сделали никаких коммитов на главном сервере, это означает, что git merge mybranch
был перемоткой вперед: master HEAD
просто переместите к mybranch HEAD
.
Это может объяснить, почему git svn dcommit
перенес ваши изменения в SVN mybranch
.
Он должен:
mybranch
, еще не зафиксированными, Я не думаю, что мастер не менял свою ссылку, но если у вас есть сомнения (и ваш рабочий каталог чист), вы можете (если мастер в настоящее время извлечен):
git reset --hard remotes/trunk
В общем, вы не должны использовать git merge
с git svn
, потому что svn, даже с ветвями, не поддерживает такой вид слияния отслеживание того, что делает git. Когда вам нужно объединить ветку, я добился наибольшего успеха (по крайней мере, с недавним svn), выполнив простой процесс проверки / слияния svn, а затем использовал git svn rebase
для обновления моих репозиториев git-svn. Это сохраняет собственные метаданные svn для отслеживания слияния, которые (AFAIK) git-svn
полностью игнорирует.
Я не совсем уверен, в каком состоянии находится ваш svn-репозиторий - я бы проверил, чтобы dcommit слияния выполнял то, что вы хотели, в магистрали. Даже если бы это было так,
Готов поспорить, если вы посмотрите содержимое файлов refs / Heads / master
и refs / remotes / trunk
в вашем репозитории, то увидите, что они сейчас разные . Если это так, я бы (без локальных изменений) сделал бы git-svn fetch
, а затем git branch -f master remotes / trunk; git reset --hard master
для повторной синхронизации ветки git с веткой отслеживания git-svn.Если у вас есть локальные изменения, вам нужно будет выполнить фиксацию и сделать что-то вроде git rebase master ^ 4 --onto remotes / trunk
, где 4 - количество коммитов, которые необходимо сохранить. В качестве альтернативы, если все они не зафиксированы, сначала спрячьте их с помощью git stash
.
В противном случае вы всегда можете получить все в svn и просто стереть репо и получить новую проверку.