Github popularized “pull request” and I think it’s a fine term. Whether you are “actually” pulling from a different repository instead of just doing a “merge request” (idiosyncratic GitLab term) within the same repository doesn’t feel like an interesting distinction.
If you're treating git as a centralized VCS, that is, there is only a singular upstream, perhaps, say, GitHub.com, then that makes sense. That, however, is not the only way to use the tool (though GitHub.com obviously has their own opinions on whether that should be the case or not), but the upstream repository that you're pulling from certainly it's an important distinction if you're using the tool beyond how GitHub.com wants you to.
So you should change your terminology depending on some “how X” your workflow is? If you are working with two repositories between yourself and a teammate then it becomes “pull request”, but then if you move back to the centralized company upstream then you’re doing “merge requests”? The distinction is not interesting enough to, well, make a distinction over.
> That, however, is not the only way to use the tool
And “pull request” somehow is exclusionary? No, because you can use it to talk about both inter- and intra-repository changes.
Yeah, `git pull` is just shorthand for `git fetch` followed by `git merge`, so it's technically a superset of a "merge request".
And it also handles the cross-repo case, which is a common case in the Github model of "make your own personal fork of the upstream repo and send PRs from there," which has advantages -- it allows random people to send PRs without needing to give them permission to e.g. pollute the upstream repo's branch namespace.
You pull when you want code from their repo, they pull when they want code from your repo. You don't have permission to push to their repo, so instead you request that they pull from yours.
No you pushed it to your own GitHub repository. So they need to pull from your repository into theirs.
Though I agree the situation is somewhat muddied by the fact that you can create pull requests for branches in the same repository (even though that's not the normal workflow). GitLab's "merge request" terminology is more accurate for that use case.
> ... But it’s actually a little misleading. You might think that this means that your main branch is up to date. It doesn’t.
No need to well-actually this one. Isn’t the Two Generals problem applicable here? If you are being really pedantic, it is impossible to tell whether you are “up to date” right this split second. Even if you do a fetch before `status`. So what’s the reasonable expectation? That the ref in your object database—on your own computer—is up-to-date with some other way-over-there ref in an object database last time you checked.
A simple `status` invocation can’t (1) do a network fetch (annoying) and (2) remind you about the fundamentals of the tool that you are working with. In my opinion. But amazingly there are a ton of [votes on] comments on a StackOverflow answer[1] that suggest that those two are exactly what is needed.
> I think git could theoretically give you a more accurate message like “is up to date with the origin’s main as of your last fetch 5 days ago”
But this is more reasonable since it just reminds you how long ago it was that you fetched.
Another thing: I thought that `ORIG_HEAD` was related to `FETCH_HEAD`, i.e. something to do with “head of origin”. But no. That “pseudoref” has something to do with being a save-point before you do a more involved rewrite like a rebase. Which was implemented before we got the reflog. I guess it means “original head”?
I'm pretty pro-Git, but I agree with the author on the wording of that message (though I disagree with their suggested alternative). "Your branch is up to date with ‘origin/main’" is technically correct, but the usage of the phrase "up to date" implies on a casual reading two things: That main matches origin/main, and that origin/main is up to date (i.e. that it was updated as part of the command, or is being kept up to date automatically and the last successful sync was arbitrarily recently). We're talking about a user-facing status message, not a machine-readable signal that must be true during this CPU cycle. This is a reasonable interpretation without having to get into networking theory.
"Up to date" means caught up in time, as opposed to space. Local branch positions are more like space ("where is this branch pointing?") and remote ref state is more like time ("when did I last update the remote ref?"). I know, that's very subjective. Either can mean either.
Anyway, I think a better wording might be "Your branch matches origin/main" or "Your branch's head is the same as origin/main" or "Your branch is pointing to the same commit as origin/main" or some other tradeoff between verbosity and clarity. Maybe with the author's suggestion as a parenthetical: "Your branch ... origin/main (remote ref last updated 5 days ago)."
>A simple `status` invocation can’t (1) do a network fetch (annoying)
i don't think that's annoying. i want network operations to be explicit, not implicit. when i do git status, i wanna know the status of my repository as is in my file system.
if i want to know what's going on in another remote, i will fetch that and then compare.
The expectation is that the information you get is up-to-date as of the time you started the status command, yes there can be a race in the time it takes to present information to your terminal but that's a small time window. This more or less means you want to fetch, yes. Two Generals problem is only applicable on the remote side, which may keep sending retransmits for a while, if it doesn't get acks that you received its data (which isn't the client's problem). If the client doesn't get data from the server presumably the right behavior (which I'd expect happens now with fetch) is to hang and print an error after a timeout.
It is not - it is the expectation of the phrase "up to date". You don't have to alter reality, you can just alter the description of reality to be a little more conversationally precise.
It's pretty presumptuous to just tell somebody what they think about English is wrong. We can change the wording without changing the system (Though technically we could even alter the system to update the remote ref as part of the status command, and the wording would be much better to a human! Though we shouldn't, since, as you imply, we don't want the status command to be dependent on a network call.)
Edit: Removed accusation of "Conflating the implementation of the system with the wording of its output".
I use an external keyboard for my right hand and the laptop keyboard for my left so that the left one can be more straight. So that an inflammation doesn’t worsen. (This is on Ubuntu/Gnome 3 (ugh))
I have tried two external keyboards (on the laptop) but then I had to deal with very annoying input lag from the second plugged in keyboard.
What about using a split keyboard like those from: Kinesis[1], ZSA Moonlander[2] or ErgoDox[3] or Voyager[4], etc. Or full key keyboard with split design like seen at: Logitec[5], Microsoft and others[6].
I feel that. It seems like you've found something that works for you, but if you're ever looking to change up your setup, I've got some keyboards that are helpful to me. I'm attached to a certain pricey brand (and they're awesome and I wholeheartedly endorse them), but you can find some cheaper alternatives as well that are similar. (They're also open hardware, so you could build them if you're so inclined.)
I have a Keyboard.io Atreus. It's very small, it has 44 keys. You don't move your hands to type, they just stay where they are and only your fingers move. The downside is that, to make up for the lack of keys, you've gotta use several layers with modifier keys (eg I have 3).
I've also got a split keyboard (Keyboard.io Model 100). Each side can be positioned independently, and they're hooked together by an Ethernet chord. So you could get a similar set up to what you have now.
The other things that were important for me are a vertical mouse (Logitech MX Pro Vertical), and a gaming mousepad, and additional padding for my chair's armrests.
Obligatory reminder that everyone using a computer all day should make sure to put some effort into ergonomics and not developing an RSI.
I need to let my arm rest on a wrist patch and/or armchair. Else I get inflammation. With my second keyboard (for my Mac) I didn't do this, as it stands behind the first one, and so now I have developed an inflammation.
The advice for vertical mouse I read before. But I like that my mice are wireless (Logitech G903 and Apple Magic Mouse 2).
There are wireless vertical mice, e.g. the cherry MW 4500, cheap enough to just test it. I really like that model, it comes with a dongle (so likely better latency than if it used Bluetooth) and uses regular batteries, so it can be powered with rechargeable ones. No idea which sensor is in there, likely nothing great, but it worked fine for me for work and gaming.
Yeah that seems like great bang for the buck. I'll try that one and if it works out I will use it till it breaks [EDIT: or try one of the mentioned ones and send it back within 2 weeks if not satisfied]. I read reviews and if it works out I will go for either BakkerElkhuizen Evoluent D Wireless (probably this one), R-Go Tools: Break HE, or Logitech MX Vertical.
Trackball attains too much dirt (heck, even mice do). Maybe BakkerElkhuizen ErgoSlider Plus would also work.
The evoluent mouse often pop up in this space, quite expensive. Not sure they are worth the price. I had a different r-go mouse in for a small test, felt OK, but not better then the cherry. The Logitech MX Vertical should be the mainstream option, but Logitech has quality issues, specifically by using switches that double click after a while. For the price not okay, even if it can happen with many different mice as well.
I really liked the cherry mouse given the alternatives I had at the time ;)
Supposedly the scroll wheel gets dirty quickly, and requires cleaning with contact spray and then some lube. It also has no support for pink apparently. People are claiming defect after X months. Either way, in EU I get 2 years warranty and the price warrants trying it out.
I did never need contact spray with it, during a few years now. The pinky finger might depend on hand size :)
I did have a broken button though, claimed warranty and got the money back, afterwards I soldered in a new button. Was easy enough, but I hope it does not happen too often! https://www.onli-blogging.de/2103/Kaputten-Maustaster-auswec... was my writeup.
Useful to know: Cherry has an additional manufacturer warranty for that mouse, which I claimed with the vendor.
Some of it might be inherent though. The data structure consists of immutable commits which are addressed by the SHA1 which depends not only on the snapshot but also the metadata as well as the SHA1 of the parents. You run into this immediately when someone thinks that they can maybe just tweak the commit message a little and end up with the same commit. Or drop the second parent of a merge commit in order to “forget” that line of history (effectively making a “squash merge”).
Imagine if someone was working on a SQL database and they thought that an `update` would not change anything in-place but instead would create a new immutable row and that they could reset back to the previous row (before the update) right after that since the immutable row (they thought) would still exist until some arbitrary garbage collection time. You would end up having to explain the same thing but kind of reversed.
The rule was to not use any external tools so it doesn't qualify.
But you're right. filter-repo is a great tool. You can even use pleasant Python "callbacks" instead of a hodge-podge of env variables and shell snippets.
The rule is arbitrary and unhelpful and only helps drive a rhetorical point, not actual advice: you really don’t want to do this without a tool as safe and fast as filter-repo. Even recommending filter-branch is just aligning the footgun slightly.
If a point is to be made that confirms OP: removing a file completely isn’t trivial, and thinking one did when one didn’t it is too easy.
It ships with git, so without extra tools, it is the implied solution to OP’s question, and the default choice for many.
I’m not saying they recommend it, as the question drives a rhetorical point. But it’s worth mentioning “git filter-repo” as a solution you will not stumble into as easily as the more difficult, brittle and slow “git filter-branch”.
What I said in my one-sentence-reply is that there are no non-deprecated, built-in tools that helps with this task in a streamlined manner. Which means by extension that it is not a trivial task.
It's not the same thing but Git Flow reminds me of Conway's Law. Just that the branches end up representing the dev-test-release workflow.
Another variation is that you reify branches according to whatever team that is working on it, like dev and qa and release. As in they have these literal branches and they need to follow a workflow diagram in order to remember what to merge into what and in what order. Then they mess something up and they go to StackOverflow to ask such easily inteligble questions like:
> We are using a standard branching model. But sometimes we find a bug in release/5613248 and need to deploy a hotfix. So naturally we branch hotfix/5613248 from release/5613248, fix the bug, do a PR against release/5613248/joe-the-gatekeeper, then Joe merges that into release/5613248 and also into pre-release/5613248, qa, and finally into develop. But sometimes we get weird merge conflicts when merging into for example qa or develop. How do we avoid that?
Someone who feels alienated from others is most probably not in a place where they can just explain who they are to other people, even if they have perfect self-understanding.
> So TLDR: This reads a bit like "clever" code or code-golfing, which isn't always a bad thing, especially if the codebase is mature and contributors are expected to mentally translate between these versions with ease.
You contradict yourself. You can’t deride it as “clever” (whatever the quotes mean) and then in the next breath say that it might be a practical style.
And yes, Rust code in the wild does look like this.
