Как к dcommit только выбрал патчи с мерзавцем svn?
Эти две внутренние характеристики сообщают о различных типах времени. system_clock сообщает "время стены" или истекшее время. cpu_time сообщает время, используемое процессором. На многозадачной машине они могут сильно отличаться, например, если ваш процесс совместно использует ЦП в равной степени с тремя другими процессами и, следовательно, получает 25% ЦП и использует 10 процессорных секунд, это займет около 40 секунд фактического истечения времени или времени ожидания. время на часах.
3 ответа
Вот что я в итоге сделал. Отправной точкой является "главная" ветка, синхронизированная с svn, со всеми моими локальными исправлениями наверху.
Создайте новую ветку (wip = Work In Progress).
git branch wipЭто создает копию текущей ветки, включая все исправления, еще не зафиксированные в svn. Текущая ветка останется «главной» и не будет изменена.
Удалите нежелательные локальные исправления из «мастера» с помощью rebase:
git rebase -i HEAD ~ 10Теперь в ветке master есть исправления, которые вы можете безопасно зафиксировать:
git svn dcommitВетвь "wip" теперь содержит основные изменения, которые еще не готовы к публикации. На самом деле, я хочу, чтобы они там остались, и здесь я бы остановился . После того, как все будет завершено, можно выполнить команду svn dcommit из ветки "wip". Но для полноты картины и ответа на исходный вопрос есть последний шаг:
Вытяните незафиксированные изменения обратно в «главную» ветку с помощью
git cherry-pickи, наконец, удалите бесполезную ветку с помощьюgit branch -d wip.
С git вы фактически не должны работать с отдельными наборами изменений. Лучший из известных мне подходов - это создание локальных веток для любой нетривиальной работы. Таким образом, ваши непроверенные основные изменения попадут в разные ветки вашего репозитория git, и вы сможете довольно легко их различать.
Если это проблема, с которой вы сталкиваетесь в данный момент, вы, вероятно, можете создать новый ветку с момента последнего обновления из svn, а затем используйте git-cherry-pick , чтобы перенести ваши простые исправления ошибок в эту новую ветку, из которой затем вы можете dcommit в svn.
Из более длинного С точки зрения -term лучше всего иметь свою собственную "главную" ветку, созданную из транка subversion, а затем либо:
- Перебазировать все свои ветки каждый раз, когда вы обновляетесь из svn, затем слейте те, которые вы хотите получить в svn, со своим мастером и dcommit оттуда.
- Слейте данные из svn с помощью обычного git-merge , а затем слейте данные со своим мастером для dcommit с помощью
git diff ..my_branch | patch -p1, который удалит историю, которую git-svn не может обработать. Этот подход более сложен для окончательного слияния, но позволяет вам объединять данные между ветвями (и, возможно, другими людьми) в самом git.
Я следовал процедуре, описанной здесь:
http://fredericiana.com/2009/12/31/partial-svn-dcommit-with-git/
Если вам удобно делать ребазинг, это работает довольно хорошо.