They aren’t all the same thing. A diff (or patch) is a change to the code that’s not tied to the history in any place. Linux kernel patches and Meta diffs are like this.

Pull Requests and Merge Requests are more complicated, and the unit of change is a branch. Many people reject this workflow because ultimately a branch of commits can be summed to one single diff and that’s the only thing that matters in the wider project, outside of your private branches on your personal machine.

GitLab doesn’t support anything other than merging hence the name. Most people who prefer linear history will never merge. Instead they’ll land their change on the tip of the branch, each developer taking it in turns to advance the linear history one step at a time.

I don’t know about changelists or change requests.

No, Gitlab does support other integration workflows, including one which requires MRs be rebased and fast-forwards them onto main without a merge commit.

A changelist is most generally a Perforce term (and as may the case for Google, a similar concept). In the Perforce Helix Core (what the "Perforce Server" is currently called), changelists are increasing integers that mark units of atomic change. Changelists can contain committed work, pending work, or shelved work (a shelf is un-committed work that resides server-side). Shelves are often how code review is done since the file content and metadata is available outside of the author's computer.

Whereas “merge request” and “pull request” have very literal meanings in terms of Git / distributed version control systems, Phabricator’s “diff” is VCS neutral. Diffs don’t even have to come from a VCS at all.. we have tools that spit out Phab diffs for review of changes they’re going to apply to MySQL DBs, for example.

When you use Phab with Git you normally set it to always squash merge. Each diff becomes exactly one commit on the main branch, with its commit message reformatted by Phab. The SHA that you committed before submitting your changes to Phab never appears in the authoritative repo (if only because Phab adds Reviewed-By and other metadata).

It's all the tooling: phabricator has diffs, perforce has changelists and git has both "merge" and "pull".

Tools don't agree on what to call stuff, and everyone uses different tools (and a lot of these tools are pretty old). Perforce is from '95, phabricator is from '07. Both of those predate widespread usage of git (released '05), so it's pretty reasonable that everything is different.

I think this basically doesn’t matter and it’s fine for institutional culture to have its own ingroup jargon.

Trying to standardize for some aesthetic reason wouldn’t add anything

I don't know that this particular term is a big deal, but it's a little alarming that you think standardized terminology has no more than "aesthetic" value.

“Some aesthetic reason” like cutting down on onboarding time? Making things a bit less complex for the juniors?

Standardization is more about consistency than aesthetics.

I think most people would be able to handle any one of those terms smoothly on day 1

You: "I'm going to send a pull request"

Other engineer: "OK. BTW, we call them change requests here"

You: "OK"

If only it were that simple. As we’ve seen in this thread, you’d instead likely have:

Somebody else: Where I used to work we called them pull requests. Let’s have a meeting to discuss changing the terms to match industry standards. We may also want to create a committee to agree on other terminology changes too, like main instead of master.

I'm not sure if you're saying this as an argument for standardisation (ha, let's debate the spelling) or not, but these people will always find something, from frameworks to linting rules - the amount of discussion stays the same no matter how much is agreed

I'm not really arguing for one way or the other, just pointing out the reality of working with lots of people means lots of opinions on how to do things, so it's never that straightforward to get things done. It's just a fact of life.

And yeah, I've been in those long discussions too about frameworks and linting rules. It can often turn into just egos trying to win and less about doing what's right or expedient for the team.

The workflow is different enough where it does take some time to get used to

> The workflow is different enough where it does take some time to get used to reply

If the workflow is different, then it's _not_ just a question of terminology. In that case it's probably a good thing that there are different names for the various workflows.

These are all just terms for slightly different perspectives on the same thing. Like diff is the summary of changes in a commit. the person who wants to affect the change submits a pull request. Another person reviews the pull request and decides whether or not to merge their code into the main codebase, etc. It's all the same thing from different perspectives.

The content is the diff (including description/test plan), which I'd argue should be the name.

It could be in a draft state, awaiting review, accepted for merge, or being merged.

'diff' is the shortest at most descriptive name.

There is no "correct" name. You only see things from your standpoint, and so does everyone else. There is nothing about your opinion that is any less arbitrary than all the opinions that disagree with you.

When I hear “PR” I think of a tree of git commits. When I hear “diff” I think of one set of squashed text changes, for a tool that doesn’t support git.

Is diff the best of them all though, because of the implication?

Mac: What implication?

Dennis: The implication that things might go wrong for her if she doesn't review my code in a timely manner. Now, not that things are gonna go wrong for her, but she’s thinking that they will.

The others have one thing in common: they describe the difference between what is and what should be. Whereas diff is commonly used for the difference between any two things. You could make a diff (as in using the diff program) between two feature branches with no intention of merging one into the other. To me it makes sense to have separate names for these two concepts.

Diff seems the best because the others describe internal details of the source code management implementation. Pull request, merge request, and changelist especially.

They are all diffs. Simple is better here.

All pull/change/merge requests are diffs, but not all diffs are pull/change/merge requests.

Right, but in the context of making code changes, you can use diff. Which aligns with the Unix tool diff, and application of said diff with patch. So diff and patch are the operations that happen as you mutate a code base.

Of all these, the one that confused me the most when I encountered them was surely "pull request".

Same

> Nitpicking, but jesus christ, why can't we stick to a single term?

Because different groups of people develop their own languages. This is pretty standard for humanity across all time periods, disciplines, cultures, etc.

diff request makes the most sense to me...

At least that seems descriptive in the context of making a request in a system to get approval to change the code.

A diff request would be asking someone to create a diff for something.

Other folks have said the basic (these aren't the same) but one thing that I feel like few people realize is that "Pull Requests" aren't actually a git concept at all.

"Pull Requests" are just implementations that many web-based git tools (but not all!) have adopted to facilitate the code review process taking place on their platforms.

I'd like to propose another to consider "delta"

nitpicking but "changelist" sounds like what meta would call a diff-stack (aka multiple diffs).

don't forget Incident = SEV = DEFCON = 911 ...