civopsec

> Anyway, I think a better wording might be "Your branch matches origin/main"

That’s fine. And also less partial to the implicit view that the remote ref is the thing you are supposed to be “up to date” with.

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.

> The expectation is that the information you get is up-to-date as of the time you started the status command,

Why is that the expectation of a “distributed VCS”?

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.

Aye thanks for the recommendations.

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.

That's a different subject that my comment did not try to address.

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.

> Even recommending filter-branch is just aligning the footgun slightly.

Who recommended it?

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.

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.

> Without using any external tools.

git-filter-branch is the only mass-rewrite helper tool that I know of in git(1) and it's deprecated.

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?

Slight hyperbole here.