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.

See also:

- The git staging area, the term literally everyone agrees with

- https://news.ycombinator.com/item?id=28143078

> “Your branch is up to date with ‘origin/main’”

> ... 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.

[1] https://stackoverflow.com/questions/27828404/why-does-git-st...

...

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”?

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.

Found on https://git.github.io/rev_news/2023/09/30/edition-103/

Can’t say I find the examples motivating. Just tells me more about the author’s tastes and proclivities than the utility of all this markup.

Nice deduction with limited utility.

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.

If you are fine with using `map` then I don’t see how this is “clever”. `zip` is basically “map2”.

What’s there to say? It works the same way as `zip` does for an iterator over a `Vec`. So if you understand `zip` as applied to an iterator over `Vec`, then you might understand `zip` applied to `Option`.

In other words:

Y is clear if you already understand X. Like how returning early is simple to understand if you understand if-blocks.

That’s the problem with replying to these kinds of questions: the response is so short and context-dependent that it can look curt.

EDIT: the first code is also inelegant in that it effectively checks if both values are `None` twice in the `Some` case: once in the if-condition and once in `unwrap()` (the check that panics if you try to unwrap a `None`).

> instead of one using e.g. .pg?

Why not just `.prolog`? In this day and age. (Maybe there’s some reason like “then I can’t put these source files on FAT filesystems”, I don’t know.)

Java seems to do fine with it’s longer-than-three-letters `.java`.

> I interpreted the quotes as implying that the children hadn’t developed a full human language, but rather the rudimentary beginnings of one.

A language, in other words.

I looked at this thread in the morning. Then I waited the whole workday to get home and read anecdotes like yours.

This is seriously cool. I never understood why people don’t talk more about this style of programming.

Define missing the point.

Welcome to modernity.

> 500 billion people

* million

> something that created us, is something almost all of us have.

Buddhism claims that nothing created us. Samsara is beginningless and wasn’t architected by anything. And that’s just 500 billion people or so.

> Even something as simple as prepending the site name in ROT13 to a reused password greatly reduces your exposure to the sort of background infosec threat radiation that's like 99.99% of the threat model for most people

If one goes with the infosec advice that you should calculate the entropy of passwords based on the assumption that the attacker knows the password scheme, then this password scheme provides zero entropy. So if there is zero cost for the cracker to pwn you as well as all the others that don’t have this kind of leetspeak obfuscation then you’re still pwned.