如何对一系列快照和潜在合并进行排序

发布于 2024-11-30 14:49:03 字数 351 浏览 3 评论 0原文

我正在将一个项目转换为 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 diffs 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 技术交流群。

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

发布评论

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

评论(1

再浓的妆也掩不了殇 2024-12-07 14:49:03

可能感兴趣的一个可能的指标是将提交与他们的父母和祖父母进行比较 - 如果您看到与祖父母的相似性较高(=较小的 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.

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