I created a code wiki. Worked nicely.
Decided to take a look at published wikis so added one and then found that it overrode the code wiki (wtf?)
Then I discover that I can't go back (double wtf?)
Eventually, after much faffing about I found this:
https://learn.microsoft.com/en-us/azure/devops/project/wiki/provisioned-vs-published-wiki?view=azure-devops#delete-project-wiki
Talk about a PITA, but it worked. This morning I look at the wiki again and the empty published wiki is back.
However, the above solution no longer works. Running "az devops wiki list" just shows the single codeWiki. No mention of the projectWiki and so, I have no repositoryId to call DELETE against.
So, two questions:
How do I get back to the codeWiki?
Has there been any indication of when MS are going to fix this ridiculous manual delete situation?
You can select your wikis here:
You can refer to the document if you want to delete your wiki pages:
Code wiki:Edit, rename, or delete pages
Project wiki:Edit and delete wiki pages
Related
Have read about differences of the two here: https://learn.microsoft.com/en-us/azure/devops/project/wiki/provisioned-vs-published-wiki?view=azure-devops.
Would like to try out code as wiki, however, want to have a backup plan in case I want to switch back to the provisioned one.
Once I have tried the "published code as wiki" does anyone know how to import the contents from a repo backup and make it "provisioned one"?
If you have already created a project wiki and add a code wiki, the two wiki's will coexist (see screenshot):
If the Code wiki is not the way to go, you can unpublish it only leaving the project wiki in place.
If the Code wiki is the way to go, removing a provisioned (project) wiki doesn't seem to be an option in the UI. Still, there are options to Delete default project Wiki in Azure DevOps using the API.
As another solution said, you can unpublish the Code wiki if you want to keep the project wiki.
If you want to keep only the Code wiki then you can download the project wiki as a git repo and replace all content. After having pushed the new content you can delete the (old) Code wiki.
Editing history will be lost but that is hopefully not important to you.
Because the Twitter algorithm is Weird™️, this super old tweet come through my feed very recently and I decided I'd like to try out the gist it links to.
Unfortunately, sometime in the 5 years since that tweet was sent, the gist has either been deleted or made private1. Fortunately, I found the gist on the Wayback Machine. Problem solved! Right?
I could just copy-paste the file into a gist of my own for posterity, but I notice that there were 25 forks as of the Wayback snapshot. According to this documentation it seems like...
...one of the existing public forks [should have been] chosen to be the new parent repository.
...assuming Gists have the same behaviour as vanilla repositories. Sadly, Wayback has not cached a list of who those forks belong(ed) to. If I want to follow along with that gist and its forks, how do I find them?
1: fwiw - it looks like the original author deleted their GitHub account very recently
I was able to find the forks by going to gist.github.com and copying a string from your wayback link in the search box (seeyouspacecowboy.sh).
This search provided me with 2 search results, one of which showed "25 forks". Clicking that gist allowed me to see all 25 forks of the Gist.
Previously I remember that I could go into any repository and see how many codes it has how many lines with or without comments, what languages is it made of with how much percentage, how many man hour was used for development of that repository. I could see all of them on my browser. No code was required.
Now, I cannot find any option on Github. Is this facility changed, moved or removed?
There is an open source project made by #vdaubry : Github Awards
You can get all the information you described and more.
Does the wiki that installs with a GitHub repo support directories? Our wiki is cluttered with pages, and we are looking for a way to organize them better.
We tried pulling the repo, creating local directories, and moving things around, but when committed back, the wiki didn't pick up the changes.
I was having the exact same issue and tried variants of what you tried. Nothing stuck. Asked GitHub support about it and received a reply that essentially said "No, but we'll let the developers know that people are interested in this feature."
So the short answer is "No", and the long answer is "No, but maybe in the future."
Actually, it looks like github added support for directories recently.
I was able to do the following:
Move an existing markdown file to a new directory.
Create a new markdown file in an existing directory (created in the former step).
Create a new markdown file in a new directory.
In all cases, the existing pages were still there and new pages were added.
The one constraint that remains is that your file names must be unique. If you have more than one file with the same name, only one of them will show up in the wiki (I'm not sure which.. ).
The GitHub wiki (aka Gollum) does use directories but not in the way you may expect.
The documentation on the Gollum wiki could use some work but this is what I have figured out mostly via testing.
All files appear in the root of the wiki no matter where they are placed in the repo.
_Header, _Footer and _Sidebar files are per-directory, but inherited if there is
none present in a child folder.
File links can be relative to the source file (keep your files with your content).
So, if you want directories for namespacing you are out of luck. Consider using the {namespace}-{page} scheme for namespacing.
It's not the an ideal solution but the workaround would be to create a custom sidebar where you create a table of contents with links to your pages. I find this to be better than folders anyway because it allows you to have a link to a single page under multiple hierarchies.
Actually, there is still a limitation. Yes, you can add 1 level (so, 1 subfolder). But that's it! I refactored my whole documentation layout, creating multiple levels of subfolders for organisation, but that was a no-go.
sigh
I must say: I'm appalled by this Gollum thing. I'm surprised Github even picked it up.
Well, that's a disappointing missing feature!
What I try to do is to actually have directories under a docs directory and in each one, a README.md file.
Not great...but works for documentation and organizes stuff.
If you want to go further, you can have a different branch only with these files.
Still no intention of adding this 9/2022.
https://github.com/orgs/community/discussions/23914
Is it possible to completely remove an issue from the GitHub issue tracker?
No, the github API only allows you to open/close/reopen issues. Here's the Issues API docs.
You can edit an existing issue (let's say if it's a duplicate) and you can change the title, description and target milestone to be something completely different. That's as close as you can get to removing the ticket, AFIK.
Update Nov 2018: You now can delete issues if you are a owner of the repository!
See "Github - remove issues entered in error"
https://docs.github.com/en/github/managing-your-work-on-github/deleting-an-issue mentions:
People with admin permissions in a repository can permanently delete an issue from a repository.
For other people (without permission), questionto42's comment shows that you can ask to GitHub support for the issue to be deleted, as illustrated here.
At May 2018, original answer:
Three 8 years later, and closing issues remains the answer (still no deletion possible).
See "The Ghost of Issues Past", where GitHub advise to check and close:
issues opened over a year ago state:open created:<2013-01-01
the ones I'm involved with involves:twp state:open created:<2013-01-01
and those not updated in the last year involves:twp state:open updated:<2013-01-01
For posterity: Deleting issues would be a bad thing, since in general they can be targets of associations on github.
But if you are willing to sacrifice the collaboration info, here is a "whack it with a sledgehammer" approach:
Clone your original repo.
Copy your issues via the Issues API.
Delete the original repo; alternatively, chose a new name for your new repo.
Re-create a new repo based on your clone.
Re-create the issues you want to keep via the Issues API.
I imagine this could potentially lose a lot of other linking information as well such as forks, pull requests, etc.
Public feature request
I wrote to GitHub in 2014-08 and https://github.com/jdennes replied by email:
Thanks for the suggestion. It's only possible to edit/clear the issue content currently. However I've added a +1 to this suggestion on our internal Feature Request List.
confirming it was not possible.
Best workaround so far
set the title to something that will never conflict with any search, e.g. a single dot ..
This may not hide the history of your blunder entirely because of the automatic undeletable "changed the title to" comments.
make the body empty
GitHub staff has the power
If something is a security issue, contact GitHub staff, they usually reply quickly, and are able to remove issues for good as can be seen at: http://archive.is/OfjVt which has issue 1 and 3 but no 2.
You can delete the entire repo if it's really important.
Possible workaround
As of 04/2019 not all issues can be deleted current work around is to edit the issue then delete the edit history, the only downside is that the issue still exist and the old title could be seen.
You could by just asking to github to ban the user that created the issue 😁
Source: https://github.com/isaacs/github/issues/253#issuecomment-290944938
Users are unable to do this, including repository owner.
But issues can be deleted by Github support. One may contact them and request deletion. It may be delayed or refused but it is an available option that can be used.
Still impossible. Another workaround to the ones suggested in the other answers is to label the issue as "deleted" (or any other label you might fancy better), to be able to filter them out if you use the github API to retrieve them. Obviously you should use that specific label only for this purpose, setting the label when you close the issue.
You can create a new repository.
Transfer (yeah it is possible) unwanted issues to the new repository.
Then delete the new repository.