Github 批准在 rebase -i 中生存?

发布于 2025-01-10 18:52:19 字数 183 浏览 0 评论 0原文

我想支持以下场景:

  • 拉取请求被标记为已批准
  • 作者强制推送具有不同 git 历史记录的完全相同的代码(变基或变基 -i 南瓜)
  • 作者合并代码

通常,强制推送将清除所有批准,因为它可能是完全不同的代码。在这种情况下我不想保留批准。但是有没有办法让github去查呢?

I'd like to support the following scenario:

  • Pull request is marked as approved
  • Author force-pushes the exact same code with a different git history (rebase or rebase -i squash)
  • Author merges code

Normally, a force-push will clear any approvals, since it could be of completely different code. And I wouldn't want to keep approvals around in that scenario. But is there any way to get github to check?

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

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

发布评论

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

评论(1

葬花如无物 2025-01-17 18:52:19

没有办法做到这一点,因为一般来说,确定两组提交是否引入相同的更改并不容易。

您尝试执行此操作的逻辑方法是使用 diff 输出,但由于变基可能会引入上下文更改、代码移动或重命名文件,因此这实际上是不可能的。在没有上下文的情况下仅查看添加和删除的行是无效的,因为将相同的代码添加到不同的函数将是本质上不同的更改。一组重新设置的更改是否“相同”需要比 Git 拥有或能够提供的更多关于代码的知识。

There's no way to do this because in general, it's not easy to determine whether two sets of commits introduce the same changes.

The logical way you'd try to do this is with diff output, but because the rebase can introduce context changes, code movement, or renamed files, this isn't really possible. Looking at only the added and removed lines without context wouldn't be effective because adding the same code to a different function would be a substantively different change. Whether a set of rebased changes is "the same" requires substantively more knowledge about the code than Git has or can provide.

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