[lucideer]

> The difference is subtle, but significant. In the pull request model, you create a fork of the original repository, push changes to it, and ultimately propose to merge changes back. In the change proposal model, you prepare a change, and propose it. You do not create a complete fork and everyone contributes into the same original repository with what are basically lightweight, ephemeral topic branches

This is an odd distinction to make. Forking in GitHub is an entirely optional process - in my experience it's primarily used to invite outside collaborators to open source projects. I've never worked on a team that uses this process for their owned repos. I've only ever used GitHub Pull Requests according to the process described here as the "Gerrit way".

I've never used Gerrit so not sure if I'm missing something here: it sounds like they're just describing a process that works identically to PRs with the exception that the platform doesn't support forks?

[reactordev]

Quite the contrary to their claim, we restrict forking on ALL our repos and still have meaningful PRs.

Your assertion is correct that most organizations operate this way.

However, open source is different. Often you’ll have someone fork - hack on it - devise a novel change - and request a PR from their fork:branch to origin:branch.

In this scenario, the fork - and subsequent hacking - are exploratory while submitting the change and PR is distinctive. Not sure how one is supposed to explore and hack and provide PRs in their model as you’re forced to branch. A local copy is still a “fork” but with a separate origin.

You can still do a dual origin setup or do a merge main onto yours but I find this extremely limiting to contributors and overly controlling by project owners. There’s nothing stopping you from enforcing squash on merge or having standards on your SDLC. Enforcing that on everybody else isn’t in our best interest though. A diarrhea of commits is how you end up with spaghetti code.

[bityard]

From where I sit, the primary distinction seems to be where the fork lives. On Github, forks are public. You get a copy of the repo in your own namespace on Github which you can pull from and push to from wherever. Others can see it and any changes you make to it as well.

On OpenDev, your clone/fork/personal branch is only on your dev machine and you only push patches, if I'm reading it right.

I guess the OpenDev model discourages people from forking the repo, modifying it to suit their needs, and then not sharing the results. To some degree.

I think I actually prefer the GitHub model where people's branches/changes are public by default unless they choose to go through the trouble to make their fork private. I have found many good bug fixes and enhancements for repos abandoned by their upstream authors this way.

[cmsj]

The key philosophical difference is that in Gerrit you are proposing a specific change, where in GitHub you are proposing a branch be merged.

It's a very subtle distinction, but having worked on OpenStack in the past, I much prefer the Gerrit model. Patch revisions are much easier to track over time than pushes to a PR branch during review.