如何对一系列快照和潜在合并进行排序
我正在将一个项目转换为 git。我们有很多 zip 文件形式的代码快照,带有大致的日期顺序和“版本”信息。但它并不那么可靠,并且还有一些分支和合并(使用 BC2 手动合并)。
我已按主要修订号和日期分隔了大部分快照,并且有一个漂亮且线性的提交序列。
我正在尝试查看使用 diff
是否会显示哪些提交不按顺序或可能是合并候选者 - 比较范围约为 -4/+1 提交,超过可能为 60 的序列承诺很长。
有没有人对检查这种构建历史的“无序性”的可能指标有任何建议。我的 *nix 脚本技能很低,近 30 年没有在愤怒中使用过它;-)。我正在考虑受影响的文件数量,以及更改/共同的行数,或类似的东西。有人有这方面的经验吗?
I'm converting a project to git. We have lots of code snaphots as zip files, with an approximate date order, and 'version' info. but it's not as reliable as it could be, and there was some branching and merging as well (manual merge using BC2).
I've separated out most of the snapshots by major revision number and date, and have a pretty, and linear, commit sequence.
I'm trying to see if using the diff
s would show which commits are out of sequence or are possible merge candidates - the comparison scope is about -4/+1 commit, over sequences that might be 60 commits long.
Does anyone have any suggestions as to possible metrics for checking the "out-of-sequenceness" of such a constructed history. My *nix script skill are low, not having used it in anger for almost 30 years;-). I'm thinking of number of files affected, and number of lines changed/in common, or something like that. Has anyone any experience of this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
可能感兴趣的一个可能的指标是将提交与他们的父母和祖父母进行比较 - 如果您看到与祖父母的相似性较高(=较小的 diffstat),则表明可能存在无序提交或恢复。
One possible metric that may be of interest would be comparing commits against both their parent and grandparent - if you see a higher similarity (= smaller diffstat) against the grandparent, it suggests there may be an out-of-sequence commit or revert.