Mercurial 中的清晰修订历史记录
我是 Mercurial 的新手,仍在尝试建立工作流程。
我克隆了一个远程存储库。然后我进行更改并提交到我的本地存储库。我想推送一个干净的修订历史。我不想推送一些可能只会使远程存储库变得混乱的修订(例如方法的拼写错误重命名、添加 javadoc、删除空格等)。这可能吗?
谢谢你!
I'm new with Mercurial and I'm still trying to establish a workflow.
I clone a remote repository. I then make changes and commits to my local repository. I would like to push a clean revision history. I don't want to push some revisions that may only muddy the remote repository (e.g. typo rename of methods, adding of javadoc, removing whitespaces, etc). Is this possible?
Thank you!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
事实上,在某些情况下,修剪/剥离/抛光变更集或分离私有/正在进行的和公共/就绪的变更是有意义的。以下是如何使用 Mercurial 处理此问题的一些建议:
如果您进行了一系列小提交(这是一件好事),但您更喜欢将它们作为一个变更集发布(如果您提交了,这很有意义 - 可能是矛盾的 -快照变更集),使用 collapse 扩展:
如果您只想进行更改当您希望其他人保密时发布时,(a) 使用 mercurial 队列 进行私有更改,或者 (b) 在自己的分支 中提交仅限私有的更改 (命名、添加书签或克隆)并定期将其与公共分支合并。如果您交替提交私有和公共更改,后者要求您经常在分支之间切换。
更新
为了说明选项 2.b,请考虑以下变更集图表:
这意味着您已对 进行了
2
和3
更改dev 分支。然后,您在 stable 分支上做了一些工作(修订版4
和5
)。这些更改在 dev 中也有意义,因此您将它们合并到 dev(修订版6
)中。最后,您在dev(修订版7
)中进行了另一项实验性更改,并在stable(修订版8< /code> 和
9
)。您现在可以通过运行发布(即推送到远程存储库)在稳定中所做的更改所有私有更改将保留在本地!
请注意,如果您计划稍后完善您的私有提交(例如将它们折叠为一个变更集),则不得在稳定分支中合并(折叠不能跨合并工作)。相反,只要您希望私有更改与中的最新更改同步,rebase您的私有更改即可>稳定。
Indeed there are cases when it makes sense to prune/strip/polish changesets or to separate private/in-progress and public/ready changes. Here are some suggestion how to handle this with Mercurial:
If you made a series of small commits (which is a good thing), but you prefer to publish them as one changeset (which makes sense if you committed - possibly contradicting - snapshot changesets), use the collapse extension:
If you just have changes you want to keep private while others you want to publish, either (a) use mercurial queues for you private changes or (b) commit you private-only changes in an own branch (named, bookmarked, or cloned) and regularly merge it with the public branch. The latter requires you to switch between branches quite often if you commit private and public changes alternating.
UPDATE
To illustrate option 2.b, consider this graph of changesets:
This means you've made changes
2
and3
on the dev branch. Then you did some work on the stable branch (revisions4
and5
). These changes also make sense in dev, so you merge them into dev (revision6
). Finally you make another experimental change in dev (revision7
) and some ready-to-publish improvements in stable (revisions8
and9
). You can now publish (i.e. push to the remote repository) the changes made in stable, by runningAll private changes will stay local!
Note that if you plan to polish your private commits later (e.g. collapse them to one changeset), you must not merge in the stable branch (collapse cannot work across merges). Instead, rebase you private changes whenever you want them to be in sync with the latest changes in stable.
这更多的是关于一般版本控制系统的问题,而不是关于 Mercurial 的问题。就我个人而言,我会推动一切,你的建议有点违背版本控制系统的目的。
但是,如果您想了解有关 hg 工作流程的更多信息,请尝试查看此指南 或此wiki。
您可能还对 rollback 命令感兴趣,该命令使您能够修复最新的提交。
编辑:我选择的选项是保留两个分支:一个与远程存储库相同,您仅在其中提交“官方”更改,另一个则合并新的官方提交并进行其他私有提交。
This is more a question about revision control systems in general than about mercurial. Personally I would push everything, what you're suggesting kinda goes against versioning systems purposes.
However if you want to read more about hg workflows, try having a look at this guide or this wiki.
You could also be interested in the rollback command, that enables you to fix the latest commit.
edit: the option I would go for is to keep two branches: one identical to the remote repository where you commit only "official" changes, and one where you merge new official commits and make additional private commits.
如果最后完成了所有寄生更改,您可以简单地剥离它们。
如果没有,您可以尝试使用补丁队列来删除不必要的提交:
这对于小型应用程序有效承诺。如果您尝试此操作,请在本地存储库的克隆上执行此操作,以避免损失。
另外,请注意不要更改已经“共享”(推送)的历史记录。
If all the parasitic changes have been made at last, you can simply strip them.
If not, you can try to use the Patch Queue to remove the unnecessary commits:
This will work for small commits. Please if you try this, do it on a clone of your local repo to avoid loss.
Also, take care not to alter an already 'shared' (pushed) history.
Histedit 也可以是用于编辑历史记录的可用且更简单(比 MQ)的解决方案
Histedit also can be usable and more easy (than MQ) solution for editing history