Git -svn clone | ложные ветки

Ответ 1

TL;DR:

git svn создает эти ветки "@" , если для подкаталога была создана ветвь (или тег) (или для другого каталога, который не отслеживается git -svn). Всегда будет также "регулярная" ветвь с тем же именем, но без суффикса "@" . "@" - ветвь существует только как ветвящаяся точка для регулярной ветки.

Примечание. Я отправил патч для этого; отредактированная версия этого объяснения теперь является частью официальной git svn manpage, как новый раздел "ОБРАБОТКА СВИНОВЫХ ФИЛИАЛ" (начиная с Git 1.8.1).

В Subversion ветки и теги - это всего лишь копии дерева каталогов, поэтому возможно (хотя обычно не рекомендуется) создавать ветку из каталога, который сам по себе не является ветвью (или магистралью). Например, путем копирования /trunk/foo в/branch/bar вместо копирования /trunk (так называемая ветка подкаталога) или путем копирования каталога, который находится за пределами структуры соединительных линий/тегов/ветвей (что является возможно в SVN).

В git, однако, ветвь всегда для всего репо, ветки подкаталога не существуют. git svn поэтому использует обходное решение. Если он обнаруживает ветвь, которая была скопирована из каталога, который сам по себе не отслеживается как ветвь на git -svn, он создаст новую историю. Например, для ветки подкаталога, где /trunk/foo копируется в /branch/bar в r1234, создается:

• Новый Git фиксация для каждой ревизии SVN из r1233 в обратном порядке (обратите внимание, что номер является последней ревизией до создания ветки). Деревья этих коммитов будут содержать только подкаталог, который был разветвлен. Таким образом, для каждой ревизии от r1233 в обратном направлении обычно будет две коммиляции Git, одна с целым деревом (созданная, когда git -svn обработала историю trunk), и новые.
• Фиктивная ветка, называемая "bar @1233" (название ветки @revision), которая указывает на фиксацию, созданную с r1233 выше.
• Передача из r1234, фиксация, которая создала ветвь. Эта фиксация будет иметь ветвь выше как ее (только) предка.
• От ветки, называемой "бар", которая указывает на вторую фиксацию.

Таким образом, для панели ветки подкаталога вы получаете две ветки в git

• bar @1233, который представляет состояние репозитория, созданного веткой из
• который представляет ветвь

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

Обратите внимание, что весь этот механизм можно отключить, используя флаг --no-follow-parent. В этом случае каждый ветвь SVN приведет к ветки Git с только коммитами из каталога ветвей SVN. Каждая ветвь будет неразвязана с остальной частью истории и будет иметь свой собственный корневой фиксатор, соответствующий первой фиксации в ветке.

Ответ 2

У меня были такие странно называемые ветки, когда я клонировал свое SVN-репо в репозиторий Git.

После просмотра ожидаемых ветвей (в вашем случае modules-1.2, abc-1.3.x, branch_test_script и release-1.1) я заметил, что ветки @revisionnumber - это не что иное, как фиксация в своих префиксах.

Если вы хотите сделать это вручную, откройте gitk на ветке abc-1.3.x и убедитесь, что [email protected] и [email protected] отображаются в истории этой ветки. Если это так, вы можете удалить соответствующую ветку.

Это может быть немного громоздким, если у вас есть много веток или много коммитов для просмотра.

Автоматический путь: попросите Git сделать это для вас:

git branch -r --contains [email protected]

будет эхо (или, по крайней мере, должен)

abc-1.3.x
[email protected]
[email protected]

Это означает, что вы можете безопасно удалить [email protected], потому что он содержится в abc-1.3.x:

git branch -r -d [email protected]

Из-за линейной истории SVN он, конечно же, также содержит (newer) commit 541512.

Боковое примечание:
Возможно, вы заметили, что ваши теги SVN фактически не конвертируются в теги Git и родные ветки Git. Это может быть достигнуто с помощью svn2git, чтобы клонировать репо SVN в репозиторий Git.