2015-03-13 4 views
0

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

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

Проблема в том, что я попытался сделать новое изменение/совершить после этого; и, по-видимому, dcommit хочет загрузить неправильный файл - и с ошибкой «Transaction out of date»; Я видел How to recover from an unwanted rename using git-svn: "Transaction is out of date", но это, похоже, не отвечает на это.

Установка несколько походит на это:

$ git config -l 
svn-remote.svn.url=svn+ssh://[email protected]/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 
[email protected]'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://stackoverflow.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://[email protected]/remotepath/to/repo_svn ... 
[email protected]'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 
[email protected]'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://[email protected]/remotepath/to/repo_svn ... 
$ 

... то есть, если я git svn rebase вместо git svn fetch первых, то нет разницы, признанной между стороной мерзавца и боковой СВН, и, таким образом, я ничего не может получить dcommit ed (и поэтому я даже не получаю приглашение пароля). EDIT: обратите внимание, что, если я 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?

ответ

0

EDIT: найдено: git-svn-id is missing from some commits - и, похоже, это помогло; трюк заключается в использовании fetch для обоих git svn и git, как описано здесь; а затем использовать cherry-pick для остаточных коммитов, которые должны быть dcommit ed; по-видимому, это дело с бытием «застревают» в оборот 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 

Так вот, журнал является более точным, так как она визуализирует различия между СВН и журналов 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. 

Так что я посмотрел в How to handle/fix git add/add conflicts?, и в конечном счете пробовал:

$ 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, и вызвало беспорядок - ну, это то, что я надеялся, что я бы избежать, и нет; не уверен, что теперь делать ...

 Смежные вопросы

  • Нет связанных вопросов^_^