git svn dcommit提交错误的文件? [英] git svn dcommit committing wrong file?

查看:65
本文介绍了git svn dcommit提交错误的文件?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

好吧,我有一个复杂的设置,在这里我使用git版本1.7.9.5,并且有一个git存储库,在git方面是裸仓库的克隆.并且在svn端,应该是远程SVN信息库的克隆.另一方面,没有分支,一切都在master中完成.

Ok, I have a bit of a convoluted setup, where I use git version 1.7.9.5, and have a git repository, which on the git side is a clone of a bare repo; and on the svn side, should be a clone of a remote SVN repository. On the other hand, there are no branches, and everything is done in master.

远程存储库离线了一段时间;它刚回来,我似乎设法通过git svn dcommit上传了所有未完成的提交.

The remote repository was offline for a while; it just came back, and I seemingly managed to upload all outstanding commits via git svn dcommit.

现在的问题是,我尝试在此之后进行新的更改/提交;似乎dcommit要上传错误的文件-失败并显示交易过期";我看到了如何使用git-svn从不需要的重命名中恢复:交易已过期" ,但这似乎无法解决这个问题.

The problem is now, I tried making a new change/commit after this; and seemingly dcommit wants to upload the wrong file - and fails with 'Transaction out of date'; I saw How to recover from an unwanted rename using git-svn: "Transaction is out of date", but that doesn't seem to answer this.

设置有点像这样:

$ 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中提取信息:

Then I pull from the local bare repo git:

$ 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版本有所不同:

I check to see if there is a difference from the SVN version:

# 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中有-并且这是正确的更改;所以我正在尝试使用dcommit:

... and there is - and it is the right change, in the file folder/file.tex; so I'm trying to push/upload that to svn using 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-确实存在,但是在此提交中没有对其进行任何更改吗?!

Now, the file I expected to be uploaded is ./folder/file.tex; yet git svn dcommit tries to upload ./notes.txt - which indeed, does exist, but there haven't been changes to it in this commit?!

有趣的是,如果我在这里这样做:

Interestingly, if I do here:

$ 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 ed(所以我甚至都没有提示输入密码).请注意,如果我在git svn rebase之后执行git pull --rebase origingit master,则与以前相同(即git diff --name-status看到正确的更改,但git svn dcommit失败并显示交易已过期:")

... that is if I do git svn rebase instead of git svn fetch first, then there are no differences recognized between the git side and the svn side, and thus I can get nothing dcommited (and so I don't even get a password prompt). note that if I do git pull --rebase origingit master after the git svn rebase, the same as before happens (i.e. git diff --name-status sees the right change, but git svn dcommit fails with "Transaction is out of date:")

所以我的问题是-为什么git svn dcommit坚持要上载这个错误的文件(如果先运行git svn fetch)-而不是正确的文件,否则该文件将由git diff --name-status正确报告?我该如何检查?

So my question is - why does git svn dcommit insist on uploading this wrong file (in case git svn fetch is ran first) - instead of the right file, which is otherwise correctly reported by git diff --name-status ?? How can I inspect that?

又如何强制git svn正确将本地git更改同步到远程SVN?

And how can I force git svn to correctly synchronize the local git changes to the remote SVN?

推荐答案

发现以下内容:git-svn-id:

found this: git-svn-id is missing from some commits - and it seems it helped; the trick is to use fetch for both git svn and git as described there; and then use cherry-pick for leftover commits that need to be dcommited; apparently this business with being "stuck" at rev 60 is due to that revision being the last that had a proper git-svn-id:

我到了某个地方,但是没有解决.但可能会部分回答为什么提交了错误的文件.

I got somewhere, but didn't solve it; but may answer partially why is that wrong file committed.

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),并且日志基本上始终显示直线"行.

Note that revision is the latest (446) here, and the log basically shows a "straight" line all the way through.

做完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)-使其希望发送在该版本中修改过的文件;因此可能是文件错误的原因. (为便于阅读而对哈希进行了更改)

So here, the log is more accurate, as it visualizes the differences between the svn and the git logs properly (i.e. svn and git are interleaved at bottom, when server was working, and git and svn commits are consecutive; then there is a break where commits are sequential due to server being offline) - and correctly shows the new revision; BUT for some reason it also thinks it is at a very early SVN revision (60) - making it want to send the files which were modified in that revision; so probably the reason for the wrong file. (hashes are changed for readability)

我看到了一点/usr/lib/git-core/git-svn-似乎它使用某种git命令来计算修订版本号,但目前无法从该Perl代码中获得更多信息.

I saw a bit /usr/lib/git-core/git-svn - it seems that it uses some sort of git commands to calculate the revision number, but cannot get much more out of that Perl code at the moment.

请注意,没有--rebasegit pull是这样产生的:

Note that git pull without --rebase resulted with this:

$ 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 add/add冲突?,并最终尝试:

So I looked into How to handle/fix git add/add conflicts?, and ultimately tried:

$ 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提交;它基于它进行合并;所以现在我有:

This might look ok, but it isn't - it doesn't just copy the bbbb101 another null edit; previous attempt failed commit; it makes a merge based on it; so now I have:

$ 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 - 
...

这绝对不是我想要的;并且随后的重复该过程的尝试失败了:

which is absolutely not what I wanted; and the subsequent attempt to repeat the procedure failed with:

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版本,并造成了混乱.不知道现在该怎么办...

So again it reverted to the old SVN revision, and caused a mess - well, this is what I hoped I'd avoid, and didn't; not sure what to do now ...

这篇关于git svn dcommit提交错误的文件?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆