Почему смысл "наших" и "их" отменяется с помощью git -svn

Ответ 1

Это похоже на то, что делает rebase.

• git svn rebase будет получать ревизии от родителя SVN текущего HEAD и восстанавливает текущую (незадействованную SVN) работу против он.

• git rebase упоминает:
  Обратите внимание, что слияние ребай работает, переигрывая каждую фиксацию из рабочей ветки поверх ветки <upstream>.
  Из-за этого, когда происходит конфликт слиянием:

  • Сторона, указанная как наша, представляет собой так называемую перевыпущенную серию, начиная с <upstream>,
  • , а их - рабочая ветвь.
    Другими словами, стороны обмениваются.

git rebase повторяет каждую фиксацию из рабочей ветки поверх ветки <upstream>.

Если вы согласовываете оба определения:

• Котировки, исходящие из SVN, - это те, на вершинах которых локальные компиляции Git воспроизводятся. Они являются частью серии "so-far rebased" и называются "нашими" (в вашем случае, файл test.txt с содержимым bar)
• рабочая ветка (содержащая Git фиксирует неизвестный SVN, в вашем случае, файл test.txt с содержимым baz) является "их" , и каждая из этих локальных коммитов Git воспроизводится.

Другими словами, SVN или нет:

• ветвь "<upstream>" (поверх которой все что-либо воспроизводится и которая является частью так называемых сокращенных коммитов) " наша".
• то, что воспроизводится (рабочая ветвь), их.

Хороший мнемонический совет от CommaToast:

любой HEAD, указывающий на "наш"

(и, прежде всего, git rebase upstream выполняет проверку ветки upstream, поверх которой вы хотите переустановить: HEAD теперь относится к upstream - ours.)

Путаница, скорее всего, происходит от роли рабочей ветки в классическом git merge.
Когда вы объединяетесь:

• "рабочая ветвь" - это та, которая содержит "до сих пор объединенную" и считается "нашей" ,
• в то время как другой фиксатор представляет то, что есть - не воспроизводится, а - сливается поверх рабочей ветки и считается "их" .

Как упоминается страница man git rebase, слияние во время переустановки означает, что сторона обменивается.

Еще один способ сказать то же самое - подумать, что:

• то, что у нас есть на проверенной ветке, наш,
• то, что у нас было (и оно сливается или переигрывается) - это их.

При слиянии:

x--x--x--x--x(*) <- current branch B ('*'=HEAD)
    \
     \
      \--y--y--y <- other branch to merge

мы не меняем текущую ветвь "B", поэтому то, что мы имеем, - это то, над чем мы работали (и мы сливаемся с другой ветвью)

x--x--x--x--x---------o(*)  MERGE, still on branch B
    \       ^        /
     \     ours     /
      \            /
       --y--y--y--/  
               ^
              their

Но на rebase, мы переключаем сторону, потому что первое, что нужно сделать, это проверка ветки upstream! (чтобы воспроизвести текущий ток на вершине)

x--x--x--x--x(*) <- current branch B
    \
     \
      \--y--y--y <- upstream branch

A git rebase upstream сначала изменит HEAD B на ветвь вверх по течению HEAD (следовательно, переключатель 'ours' и 'theirs' по сравнению с предыдущей "текущей" рабочей ветвью.)

x--x--x--x--x <- former "current" branch, new "theirs"
    \
     \
      \--y--y--y(*) <- upstream branch with B reset on it,  
                       new "ours", to replay x on it

а затем rebase будет воспроизводить "свои" фиксации в новой "нашей" ветки B:

x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
    \
     \
      \--y--y--y--x'--x'--x'(*) <-  branch B with HEAD updated ("ours")
               ^
               |
        upstream branch

Единственный дополнительный шаг с git svn rebase заключается в том, что svn "fetch" выполняется сначала на удаленной ветке Git, представляющей записи SVN.
Вы изначально:

x--x--x--x--x(*) <- current branch B, "ours" for now.
    \                                   
     \
      \--y--y--y <- SVN tracking branch, "theirs for now"

вы сначала обновляете ветвь отслеживания SVN с новыми коммитами, поступающими из SVN

x--x--x--x--x(*) <- current branch B, still "ours", not for long
    \                                   
     \
      \--y--y--y--y'--y' <- SVN tracking branch updated

то вы переключите текущую ветвь на сторону SVN (которая становится "нашей" )

x--x--x--x--x <- for "B", now "their" during the rebase
    \                                   
     \
      \--y--y--y--y'--y'(*) <- SVN tracking branch updated, and branch B: 
                               now "ours" (this is "what we now have")

перед воспроизведением коммитов, над которыми вы работали (но которые теперь являются "их" во время этой перезагрузки)

x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
    \
     \
      \--y--y--y--y'--y'--x'--x'--x'(*) <-  branch B with HEAD updated ("ours")
                      ^
                      |
        upstream SVN tracking branch