You can recover the history using their tooling build on top of their bugtracker and GitHub. Specifically they capture the discussions and all small changes over time in their skara tools and are prepared to leave GitHub if needed. They had multi de adres experience and had multiple prior code repos. Still do if i understand as the Oracle team has the sun and bea code repositories pre openjdk preserved.
Hmm. Is this about Github or Git? Dependency on Github seems tangential to treating Git as a first class record of history.
edit: rereading, I guess the implication is that there's tooling built on top of Github outside of Git, so Git history is indeed not meant to be contain some things.
> Articles for Deletion votes -- original with comments
>
> Summarizing it, 5/7 for delete have accounts, and 1/4 for keep have accounts. Not along after the final vote, a Wikipedia admin deleted the article. Being a little bit lax with my language, the majority's consensus agreed that Odin isn't notable, and the article had no reliable sources.
important clarification about a popular misconception: "Articles for deletion" discussions on English Wikipedia are not decided by vote.
What kind of happens is that there are some people who invest their lives in Wikipedia, their opinions is what ends up mattering.
This has boths pros and cons. The good thing about it, is that these people are deeply invested in Wikipedia and therefore have a lot of incitament to do what (they believe at least) is the best for Wikipedia.
The downsides are: (1) that just because you invested a lot of time into Wikipedia you don't have biases (2) you are not immediately qualified to determine whether some article/source is bad or not from a factual point of view.
Also, it's very HARD to become a regular contributor, because you'll have to invest an insane amount of time initially to build up goodwill and reputation, when at the same time anything you do might just get reverted because someone thought it was too much detail or bad in some other way.
So it's a very punishing environment which makes sure that the actual group of Wikipedia editors is a fraction of what one could expect. (Also, the Wikipedia markup... it's really the worst dialect of Wiki syntax)
Anyway, all of this is probably not good for Wikipedia in the long run. LLM's will be much better than humans at creating "beginner" articles, and it will be increasingly hard to know what's LLM-authored. So I expect Wikipedia to go the way of Stack Overflow in the long run.
Sounds like you are describing Grokipedia (Grok), where the general public has rejected it as a replacement for Wikipedia. Way too much hallucinating, tainted algorithms reflecting political preferences, gossip, and unverified or disreputable sources.
And as an example of bias: I personally witnessed a wikipedia editors adding their own interpretation of a certain written article. This interpretation was very politically biased and not justified by the text, but these were influential wikipedia editors so that it stayed in. I then asked the author of the article on Twitter if this interpretation was correct. I was unambiguously told NO. This information (including the public twitter conversation), was rejected by the wikipedia editors because it was first hand accounts.
Which led to the rather odd result that the interpretation of an article's message by a Wikipedia editor was favoured over the explicit statement by the article's author.
Here I would have thought that it would have been prudent to simply leave out that part of speculation, but they adamantly insisted it should stay.
I must add that this happened on Swedish wikipedia, not the main English Wikipedia – which I actually found much more balanced. But the problem is that this mechanism exists in the first place.
It was at the time (5-10 years ago?) well known that the Wikipedia of some language – I don't recall which one – was at the time pretty much hijacked by a group. Oh, wait I found it - the Croatian Wikipedia.
This is unlikely to happen to the main Wikipedia, but it does demonstrate a certain brittleness and risk of bias in the system.
You describe the concept of being taken seriously. We use this a lot in real life. It's arguably a very useful concept.
Wikipedia has elaborate guidelines for everything but users have their own ideas.
For example, the guidelines don't grant you the privilege to delete contributions because you've decided not to take the editor seriously.
Imagine reverting and putting it in an edit summary: I don't take this guy seriously
If there are insufficient independent so called reliable sources to establish the so called notability of Odin but it does have 11k GitHub stars. Then you put an infobox on the article that describes the problem.
You then attempt to find sources. If you find nothing that Wikipedia accepts you might have a conversation about sources for programming languages.
Then you end up reading things like the AFD for hackernoon (22 May 2026) Not even worthy of a stub?
Then you wonder how any programming article established so called notability.
I've just looked at php and I don't see any reference from mainstream media, definitely nothing specifically about php.
You've openly stated that you were intentionally acting in bad faith, hounding other editors to provoke them and doing so while logged out to evade scrutiny. Retreating to "you can't prove I did anything wrong" is not the defense you think it is.
Assuming good faith is not a suicide pact. If you consistently aim to disrupt the project then you obviously should be CBANed. I can't comment on the evidence available in your block discussion, only what you've presented here.
I have no block discussion. I just read other peoples talk pages.
Besides from the obvious cases it is quite subjective what disrupting the project even means.
I'm not trying to stop the character assassination article but I will be a nuance to the process. I will argue this valuable to the project.
Im kinda curious, if a topic is considered a fringe theory, say fringe physics (where the consensus among surviving editors is that it must be denounced as fake until published in a high quality journal) would you oppose including other high quality sources or would you exclude them to help portray the topic as fake?
If one was to reliably demonstrate 1) there to be [say] a giant time travel laboratory, 2) a hundred million research budget and 3) prominent names involved.
I will not concede that it is at all "subjective" what being disruptive means in the specific case of your intentionally bad-faith trolling. You may choose to categorise that either as an obvious case or refer to my previous comments.
if IDE supports converting them into clickable links, then scrolling through a log in its Git integration (kinda like `git log --oneline`) will be a convenient list of links to issues. If the commit messages are good, you just skip over the Jira issue/ticket key/ID. If what you want is to see the requirements of a feature or steps to reproduce of a bug or some other context for the ticket, then a clickable link is very convenient. Of course, sometimes it does make sense to include some of that information in the commit message as well.
When working in big teams, it can be very hard to increase the usefulness of commit messages. On the other hand, enforcing inclusion of a Jira issue key in commit messages is easy to implement. Relying on issue tracker descriptions can be a difficult proposition as well. Quality of individual ticket descriptions can be low; depending on how responsibility for maintenance is handled, the bug tracker migrations can sometimes be handled improperly and information can be more easily lost than in a Git log.
The difference is that the Jira ticket is for everyone involved in a project (business analyst, UI designer, QA, support, DBA), while commit messages are written with developers being almost exclusive audience. PRJ-123 might explain why an end user might need it, but the commit message explains why the change (diff) is the way that it is. The ticket answers requirements-level questions, the commit message answers code-level questions. Commit messages are useful both during the review and when a future maintainer is reading the code.
> Additionally, if a change requires multiple commits, you don't want to be repeating the justifications for the entire feature in every commit message. It's redundant. But the commits will all be tied together by the ticket reference in the commit message.
Different commits do different things, so require different justifications. Here's a fictional example to demonstrate:
First commit:
[PRJ-123] Server: extract class Foo
In the next commit, we're going to need to re-use the foo logic from
class Bar. Extract new class Foo from Bar to make it available for
re-use.
Second commit on the same ticket
[PRJ-123] Server: use Foo in Baz
The users of BazClient need to be able to see foo information in the
baz dialog. Include Foo in the data sent by class Baz in the server.
Side note: the user might not even know that they are looking at Foo and Baz, it might be called something else in the UI they are shown. Whether or not this needs to be included in the commit message depends on the situation.
And later in a commit fixing a bug:
[PRJ-456] Server: check ID for null in Foo
When class Foo was extracted from Bar in commit deadbeef ([PRJ-123]
Server: extract class Foo, 2026-06-06), a null check for the field
ID got lost by accident.
Check the field ID for null in class Foo to avoid a
NullPointerException when a foo event is sent to Baz.
Personal preference I guess, but to me all of those commit messages are way too wordy. I'd probably have:
[PRJ-123] Refactor Foo out from Bar
[PRJ-123] Include Foo data in BazClient
[PRJ-456] Null-guard on Foo ID to avoid data loss
Bug introduced in commit deadbeef
And then in PRJ-456, I'd also have the comment about bug introduced in commit deadbeef, and link the two JIRAs if it was significant, or just mention it in a comment for a minor fix.
For me personally, nothing else in your commit messages adds value that can't be seen trivially from glancing at the changes.
Git is more robust than Jira. Git log is accessible offline. Jira descriptions exist only as long as people managing the Jira instance are competent and are migrating the necessary data correctly when migrations are needed. Even migrations from one Jira instance to another (e.g. when companies get acquired and two Jira servers get merged) can be extremely brittle.
It's fair that maybe such simple trivial changes don't deserve such a wordy commit message. But these are just fictional examples that I came up with on the spot. Refactorings, new features, and bugfixes can all have various levels of complexity.
A good commit message helps answer the "why?" questions first and foremost. If a diff is fairly large, pointing out the most important change can be useful. Explanations for non-trivial dataflow can sometimes not make sense in separate documentation, but still be relevant in a commit message.
Much of such issue tracking systems may be better in the repo in the first place. A Jira issue could just be a markdown file committed in the repo. A code review could just be commits of inline remarks/comments.
Maybe there is some value to slapping on a web interface on top of that data for ease of use, but as to where the data lives I'm leaning towards putting everything in repo.
> archive.is is one of the domains of archive.today, which used its end users for a DDOS attack on a blog.
Please provide evidence for your claim. The wiki rfc [5] that you linked doesn't provide any DDOS evidence at all, which is odd for wikipedia.
> This caused English Wikipedia to deprecate it with the end goal of blacklisting
This appears to be a concerted effort to blacklist archive.today by unknown actors. There were at least 3 attempts with odd efforts to sway the vote [1][2][3] (the notes in the sidebars at those Wiki RFCs document these actions by bots and others), and a successful attempt to undo the blacklist [4], and then yet another attempt [5].
I'm curious as to why you did not include this very relevant background information in your comment?
Complaining about bad people is fun, don't get me wrong... but your post doesn't contain an alternative archive link. You're just siphoning people into your soapbox.
The link they did include seems to have a pretty comprehensive list of alternatives. Complaining can be fun, but it doesn't really make sense to penalize them for not being prescriptive about alternatives when the exact point they're trying to make is specific resources for this sort of thing can be prone to abuse.
Just like complaining about Amazon (be it as an employer or as a service provider), without providing an alternative, is siphoning people into a soapbox?
I, for one, found out about the archive.* situation recently, and am totally glad someone like the commenter pointed it out. My wanting to bypass paywalls to read content doesn't justify supporting the owner's behavior - not even close.
According to the original reporter, the bug is still exploitable and that's why the issue on the bug tracker got hidden again.
> OH NO I JUST REALIZED THIS IS NOT ACTUALLY PROPERLY FIXED AND STILL WORKS
> even worse, edge no longer even makes the download menu pop up, so it's completely silent js rce that keeps running even after you close the browser !!
> all from just visiting a single website once !!
> issue set to private again, hopefully it'll get fixed properly this time :p
