С "git svn" можно ли игнорировать определенные Git-коммиты при получении? - PullRequest
7 голосов
/ 15 сентября 2011

Я использую git svn на моей локальной машине для синхронизации с репозиторием SVN.

Недавно кто-то из моей команды добавил некоторые экспериментальные вещи (он пытался добавить несколько тегов) в репозиторий SVN иудалил его позже в следующем коммите.После этого мой мерзавец svn отказывается скачивать.Он просто достигает определенной точки и остается там застрявшим.

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

Ответы [ 4 ]

12 голосов
/ 18 июня 2012

Скажите, что коммит 666 - это тот, который нам нужно пропустить. Хитрость заключается в том, чтобы git получить всех коммитов, кроме 666 . К счастью, git-svn дает нам аргумент -r.

Сначала обновите коммит непосредственно перед пропуском коммита:

git svn fetch -r BASE:665

Затем обновите все после плохой фиксации в подсказке Subversion:

git svn fetch -r 667:HEAD

Это должно дать вам хранилище со всем, кроме коммита, который вы хотите пропустить. При необходимости вы можете пропустить несколько ревизий, просто повторите приведенные выше команды для любого диапазона (-ов) коммитов, которые вы хотите сохранить.

Пропуск ревизий может пойти наперекосяк, если вы пропустите изменения файла, на которые повлияют более поздние ревизии (например, вы пропустите изменение или создание файла, и этот файл будет изменен позже в ревизии, которую вы извлекаете).

Тем не менее, я только что сделал это, чтобы пропустить ревизию, в которой кто-то скопировал весь репозиторий Subversion в каталог tags/, а затем удалил явно недействительный тег. Я использовал вышеописанный трюк, чтобы пропустить ревизию, в которой был создан недействительный тег (Git пытался загрузить весь репозиторий), позволить ему извлечь удаление (которое он просто проигнорировал), и все было в порядке с миром.

3 голосов
/ 21 сентября 2011

Вы можете попытаться сбросить git-svn прямо перед экспериментальной фиксацией и повторно получить.

git svn reset -r665
git svn fetch 

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

Первый сброс до последнего коммита перед злым

git svn reset -r665

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

git svn fetch --ignore-paths='/path/to/problematic/files'

Затем вернитесь к первому нормальному коммиту после коммита, который вернул злого.

git svn reset -r668

И все заново.

git svn fetch

Я полагаю, что r666 - это злой коммит, а r667 - тот, который изменил его.

0 голосов
/ 17 декабря 2014

У меня была такая же проблема, я обнаружил, что должен продолжать повторять выборку. Но потом я обнаружил, что другие фоновые операции git svn fetch выполнялись в фоновом режиме. Убийство этих, казалось, решило проблему

0 голосов
/ 15 сентября 2011

Вы можете снова клонировать хранилище и использовать параметр глубины, чтобы указать возраст ...

git clone --depth 3 // Gets the last 3 revisions
...