我可以在使用Eclipse重新分配课程后将其重命名

发布于 2025-01-18 10:03:05 字数 315 浏览 4 评论 0原文

我刚刚使用Eclipse重构了以Mercurial跟踪的班级名称。我的Mercurial Eclipse插件是否正确跟踪了我的重命名,或者我可以做些什么来跟踪它?我该如何确定它是否跟踪?

在Eclipse执行重构后,我现在似乎无法使用HG重命名B命令。

Eclipse on Ubuntu 18.04
Version: 2022-03 (4.23.0)
hg --version
Mercurial Distributed SCM (version 4.5.3)

我猜Git由于重命名检测而不需要处理此问题。

I've just used eclipse to refactor a class name tracked in mercurial. Did my mercurial eclipse plugin properly track my rename or is there something i can do to help track it? How do I tell if it did track?

It does not seem I can now use the hg rename a b command after eclipse has performed the refactor.

Eclipse on Ubuntu 18.04
Version: 2022-03 (4.23.0)
hg --version
Mercurial Distributed SCM (version 4.5.3)

I'm guessing git does not need to deal with this because of it's rename detection.

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

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

发布评论

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

评论(2

别再吹冷风 2025-01-25 10:03:05

我不确定 Eclipse 做了什么,但是您绝对可以检查重命名是否正确记录,如果没有则事后手动记录。

我在这里假设您尚未提交更改。

一种检查方法是:在命令行上运行 hg diff -g path/to/new/file。如果记录了重命名,那么从差异中应该可以明显看出;您要么不会看到文件发生任何更改,要么至少看到可识别的更改。但如果它没有被记录为重命名,那么 diff 会认为整个文件是全新的。

接下来,如果未记录文件重命名,您可以执行:

hg mv -A path/to/original/filename path/to/renamed/filename

然后它将将该文件视为重命名(例如,移动)。再次运行 diff 来确认效果。


一个非常相似的情况是,如果您通过将文件分成几部分来重构文件。在这种情况下,您可以使用 hg cp -A ... (代替 hg mv)将原始文件的所有衍生部分记录为它的“副本” 。这样做的好处是,影响原始文件的任何后续合并也将传播到其所有衍生文件,这是跨副本/重命名跟踪文件历史记录的主要好处之一。

I'm not sure what Eclipse has done, but you can definitely check if the rename was recorded correctly, and if not manually record it after the fact.

I'm assuming here that you have not yet committed the changes.

One way to check is: on the command line run hg diff -g path/to/new/file. If the rename was recorded that should be obvious from the diff; either you will see no changes to the file or at least recognizable ones. But if it was not recorded as a rename then diff will think the entire file is completely new.

Next, if the file rename was not recorded, you can do:

hg mv -A path/to/original/filename path/to/renamed/filename

and it will then treat the file as renamed (e.g., moved). Run the diff again to confirm the effect.


A very similar case is if you refactor a file by breaking it into pieces. In that case you could use hg cp -A ... (in place of hg mv) to record all the derivative pieces of the original file as "copies" of it. This has the benefit that any later merges which affected the original file will propagate to all its derivatives as well, which is one of the major benefits of tracking the file history across copies/renames.

烟花肆意 2025-01-25 10:03:05

一种可能性是将 addremove- 一起使用-相似度选项。

hg addremove --similarity 80

这通过相似性猜测文件重命名。该选项采用 0(禁用)和 100(文件必须相同)之间的百分比作为其参数。

One possibility is to use addremove with the --similarity option.

hg addremove --similarity 80

This guesses file renames by similarity. This option takes a percentage between 0 (disabled) and 100 (files must be identical) as its parameter.

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