如何应对集市未承诺
今天多次遇到以下情况：
- 我自己和另一个开发人员都对存储库进行了集市本地签出。
- 我做了一些改变。
- 其他开发人员进行并提交了一些更改。
- 我更新。
- 另一个开发人员意识到他们之前的更改已被破坏并取消提交。
- 我更新。
现在，其他开发人员未提交的更改在我的本地结帐中显示为待处理的合并，并且我找不到将它们与我的更改分开并从我的“本地”树中删除它们的方法。
每次发生这种情况时，我都必须手动确定哪些更改是我的，哪些不是，保存我的更改，恢复，然后重新应用我的更改。
我尝试过在 -r -1..-2 和 -r 0..-1 之间的结帐时进行“择优挑选”反向合并，但都没有帮助了。 （0..-1 表示“无事可做”，尽管我可能没有正确完成。-1..-2 是错误的更改集，因此让事情变得更糟。）
当这种情况发生时，我该如何解决（除了过去并打另一个开发人员的头）？
Hit the following situtation a couple of times today:
- Myself and another dev both have bazaar local checkouts of a repository.
- I make some changes.
- The other dev makes and commits some changes.
- I update.
- The other dev realises their previous changes were broken and uncommits them.
- I update.
Now the other dev's uncommitted changes appear as a pending merge in my local checkout, and I can't find a way to separate them from my changes and remove them from my 'local' tree.
Every time this has happened I've had to manually work out which changes are mine and which are not, save my changes, revert, and then re-apply my changes.
I've tried doing a "cherrypicking" reverse merge on my checkout between -r -1..-2, and between -r 0..-1, but neither helped. (0..-1 said "nothing to do", although I might not have done it properly. -1..-2 was the wrong set of changes and thus made things worse.)
How can I fix this situation when it happens (other than going over and smacking the other dev upside the head)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
建议您不要在以某种方式发布的分支中取消提交，从而避免此问题。
It is recommended that you don't uncommit in branches that are published somehow, thus avoiding this issue.
一旦您更新（第 4 步），其他人的更改将永久合并到您的更改中。由于您的更改未提交，因此它们不会存储在任何地方。因此，一旦执行了第 6 步，我确实没有找到一种方法可以自动将您的更改与他的更改分开。
假设您手动删除了他的所有更改，只留下您的更改。您仍然有这个待处理的合并需要处理。您可以通过键入
That will not 更改您的工作树来解决此问题；它只会从“bzr st”中删除待处理的合并，这样当您提交时它看起来就不会像合并。这将使您不必保存更改、恢复并重新应用。
为了避免再次发生这种情况，您可以仅在提交之前运行
bzr update。一旦合并，立即进行bzr 提交，并且您的更改将被锁定。现在，如果没有先更新并查看您的更改，他将无法取消提交，现在对他来说可能为时已晚这样做。如果他真的想继续他的未承诺，那么他就是那个必须处理混乱的人，而不是你。您可以做的最后一件事 - 如果您真的不想处理它并且您不太关心拥有良好的版本历史记录。第 6 步之后，只需提交即可。也许在你的日志中解释说其他开发人员未提交此更改，但为时已晚。
这就是挂起的合并的用武之地。如果您提交，未提交的修订将作为分支返回到存储库中，就像其他开发人员已通过电子邮件将这些更改发送给您一样你合并了它们。它看起来像这样：
当他再次运行更新时，他会将旧的更改返回给他，并且可能会发生冲突。他必须清理它，然后提交他的修复（无论他最初出于什么原因不得不取消提交）。这可能和敲击头部一样有效，并且可以通过网络工作:)
Well once you have updated (step 4), the other guy's changes will be merged with yours permanently. Since your changes were uncommitted, they aren't stored anywhere. Therefore, once step 6 has happened, I don't really see a way of automatically separating out your changes from his.
So let's say you manually remove all of his changes so you're just left with yours. You still have this pending merge to deal with. You can fix that by typing
That will not change your working tree; it will only remove the pending merge from your "bzr st" so that when you commit it will not look like a merge. This should save you from having to save your changes, revert and re-apply.
To avoid this happening again, you could run
bzr updateonly immediately before you commit. Once merged, to abzr commitright away, and your changes are locked in. Now he won't be able to uncommit without first updating and seeing your changes, and now it's probably too late for him to do that. If he really wants to go ahead with his uncommit, he's the one that has to deal with the mess, not you.One final thing you can do -- if you really don't want to deal with it and you don't care too much about having a nice version history. After step 6, just commit. Maybe explain in your log that the other dev uncommitted this change but too late.
This is where the pending merge comes in. If you commit, the uncommitted revision will go back into the repository, as a branch, just as if the other dev had send those changes to you in an email and you merged them. It will look like this:
When he runs update again, he'll have his old changes thrown back at him, and probably get a conflict. He'll have to clean it up, then commit his fixes (whatever reason he had to uncommit in the first place). This is probably just as effective as a smack upside the head, and works over a network :)
它看起来像
bzr pull --overwrite :bound是你在追求什么。It looks like
bzr pull --overwrite :boundis what you're after.