My 12-year old questioned why a 'pull request' is named the way it is. Obviously it's after the command 'git pull' which fetches the latest changes, then merges them, but it's confusing according to him, and should be called a 'merge request' instead. I don't disagree.
My understanding is that Github called this "pull requests" because it does something similar to the `git-request-pull` function (See https://git-scm.com/docs/git-request-pull).
I quote
> Generate a request asking your upstream project to pull changes into their tree. The request, printed to the standard output, begins with the branch description, summarizes the changes and indicates from where they can be pulled.
GitLab, on the other hand, _does_ call it "merge requests" because you to your 12-year old's point, that is what they are.
"git pull" doesn't merge the "latest changes"; A pull is fetch+merge, and you can fetch from any repository, so a pull request is saying "please fetch commits from my repository and merge them".
I think git made a mistake in making pull the default (fetch+explicit merge is better) but "pull request" is correct terminology.
Is pull the default? What does that even mean? I certainly tend to fetch, checkout origin/master, create a feature branch, push, then merge in github’s web interface.
I «never» pull and I don’t have to change any settings.
this statement surpises me, because `git pull --rebase` is practically my most frequently used operation, besides commit, push and changing branches.
intellij even comes with the concept of update, which is either a `pull` or a `pull --rebase`
it asks u once which of those should be the default behaviour, then all i do is cmd-t to updaTe (aka git pull --rebase) my current branch, then push my commits, after a potential 3-way merge, which intellij has the easiest-to-learn interface for, imho.
In the early days it was literally a “request to pull from me” - one would literally email Linus (for example) “hey, I made X changes, consider pulling them from Y (an attached file, or a server)”
git as designed is truly decentralized and doesn’t consider your copy of Linus’s kernel tree to be much different than his - and so you ask him to pull from you.
Of course we immediately centralized around GitHub and turned it into a glorified SVN but that’s the fate of all decentralized entities.
Gitlab tends to work with multiple developers working in a single repo where branches are pushed and the command to integrate the changes from one branch to another is git merge.
Github tends to work with forks - where each developer is working in their own fork. When the work in the fork is complete, since it is a different repository than the original one, in order to integrate the changes the command to invoke is git pull.
The difference reflects how the typical developer works with integrating changes on that hosting solution.
This used to be one of my there's-no-wrong-answer interview questions: what's the (philosophical) difference between a pull request and a merge request.
Engineers start to think out loud about it, mention github and gitlab, etc etc so I got a meta-level scan of their experience (or the lack of it) with these tools.
Of course this was just a warmup (or cool down) question before (or after) the real git/engineering related questions.
Yep. At Google it is "change list", which I think is good because it isn't a "request" until you send it to someone to merge it, which you don't always do. Maybe "diff list" would be even better. Or maybe we could have just stuck with "patch" or "patch set" from back when people would just send these around in emails.
Ah, miss creating CLs and using fig. I now use git but always liked fig/mercurial better and wish it had won the version control space. When people ask me what I liked about mercurial, I tell them that I could rebase, cherry pick, branch and do whatever else I could think of without needing to Google it or going to stackoverflow, it was just intuitive. I can’t seem to grok git that way. Any time I need to do anything more than branch, stage, commit, push, I have to google and read man pages.
Yep, mercurial is great, much better design at the API level, though I don't know the internals of either of them. Fig is pretty good but it feels a lot slower than git; I think it's doing more stuff remotely than I expect it to.
If you like Fig and want a similar (but better, IMO) UX that can be used with Git repos, you may want to try my project: https://github.com/martinvonz/jj. It's also pretty fast (can rebase >1k commits in <1s in the Git source repo, for example).
I'm on the Fig team at Google, but the project is my own.
In git, "merge" is a local operation: it operates on two branches already available in the local repository. In order for you to incorporate somebody else's changes, they would have to first push their changes to you, or ask you to pull theirs.
I'm not entirely certain about the history of the term "pull request" as it pertains to Github, but git itself has a subcommand called request-pull that will provide information about changes between two commits, where it can be fetched from, and a short log (a list of commit titles grouped by author), as well as the overall diff.
This was something that stuck in my brain for the longest time, until I framed it as "requesting to have a patch pulled [away] into the repo to be merged." Then it all made painful simple sense. I don't know why I got stuck on it for as long as I did. Maybe it's an English language context thing: change pulls are You pulling, but pull request is Them pulling.
My 12-year old questioned why a 'pull request' is named the way it is. Obviously it's after the command 'git pull' which fetches the latest changes, then merges them, but it's confusing according to him, and should be called a 'merge request' instead. I don't disagree.