Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)

[John Franklin <franklin%elfie.org@localhost>]

On May 13, 2020, at 17:56, Greg A. Woods <woods%planix.ca@localhost> wrote:
> 
> At Wed, 13 May 2020 21:30:29 +0200, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
>> 
>> On Wed, May 13, 2020 at 12:21:50PM -0700, Greg A. Woods wrote:
>>> At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
>>> 
>>>> I have no idea what the OP is talking about. Mercurial doesn't have pull
>>>> requests, neither does git BTW. So this is about some specific web UI or
>>>> review tool, but I don't even know which one.
>>> 
>>> Consider "pull request" to stand in for _any_ kind of workflow and
>>> mechanism that third parties would use to submit changes along with the
>>> recorded existing metadata for those changes, to the upstream project's
>>> repository.

Put another way, it’s nothing more than “please consider the changes in branch jqcoder/foo for inclusion in your project.”  Any DVCS that can handle branches reasonably well can do something like a “pull request.”  If you like it, `${DVCS} merge jqcoder/foo`.  The way GitHub handles PRs, the branch lives in their private clone of the repository, not the main project’s copy.  It prevents the master repository from getting polluted with dozens of pull request branches.

> So thus the question remains:  What will NetBSD's workflow be?  Will it
> be compatible with merging a set of changes from a third party in much
> the manner of what's typically called a "pull request" in the Git
> (github, gitlab, etc., etc., etc.) world, and especially in a way that
> avoids squashing a branch into a single commit (thus losing commit
> metadata)?

It should be possible to go both ways.  I’ve seen very clean pull requests of a few commits that should be merged including the full history, and some that were 300+ commits with one-third of the commit messages including the words “revert” or “undo” in them.  (In some cases, the commit message was simply “revert”.)  Following the chain was fruitless, only comparing the branch to the mainline was of any value, and a squash commit is the only way to handle such things.

jf
-- 
John Franklin
franklin%elfie.org@localhost