This should allow averagenon-technical users to keep up with development, without reading Github comments or knowing how to program.

;)

The writer will need to tag things down, to minimal details, for the sake of languages that they don’t care about.

Sure and that’s likely a good bit of work.

However, you must consider the alternative which is translating the entire text to dozens of languages and doing the same for any update done to said text. I’d assume that to be even more work by at least one order of magnitude.

Many languages are quite similar to another. An article written in the hypothetical abstract language and tuned on an abstract level to produce good results in German would likely produce good results in Dutch too and likely wouldn’t need much tweaking for good results in e.g. English. This has the potential to save ton of work.

This issue affects languages as a whole, and sometimes in ways that you can’t arbitrate through a fixed writing style because they convey meaning.

The point of the abstract language would be to convey the meaning without requiring a language-specific writing style. The language-specific writing style to convey the specified meaning would be up to the language-specific “renderers”.

(For example: if you don’t encode the social gender into the 3rd person pronouns, English breaks.)

That’s up to the English “renderer” to do. If it decides to use a pronoun for e.g. a subject that identifies as male, it’d use “he”. All the abstract language’s “sentence” would contain is the concept of a male-identifying subject. (It probably shouldn’t even encode the fact that a pronoun is used as usage of pronouns instead of nouns is also language-specific. Though I guess it could be an optional tag.)

Often there’s no such thing as the “default”. The example with pig/pork is one of those cases - if whoever is writing the article doesn’t account for the fact that English uses two concepts (pig vs. pork) for what Spanish uses one (cerdo = puerco etc.), and assumes the default (“pig”), you’ll end with stuff like *“pig consumption has increased” (i.e. “pork consumption has decreased”). And the abstraction layer has no way to know if the human is talking about some living animal or its flesh.

No, that’d simply be a mistake in building the abstract sentence. The concept of a pig was used rather than the concept of edible meat made from pig which would have been the correct subject to use in this sentence.

Mistakes like this will happen and I’d even consider them likely to happen but the cool thing here is that “pig consumption has increased”, while obviously slightly wrong, would still be quite comprehensible. That’s an insane advantage considering that this would apply to any language for which a generic “renderer” was implemented.

It ends like that story about a map so large that it represents the terrain accurately being as big as the terrain, thus useless.

As I said in the top, you’ll end with a “map” that is as large as the “terrain”, thus useless. (Or: spending way more effort explicitly describing all concepts that it’s simply easier to translate it by hand.)

I don’t see how that would necessarily be the case. Most sentences on Wikipedia are of descriptive nature and follow rather simple structures; only complicated further for the purpose of aiding text flow. Let’s take the first sentence of the Wikipedia article on Lemmy:

Lemmy is a free and open-source software for running self-hosted social news aggregation and discussion forums.

This could be represented in a hypothetical abstract sentence like this:

(explanation
 (proper-noun "lemmy")
 (software-facilitating
  :kind FOSS
  :purpose (purposes
            (apply-property 'self-hosted '(news-aggregation-platform discussion-forum)))))

(IDK why I chose lisp to represent this but it felt surprisingly natural.)

What this says is that this sentence explains the concept of lemmy by equating it with the concept of a software which facilitates the combination of multiple purposes.

A language-specific “renderer” such as the English one would then take this abstract representation and turn it into an English sentence:

The concept of an explanation of a thing would then be turned into an explanation sentence. Explanation sentences depend on what it is that is being explained. In this case, the subject is specifically marked as a proper noun which is usually explained using a structure like “<explained thing> is <explanation>”. (An explanation for a different type of word could use a different structure.) Because it’s a proper noun and at the beginning of a sentence, “Lemmy” would be capitalised.

Next the explanation part which is declared as a concept of being software of the kind FOSS facilitating some purpose. The combined concept of an object and its purpose is represented as “<object> for the purpose of <purpose>” in English. The object is FOSS here and specifically a software facilitating some purpose, so the English “renderer” can expand this into “free and open-source software for the purpose of facilitating <purpose>”.

The purpose given is the purpose of having multiple purposes and this concept simply combines multiple purposes into one.
The purposes are two objects to which a property has been applied. In English, the concept of applying a property is represented as as “a <property as adjective> <object>”, so in this case “a self-hosted news-aggregation platform” and “a self-hosted online discussion forum”. These purposes are then combined using the standard English method of combining multiple objects which is listing them: “a self-hosted news-aggregation platform and a self-hosted online discussion forum”. Because both purposes have the same adjective applied, the English “renderer” would likely make the stylistic choice of implicitly applying it to both which is permitted in English: “a self-hosted news-aggregation platform and online discussion forum”.

It would then be able to piece together this English sentence: “Lemmy is a free and open source software for the purposes of facilitating a self-hosted news-aggregation platform and online discussion forum.”.

You could be even more specific in the abstract sentence in order to get exactly the original sentence but this is also a perfectly valid sentence for explaining Lemmy in English. All just from declaring concepts in an abstract way and transforming that abstract representation into natural language text using static rules.

I am not. Read the context mate.

They were mentioned because a file they are the code owner of was modified in the PR.

The modifications came from another branch which you accidentally(?) merged into yours. The problem is that those commits weren’t in master yet, so GH considers them to be part of the changeset of your branch. If they were in master already, GH would only consider the merge commit itself part of the change set and it does not contain any changes itself (unless you resolved a conflict).

If you had rebased atop of the other branch, you would have still had the commits of the other branch in your changeset; it’d be as if you tried to merge the other branch into master + your changes.

The thing is, you can get your cake and eat it too. Rebase your feature branches while in development and then merge them to the main branch when they’re done.

Certainly better than the U.S. in that regard but I wouldn’t consider Germany “resilient” either.

Note that I didn’t say that you should never squash commits. You should do that but with the intention of producing a clearer history, not as a general rule eliminating any possibly useful history.

you also lose the merge-commits, which convey no valuable information of their own.

In a feature branch workflow, I do not agree. The merge commit denotes the end of a feature branch. Without it, you lose all notion of what was and wasn’t part of the same feature branch.

The only difference between a *rebase-merge and a rebase is whether main is reset to it or not. If you kept the main branch label on D and added a feature branch label on G’, that would be what @andrew@lemmy.stuart.fun meant.

You should IMO always do this when putting your work on a shared branch

No. You should never squash as a rule unless your entire team can’t be bothered to use git correctly and in that case it’s a workaround for that problem, not a generally good policy.

Automatic squashes make it impossible to split commit into logical units of work. It reduces every feature branch into a single commit which is quite stupid.
If you ever needed to look at a list of feature branch changes with one feature branch per line for some reason, the correct tool to use is a first-parent log. In a proper git history, that will show you all the merge commits on the main branch; one per feature branch; as if you had squashed.

Rebase “merges” are similarly stupid: You lose the entire notion of what happened together as a unit of work; what was part of the same feature branch and what wasn’t. Merge commits denote the end of a feature branch and together with the merge base you can always determine what was committed as part of which feature branch.

…or you simply rebase the subset of commits of your branch onto the rewritten branch. That’s like 10 simple button presses in magit.

Because when debugging, you typically don’t care about the details of wip, some more stuff, Merge remote-tracking branch 'origin/master', almost working, Merge remote-tracking branch 'origin/master', fix some tests etc. and would rather follow logical steps being taken in order with descriptive messages such as component: refactor xyz in preparation for feature, component: add do_foo(), component: implement feature using do_foo() etc.

For merge you end up with this nonsense of mixed commits and merge commits like A->D->B->B’->E->F->C->C’ where the ones with the apostrophe are merge commits.

Your notation does not make sense. You’re representing a multi-dimensional thing in one dimension. Of course it’s a mess if you do that.

Your example is also missing a crucial fact required when reasoning about merges: The merge base.
Typically a branch is “branched off” from some commit M. D’s and A’s parent would be M (though there could be any amount of commits between A and M). Since A is “on the main branch”, you can conclude that D is part of a “patch branch”. It’s quite clear if you don’t omit this fact.

I also don’t understand why your example would have multiple merges.

Here’s my example of a main branch with a patch branch; in 2D because merges can’t properly be represented in one dimension:

M - A - B - C - C'
  \           /
    D - E - F

The final code ought to look the same, but now if you’re debugging you can’t separate the feature patch from the main path code to see which part was at fault.

If you use a feature branch workflow and your main branch is merged into, you typically want to use first-parent bisects. They’re much faster too.

Merge is not the issue here, rebase would do the same.

To the person receiving the money, it is worth it. Else they wouldn’t be doing it.

Yes and that’s precisely the point. You can make the decision not to pay and there are good reasons to do so (I do so too) but you must recognise that someone is still not getting paid for their work.

Cool story bro but you clearly still didn’t even read the first sentence of what I wrote.

What a great argument! You didn’t even read the first sentence…

It isn’t an ethical concern and hasn’t been since the 90s.

You’ll have to explain to me how not compensating someone for their work has been ethical since the 90s.

Security knowledge and ethical concerns are two separate things. Whether we like it or not, we pay online creators through private data we must give to entities who will use it against our best interests.

.