git-svn: сброс трекинга для мастера

Question

Я использую 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 довольно регулярно.

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

Кажется, что после слияния удаленное отслеживание для мастера переключилось на ветку, над которой я работал:

# 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, как до слияния?

Я использую git 1.7.0.5, если это поможет.

Было бы полезно, если бы вы также могли объяснить , почему это произошло, поэтому я могу избежать повторения этой проблемы. Спасибо!

Edit:

Вот мой текущий .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.

Answer 1

Когда в транке нет изменений, git выполняет быстрое слияние и просто устанавливает локальную «основную» ветвь для коммита в вашей ветке. Git-svn не знает, как выполнить быстрое слияние назад в транк, фактически он думает, что «master» теперь указывает на ветку svn.

Чтобы обойти это, используйте git merge --no-ff при объединении. Это заставит git создать коммит слияния, который затем может быть передан svn.

Answer 2

Если вы git svn rebase после переключения обратно на мастер и используете --squash, вы можете избежать этого.

# git checkout master
# git svn rebase   //(<--the missing step)
# git merge --squash mybranch // (<-- doesn't commit, more like an svn merge would do)
... (successful)
# git add . 
# git commit -m '...' 
# git svn dcommit
Committing to http://foo.bar/myproject/trunk...
#

Чтобы решить текущее состояние (т. Е. Ваш мастер указывает на ветку SVN)

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

# git checkout mybranch
# git branch -D master
# git checkout -b master trunk
... continue with merge...
# git merge --squash mybranch

... теперь у вас есть mybranch, объединенный с master и готовый к commit, а затем dcommit к trunk

Answer 3

Если вы не сделали никакого коммита на мастере, это означает, что git merge mybranch был ускоренным: master HEAD просто перейдите на mybranch HEAD.

Это может объяснить, почему git svn dcommit подтолкнул ваши изменения к SVN mybranch.
Было бы:

• сначала обновите соответствующую ветку SVN с помощью последнего коммита Git mybranch, который еще не dcommitted,
• записать слияние с транком на стороне SVN
• и тогда он будет перебазировать мастера на стороне Git (ничего не делать, уже там).

Я не думаю, что master не изменил свою ссылку, но если у вас есть сомнения (и ваш рабочий каталог чист), вы можете (если master в настоящее время извлечен):

git reset --hard remotes/trunk

Answer 4

В общем, вы не должны использовать 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, просто стереть репо и получить новую кассу.

Answer 5

Мы успешно использовали git merge --squash в разработке веток git-svn. Проблема с git-svn заключается в том, что, хотя ваш локальный клон git-svn может хранить информацию о слиянии, после того, как вы отправите его в репозиторий svn, он потерян.

Так что для других пользователей (git-) svn коммиты слияния выглядят как обычные коммиты. Сквош хорош для того же, что и git merge --no-ff (например, создание коммита слияния на master), но он также включает в себя список фактических коммитов, сделанных в сливаемой ветви, которые в противном случае были бы потеряны при dcommitting.

Answer 6

У меня была такая же проблема, и я слил пульты / транк обратно в мастер, после чего git svn info указал на транк

У меня не было времени, чтобы активировать dcommit, когда я выходил из проекта, и мое git-svn repo умерло с моим похищением Я попробовал dcommit --dry-run, и он сказал, что он вернется к транку.

Я воспроизведу настройки и протестирую, когда получу время

ура