Rename MediaWiki to Wikitext

[Nixinova]

Wikitext is the main name of the syntax; MediaWiki is the wiki software itself.

Add extension .wikitext: search results (31K+)

[Nixinova]

I'm surprised this sequence of events worked...

Though I think it screwed up the test runner...

[Alhadis]

This might cause problems with github/markup, which is currently unmaintained and without a GitHub staff member interested in taking over responsibilities. Since MediaWikitext isn't commonly used on GitHub, it's unclear when a PR to fix the old names would get merged upstream.

Bear in mind that Linguist and Markup are two entirely separate pieces of software, and two different teams of people at GitHub are responsible for maintaining them. Or should I say, only one team.

I'm surprised this sequence of events worked...

Long-winded explanation unrelated to this PR

When you delete a branch—either locally or on GItHub—the comments that referenced it still linger on in Git's object-tree (until they're garbage-collected). In fact, a branch is little more than a pointer to a commit object. Each commit holds a link to the one that came before it (the so-called “parent“ commit), so the entire history remains intact. And yes, that's bad news if you accidentally publish sensitive data.

On the other hand, it can also be a lifesaver if you later regret deleting a branch with a detailed history. Provided, of course, you know the hash of the last commit. This happened to me with file-icons's v2 branch, which I deleted after a tagged v2.0.0 was squash-merged into master for a long-awaited release. Later on, part of me wished that I'd kept that branch, purely for the sake of history. Only because of my obsessive cross-referencing did I manage to recover most of the lost branch, thanks to the lost commit being listed as a cross-reference.

I'm still stuck on how to recover the missing week between file-icons/atom@c5ee547 and the final merge-commit. 😞 @lildude, any chance you're able to help here?

[lildude]

🤔 ffb9330 is the commit where things went "wrong". Three shas are involved:

2 parents 7b2f8ca + cfafb37 commit ffb93304a79541b631d598a9f9d679224a9d45f2

GitHub only knows about the middle one (current master HEAD), but not the other two (your change which moved the entry down and the final resulting merge commit) which is likely to be in the branch you deleted. As you've force-pushed to GitHub using the same branch name, you'll need to trawl your local clone to find the original commits. You can probably find these using git reflog and git log and then hard-reset, branch, cherry-pick etc to get back your original wikitext branch.

As for ...

This might cause problems with github/markup,

This is a good point and I have absolutely no idea how this rename would impact things; I know very little about that repo and how it applies to GitHub.com.

[Alhadis]

@lildude Just in case you missed it, I pinged you in my earlier comment:

I'm still stuck on how to recover the missing week between file-icons/atom@c5ee547 and the final merge-commit. 😞 @lildude, any chance you're able to help here?

[lildude]

@Alhadis I think the same method could work here too if you've still got the original repo locally. Things like git reflog, git fsck --dangling and git log --walk-reflogs might help show the missing commits. My only concern is gc is likely to have cleaned things up since then.

[Alhadis]

@Alhadis I think the same method could work here too if you've still got the original repo locally.

Unfortunately, I don't. :sad I definitely would've dug out dangling objects if they were in my local checkout. As for the commit I did I manage to recover, I did so after several years had passed, which convinces me there might be a reference to it somewhere (possibly from some user's fork).

I'm wondering if dangling commits are included with the huge archive GitHub sends you when you request a copy of your data...

[Nixinova]

you'll need to trawl your local clone to find the original commits

Can I just git reset <master's sha> + git clean -f and redo the commits and then doing git push -f? Would that work? (Or is that what gets me into this situation...)

[lildude]

Can I just git reset <master's sha> + git clean -f and redo the commits and then doing git push -f? Would that work?

That would probably work.

If you've still got your original local clone, you could probably fix things using:

$ git revert 9a1f0cad8e7efb4b224feb730e09bc0e99cd3165
$ git cherry-pick 7b2f8caeba53d2fc67693efa729fb6f6afe1eb7b

... and then correct the name as 7b2f8caeba53d2fc67693efa729fb6f6afe1eb7b only moves the section.

[Nixinova]

Added extension wikitext which has 31K results: search

[lildude]

This might cause problems with github/markup,

This is a good point and I have absolutely no idea how this rename would impact things; I know very little about that repo and how it applies to GitHub.com.

I've looked into the markup code and I think we should be OK with this rename because we're keeping mediawiki as an alias but I'd need to test this to be sure. I'll try schedule some time to test this in the next few weeks.

[lildude]

I've tested and we look to be good to merge this. All three of the files in this gist render correctly when I test with these changes in place. For those looking at this later, the last file doesn't currently render.

So nothing is broken and we gain wiki rendering of .wikitext files 🎉