'git request-pull'和'pull request'之间的区别 [英] Difference between 'git request-pull' and 'pull request'

查看:857
本文介绍了'git request-pull'和'pull request'之间的区别的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

什么是 git request-pull ,它与制作拉取请求比较起来如何,例如 on github



1。应该如何使用?

2。它可以用来代替pull请求(例如在github上)吗?

3。使用它的优点是什么? git request-pull 命令早于托管服务。正如在评论中指出的那样,它意味着工作流程往往包含运行 git format-patch git send-email 通过电子邮件传递补丁。一旦补丁已经过测试和批准,补丁生成器可能会使提交可以在他们或他们公司提供的公共服务器上访问,并发送最终的电子邮件消息给项目维护者,宣布他们已经清理,重新发布,例如,假设一个名为Phil Systeme的人拥有一个用于文件系统的Linux内核修补程序。在某些Linux版本中,他拥有Linux内核树的克隆。他的补丁包含一个巨大的提交到十几个文件,他发送到文件系统维护列表,主题为:

  PATCH:使foo文件系统更好

文件系统维护邮件的反馈首先列出的是:将其分成至少六个较小的部分。 Phil Systeme将他的Phile System修补程序分成八个逻辑较小的修补程序,其中每个修补程序都做了一些有用的工作,并且仍在构建中。这次他发出9条消息:

  [PATCH v2 0/8]:使foo文件系统更好

(关于补丁系列的描述)

[PATCH v2 1/8]:分割xyzzy函数

作为改进foo的先决条件文件系统,把
a大函数分成几个小函数,每个小函数执行一个
的事情。稍后我们将使用它来更好地工作并添加新功能。

[PATCH v2 2/8]:...

这次,他得到的反馈信息表明它看起来更好,但他忘记说明ARM cpus需要一件特别的事情,而MIPS CPU需要不同的特殊事物。因此,他发出了第三轮 [PATCH v3 m / n] 消息,依此类推。



最终,文件系统维护中尉同意这个补丁应该进入。现在,Phil或者中尉将通过电子邮件发布的补丁转换为实际的Git提交,应用于当前的开发内核或维护内核,或者任何其他应用。在这一点上,Linus Torvalds相信这个人足够了,这个人可以说:这里是一个Git仓库,你应该添加新的提交到内核。那么Linus可以直接从这个其他仓库中获取 git pull ,或者更可能从那里获取 git fetch ,然后决定是否以及如何合并它们,还是侮辱这个人。 : - )




托管服务如GitHub和Bitbucket声称或感受到,或者您喜欢的任何动词,拉请求机制优于所有这些电子邮件。在某些方面,它很明显是;但是他们对隐藏实际的提交图的热情,如果你要使用真正的合并,真的很重要,这对我来说是一个谜。


What is git request-pull and how does it compare to making a pull request, e.g. on github?

1. How is it supposed to be used?

2. Can it be used as replacement for pull requests (e.g. on github)?

3. What are the advantages of using it?

解决方案

The git request-pull command predates hosting services. As noted in comments, it's meant for a workflow that tends to include running git format-patch and git send-email to pass patches around via email. Once the patches have been tested and approved, the patch-generator might make the commits accessible on a public server that they or their company provide, and send a final email message to the project maintainer announcing that they have the cleaned-up, rebased, etc., project-topic ready for merging.

For example, suppose a guy named Phil Systeme has a Linux kernel patch for a file system. He has a clone of the Linux kernel tree, as of some Linux release. His patch consists of one giant commit to a dozen or so files, which he sends to the file-system maintenance list, with a subject line:

PATCH: make the foo file system better

The feedback on the file-system maintenance mailing list first says: break this into at least six smaller parts. Phil Systeme breaks up his Phile System patch into eight logical smaller patches, each of which does something useful and still builds. He sends out 9 messages this time:

[PATCH v2 0/8]: make the foo file system better

(description of what the patch series is about)

[PATCH v2 1/8]: split up the xyzzy function

As a prerequisite for improving the foo file system, break
a large function into several smaller ones that each do one
thing.  We'll use this later to work better and add new features.

[PATCH v2 2/8]: ...

This time, he gets feedback that says it looks better but he forgot to account for the fact that ARM cpus require one special thing and MIPS CPUs require a different special thing. So he sends out a third round of [PATCH v3 m/n] messages, and so on.

Eventually, the file system maintenance lieutenant(s) agree that this patch should go in. Now Phil, or the lieutenant, converts the emailed patches to actual Git commits, applied to a current development kernel, or to a maintenance kernel, or whatever. Linus Torvalds trusts this person enough at this point that this person can say: "here is a Git repository with new commits that you should add to the kernel." Linus can then git pull directly from this other repository, or more likely, git fetch from there and decide whether and how to merge them, or whether to insult the person. :-)


Hosting services like GitHub and Bitbucket claim, or feel, or whatever verb you like here, that their "pull request" mechanism is superior to all this email. In some ways, it pretty clearly is; but their enthusiasm for hiding the actual commit graph, which really does matter if you're going to use a true merge, is kind of a mystery to me.

这篇关于'git request-pull'和'pull request'之间的区别的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆