如果在 Mercurial 中,出现“hg up -r”怎么办?完成后,某些文件被修改并意外提交?

发布于 2024-09-27 09:20:48 字数 418 浏览 1 评论 0原文

如果只是为了看看程序的行为如何,

hg up -r 1000

就完成了,而当前版本是1020

然后对 2 个文件进行了一些更改,并且意外地提交了这些文件。

那么现在有从1000修订版到1020版的变化,还有一些从1000直接到1021的变化……

这种情况应该如何处理?

至少有一种可能

hg backout -r 1021
hg up tip

,并进行更改,就好像 1021 没有发生任何事情一样。另一种选择是进行 hg merge 并且需要注意代码的合并方式吗? (因为从1000到1021的所有更改都与相同的功能和相同的文件相关)。或者说除了这两个还有其他选择吗?

If just to see how a program behave, an

hg up -r 1000

is done, while the current revision is 1020.

Then some changes are made to 2 files, and accidentally, the files are committed.

So now there are changes made from revision 1000 to 1020, and also some changes that is from 1000 directly to 1021...

In this case, how should it be handled?

At least one possibility maybe

hg backout -r 1021
hg up tip

and make changes as if nothing happened with 1021. Is the other option to do an hg merge and need to be careful about how the code is merged? (because all changes from 1000 to 1021 are all related to the same feature and same files). Or is there any other option besides these two?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

一场信仰旅途 2024-10-04 09:20:48

只需进行合并即可。不会很痛苦。

人们建议的退出仍然会让你有多个头。目前,您的历史记录如下所示:

---[1000]---[1001]--....--[1019]--[1020]
      \
       \----[1021]

在 1021 回退之后,它将如下所示:

---[1000]---[1001]--....--[1019]--[1020]
      \
       \----[1021]---[1022]

其中 1021 和 1022 会在逻辑上相互撤消,但您仍然拥有两个头。

合并后,您

---[1000]---[1001]--....--[1019]--[1020]---[1022]
      \                                   /
       \----[1021]-----------------------/

可以在更新到 1021 后执行“hg commit --close-branch”,这仍然会保留该头,但会阻止其显示在列表中,但合并是更好的选择。

如果您还没有将 1021 推送到任何地方,您可以完全将其留在后面,就像:

hg clone -r 1020 myrepo trimmedrepo

然后您将拥有一个新的存储库,trimmedrepo,其中包含 1020 之前的所有内容(但没有 1021)。

我喜欢合并。

Just do the merge. It won't be painful.

The backout people are suggesting will still leave you with multiple heads. Currently your history looks like this:

---[1000]---[1001]--....--[1019]--[1020]
      \
       \----[1021]

After a backout of 1021 it would look like:

---[1000]---[1001]--....--[1019]--[1020]
      \
       \----[1021]---[1022]

where 1021 and 1022 would logically undo one another but you'd still have the two heads.

After a merge you'll have

---[1000]---[1001]--....--[1019]--[1020]---[1022]
      \                                   /
       \----[1021]-----------------------/

You could do a 'hg commit --close-branch' after updating to 1021, which will still leave that head in place but will stop it from showing up on listings, but the merge is a better choice.

If you've not yet push 1021 anywhere you could leave it behind entirely like:

hg clone -r 1020 myrepo trimmedrepo

and then you'll have a new repo, trimmedrepo, that has everything up to and including 1020 (but no 1021).

I like the merge.

第七度阳光i 2024-10-04 09:20:48

你看过 rebase 扩展吗?它应该很好地处理这个问题:

hg up 1020
hg rebase -s tip

这样做的结果是,您意外对修订版 1000 所做的更改被移至 1020。我假设您想保留这些更改,而意外只是您对旧修订版进行了更改。如果您确实想摆脱更改,那么撤销方法是不错的选择。您还可以使用 MQ 扩展中的 strip 命令将它们从历史记录中删除。 rebasestrip 都会重写您的本地历史记录,如果您已将尝试编辑的变更集推送到其他人的存储库,则它们不适合。

Have you looked at the rebase extension? It should handle this nicely:

hg up 1020
hg rebase -s tip

The result of this is that the changes you accidentally made against revision 1000 are moved to 1020. I'm assuming that you want to keep the changes, and the accident was just that you made them against an old revision. If you really want to get rid of the changes, your backout approach is good. You can also use the strip command from the MQ extension to remove them from history. Both rebase and strip rewrite your local history, making them unsuitable if you've pushed the changesets you're trying to edit to someone else's repository.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文