2

好的，这是交易。
我在我的 Debian (lenny) 远程服务器上安装了 Git。Git版本有1.5.6.5。我打算将它用作远程共享/备份存储库。
我的开发机器正在运行 Windows，我的 Eclipse 和 EGit 就在其中。所以，这就是我所做的：

  • 为 git 创建共享用户。
  • 设置 SSH（在 Eclipse 和服务器上）、交换公钥等，一切顺利。
  • 我创建了远程仓库并使用git --bare init对其进行了初始化。
  • 在本地 repo 中创建项目，成功进行了一些更改和提交。
  • 将 master 分支从本地 repo 推送到远程 master。到现在为止还挺好。
  • （此外，在第三台机器上，我克隆了远程仓库（通过 EGit 导入），没有任何问题。）

当我从项目中删除几个文件时，“奇怪”的东西开始了，提交，然后尝试从远程拉，期望恢复已删除的项目，因为推送到远程的最后一个快照包含所有文件。由于pull本质上是fetch + merge，EGit 似乎有一些关于合并策略的已知问题。尽管如此，我还是配置了 fetch，从而产生了以下 fetch 规范： 

refs/heads/master:refs/remotes/amrtest1/master

Fetch 一切正常，至少看起来是这样，在本地 repo 中为远程 master 分支创建了新文件夹，我注意到 FETCH_HEAD 也在那里。
通过签出本地主分支，我尝试与远程主分支合并......结果是：

  • 本地删除的文件未恢复。
  • 在同步透视图中，我可以看到丢失的文件（在传出模式下？）
  • 在 EGit 的历史视图中，fetching 的动作按时间顺序在本地提交之前（删除文件之后），这肯定是不正确的。

我在这里做错了吗？根据所描述的过程，我对恢复状态的期望是否无效？如果是这样，该怎么做（恢复远程仓库的状态，或者至少将它与现有的本地正确合并）？

谢谢。

4

1 回答 1

2

Yes, your expectation is wrong. In fact it took several re-reads before I grasped that you believed Git would somehow psychically detect that you didn't want to delete the files which you had explicitly deleted and restore them during the merge operation. If you want the files back you ought to either revert the commit which removed them, or copy the files from the version where they existed into your current version.

On top of that, if you are correct about what you're calling the "history view of EGit" it probably means you've set pull to perform rebase instead of merge anyway. In rebase it's roughly assumed that your changes since the last pull should be applied as if against the current version of upstream. This is often cleaner for others to understand, but can be confusing or fail outright if many people are changing the same or related code in that time.

于 2012-06-15T10:13:03.390 回答