Разрешение мерзавца конфликты Svn

Я пробовал это с (n по общему признанию небольшим) конфликтом, который я принудил, и после git svn dcommit У меня больше не было конфликтов. Разница лишь в том, что я не получил сообщение о git add . Возможно ли, что ваша команда просто посылает много коммитов, которые конфликтуют с вашей работой? Это кажется маловероятным, но, похоже, это самое простое объяснение.

Возможно, стоит потратить время на то, чтобы снова поставить репо в другое место и проверить, можете ли вы вносить неконфликтные изменения, чтобы убедиться, что во время [не возникает проблем со связью. 1115176] dcommit этап, который каким-то образом скрыт.

ОБНОВЛЕНИЕ: Еще одна мысль, которая у меня возникла: я сделал git add foo.bar , когда закончил разрешать конфликт. Возможно ли, что git add. делает что-то неожиданное? Я не сильно расширяю возможности git svn , так что это в значительной степени WAG.

Кажется, что-то работает не так, как вы думаете. Если это не маловероятные вещи, которые предложил Хэнк Гей, то это еще одна невероятная вещь.

Моя маловероятная возможность состоит в том, что ваша структура ветки не та, о которой вы думаете, или вы не перебираете ветку, как вы думаете. Поэтому я предлагаю вам:

1. git branch просто для того, чтобы подтвердить, что ваша структура ветвей - это то, что вы ожидаете

2. Добавить
   export PS1 = '\ e [0; 31m \ n \ w $ (__ git_ps1 "( % s) ") $ \ e [m '
   to ~ / .bash_profile и войдите снова,
   чтобы показать ветку (и любую внутрипроцессную команду git) в вашем приглашении:

   / workspace / wikka (featurebranch1 | REBASE-i) $

Это даст вам больше отзывов (и, возможно, исключит эту WAG как возможность ).

Я бы порекомендовал использовать git-svn только между вашей локальной транковой и удаленной ствол . Между вашим локальным транком и локальным mytrunk придерживайтесь стандартных функций git only. Возможно, вы могли бы попробовать такой рабочий процесс:

[SVN]---git-svn---[trunk]---branch---[mytrunk]

Чтобы объединить, переключитесь на trunk и выполните:

git svn rebase

Это извлекает изменения из пульта и объединяет его с trunk , Затем переключитесь на mytrunk и выполните:

git rebase

Это извлекает изменения из trunk и объединяет его с mytrunk . Я думаю, что это должно работать. В противном случае, просто git-клонировать локальный ствол и вместо этого работать с клоном.

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

Вот как я попал в эту ситуацию.

У меня есть репозиторий git через git svn, используя Apache инфраструктура.

У меня есть локальный филиал.

Я пытаюсь выполнить следующую процедуру:

1) перебазировать магистраль. 2) объединить транк в частную ветку. 3) делай работу. 4) перебазировать багажник. 5) слить частное в транк. 6) dcommit.

Однако я напортачил и забыл передать изменение с частного на магистральный. Затем я внес ряд других изменений в свою частную ветку и попал в цикл «промыть и повторить» из-за полностью ложного конфликта. Последнее изменение, которое я внес, заключалось в закомментировании одной строки. Когда я затем удалил эту строку в забытом изменении, возник конфликт, который не разрешился, несмотря ни на что. В конце концов я использовал - пропустить.