git svn dcommit совершает неверный файл?

Question

Хорошо, у меня есть немного запутанная установка, где я использую git версии 1.7.9.5, и у меня есть git-репозиторий, который на стороне git является клоном голого репозитория; а на стороне svn должен быть клон удаленного репозитория SVN. С другой стороны, нет веток, и все сделано в мастере.

Удаленное хранилище некоторое время находилось в автономном режиме; он только что вернулся, и мне, похоже, удалось загрузить все оставшиеся коммиты через git svn dcommit,

Проблема в том, что я попытался сделать новое изменение / коммит после этого; и, казалось бы, dcommit хочет загрузить неправильный файл - и завершается неудачно с "Транзакция устарела"; Я видел, как восстановиться после нежелательного переименования с помощью git-svn: "Транзакция устарела", но, похоже, это не отвечает.

Настройка выглядит примерно так:

$ git config -l
svn-remote.svn.url=svn+ssh://user@myserver/remotepath/to/repo_svn
svn-remote.svn.fetch=:refs/remotes/git-svn
..
remote.origingit.url=file:///local/path/to/repo_bare.git
remote.origingit.fetch=+refs/heads/*:refs/remotes/origingit/*

Затем я вытащил из местного репо мерзавца:

$ git svn fetch
user@myserver's password: 
$ git pull --rebase origingit master
From file:///local/path/to/repo_bare
 * branch            master     -> FETCH_HEAD
Current branch master is up to date.

$ git status -uno
# On branch master
nothing to commit (use -u to show untracked files)

Я проверяю, есть ли разница с версией SVN:

# https://stackru.com/questions/2426654/git-svn-status-showing-changes-that-are-not-committed-to-svn

$ git diff git-svn HEAD
diff --git a/folder/file.tex b/folder/file.tex
index 7201cc7..3df14bc 100644
--- a/folder/file.tex
+++ b/folder/file.tex
@@ -299,7 +299,7 @@ Test


-%  test
+% test
 % still testing

$ git diff --name-status remotes/git-svn
M       folder/file.tex

... и есть - и это правильное изменение, в файле folder/file.tex; так что я пытаюсь нажать / загрузить это в SVN, используя dcommit:

$ git svn dcommit --verbose
Committing to svn+ssh://user@myserver/remotepath/to/repo_svn ...
user@myserver's password: 
    M   notes.txt
Transaction is out of date: File '/notes.txt' is out of date at /usr/lib/git-core/git-svn line 922

Теперь файл, который я ожидал загрузить ./folder/file.tex; пока git svn dcommit пытается загрузить ./notes.txt - который действительно существует, но в этом коммите не было изменений?!

Интересно, если я здесь сделаю

$ git svn rebase 
user@myserver's password: 
First, rewinding head to replay your work on top of it...
$ git diff --name-status remotes/git-svn
$ git svn dcommit 
Committing to svn+ssh://user@myserver/remotepath/to/repo_svn ...
$ 

... это если я git svn rebase вместо git svn fetch во-первых, тогда нет различий между git и svn, и поэтому я ничего не могу получить dcommitЭд (и поэтому я даже не получаю приглашение на ввод пароля). РЕДАКТИРОВАТЬ: обратите внимание, что если я делаю git pull --rebase origingit master после git svn rebaseто же, что и раньше (т.е. git diff --name-status видит правильное изменение, но git svn dcommit не удается с "транзакция устарела:")

Итак, мой вопрос - почему git svn dcommit настаивать на загрузке этого неправильного файла (в случае git svn fetch запускается первым) - вместо правильного файла, который в противном случае правильно сообщается git diff --name-status?? Как я могу это проверить?

И как я могу заставить git svn правильно синхронизировать локальные изменения git с удаленным SVN?

Answer 1

РЕДАКТИРОВАТЬ: нашел это: git-svn-id отсутствует в некоторых коммитах - и, кажется, это помогло; хитрость заключается в использовании fetch для обоих git svn а также git как описано там; а затем использовать cherry-pick для оставшихся коммитов, которые должны быть dcommitред; по-видимому, это дело с "застреванием" на 60-й версии из-за того, что эта ревизия была последней, git-svn-id:

---

Я получил где-то, но не решил это; но может частично ответить, почему этот неправильный файл зафиксирован.

После git svn rebase, Я имею:

$ git svn info
...
Revision: 446
...
Last Changed Rev: 446

git log --graph --decorate --pretty=oneline --abbrev-commit --all --date-order
* aaaa100 (HEAD, git-svn, master) : null edit - 
* aaaa099 : some more testing
* aaaa098 : some testing
* aaaa097 : just testing
...

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

После выполнения git pull --rebase origingit master, Я получил:

$ git svn info
...
Revision: 60
...
Last Changed Rev: 60

git log --graph --decorate --pretty=oneline --abbrev-commit --all --date-order | less

* aaaa100 (git-svn) : null edit - 
* aaaa099 : some more testing
...
* aaaa030 some early commit
* aaaa029 : early commit
* aaaa028 : old commit
| * bbbb101 (HEAD, master) : another null edit; previous attempt failed, 
| * bbbb100 : null edit - 
| * bbbb099 : some more testing
...

| * bbbb030 some early commit
| * bbbb029 : early commit
| * bbbb028 : old commit
* | aaaa027 : very old commit
| * bbbb027 : very old commit

Таким образом, здесь журнал более точный, так как он правильно отображает различия между журналами svn и git (т. Е. Svn и git чередуются снизу, когда сервер работал, а коммиты git и svn являются последовательными; затем происходит разрыв где коммиты являются последовательными из-за того, что сервер находится в автономном режиме) - и правильно показывает новую ревизию; НО по какой-то причине он также думает, что он находится на очень ранней версии SVN (60) - он хочет отправить файлы, которые были изменены в этой версии; поэтому, вероятно, причина неправильного файла. (хэши изменены для удобства чтения)

Я видел немного /usr/lib/git-core/git-svn - кажется, что он использует какие-то команды git для вычисления номера ревизии, но в данный момент не может получить гораздо больше от этого кода Perl.

Обратите внимание, что git pull без --rebase привело к этому:

$ git pull origingit master
From file:///local/path/to/repo_bare
 * branch            master     -> FETCH_HEAD
Auto-merging folder/file.tex
CONFLICT (add/add): Merge conflict in folder/file.tex
Automatic merge failed; fix conflicts and then commit the result.

Поэтому я посмотрел на Как обрабатывать / исправлять конфликты добавления / добавления git? и в итоге попробовал:

$ git pull --strategy=subtree origingit master
From file:///local/path/to/repo_bare
 * branch            master     -> FETCH_HEAD
Merge made by the 'subtree' strategy.
 folder/file.tex |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Это может выглядеть хорошо, но это не так - это не просто копировать bbbb101 another null edit; previous attempt failed совершить; на основе этого происходит слияние; так что теперь у меня есть:

$ git log --graph --decorate --pretty=oneline --abbrev-commit --all --date-order | less
*   9579e8b (HEAD, git-svn, master) Merge branch 'master' of file:///local/path/to/repo_bare
|\  
* | aaaa100 : null edit - 
...

что совершенно не то, что я хотел; и последующая попытка повторить процедуру не удалась с:

Applying: : second commit after git transition (first failed a bit)
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging notes.txt
CONFLICT (content): Merge conflict in notes.txt
Failed to merge in the changes.
Patch failed at 0001 : second commit after git transition (first failed a bit)

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

Итак, снова это вернулось к старой редакции SVN и вызвало беспорядок - ну, это то, чего я надеялся избежать, и не сделал; не уверен что делать сейчас...