We have quite a few wiki pages in http://wiki.jira.x-y.de/. Now we are moving to a new wiki in http://wiki.jira.a-b.com.
Can someone suggest what is the best way to move wiki pages from the new one to the old one (along with all the images, attachments, etc)? Do we have to manually copy paste each page?
If you are moving the majority of the pages, the easiest way is to do a space export from the source, and then re-import the space on the destination site. This lets you cherry-pick just the spaces you want, and then delete the (hopefully-small) quantity of pages you do not want.
Note that you must have compatible Confluence versions to use this procedure. (See the re-import link for more details on how to determine "compatible".)
Related
I want to update Topic/page titles on my GitHub wiki (which is currently using Markdown syntax). When I do that using the GUI it renames the Markdown files, and breaks all of the links.
I know that I can rename the Topic files in the Git repository and push the changes, but that doesn't help the broken links.
Is there a way to avoid this, and make GitHub Wiki's behave more like other Wiki products? I could not find an better way on GitHub documentation.
Welcome to StackOverflow. As best I can determine you cannot rename a GitHub Wiki page without its markdown file also being updated to the new name. The two are tightly coupled.
This Web Applications (StackExchange) Question has some alternatives you may consider, i.e. instead of renaming the page, create a copy. Then edit the original page so that it directs visitors to the new page via a link. This way the original page link remains valid but directs visitors to the new page.
Background:
When you land on a GitHub repository page on the website, it automatically renders the README.md file that lives on the root.
Question:
I want to have a separate one for iOS and Windows, and display the appropriate one based on the operating system the page is viewed on/from. Is this something you could do?
My current in-mind solution is to just have a super large file with clickable tags for the iOS and Windows sections, so that a user can click and jump to that section - this is not ideal though, as this file would grow extremely large (it is used as a setup guide).
I don't believe it's possible to show a different README based on the viewer's OS, and I believe that's a good thing. I've frequently had to look something up on one device and use it on another.
What's to say a user wouldn't need to look up the Windows instructions from their iPhone?
My current in-mind solution is to just have a super large file with clickable tags for the iOS and Windows sections, so that a user can click and jump to that section - this is not ideal though, as this file would grow extremely large (it is used as a setup guide).
This sounds like a good solution to me, though you're right that it could get unwieldy if you've got a lot of content.
Why not use GitHub's wiki feature for detailed documentation? Windows and iOS could each have their own page, or pages. Your README can still contain some basic information and link to the wiki.
Alternatively, you could publish a website using GitHub Pages using content from a dedicated gh-pages branch or a docs/ directory in your master branch.
Since the a gitpitch presentation is displayed at the location
https://gitpitch.com/user-name/repository-name
only one gitpitch presentation can be created per repository.
I would like to use gitpitch to create more presentations, but it feels like creating a new repository for every presentation is too much.
Is there any way to go around this limitation?
E.g. display presentations with a more specific URL, something like
https://gitpitch.com/user-name/repository-name/sub-folder
Had a hard time finding the answer in the documentation but this worked for me. If you put your PITCHME.md file in your subfolder, then use the following path.
https://gitpitch.com/user/repo/branch?p=subfolder
with the key component of placing ?p=subfolder after the branch name.
More can be found here https://gitpitch.com/docs/git/branch-many-slideshows
You can create multiple presentations in a single branch within repo. You do not have to branch for each new presentation.
Take a look at the Asset Sharing and Modular Markdown pages on the GitPitch Wiki for details. The asset sharing page explains how you can create and share any number of presentations within in a single repo. The modular markdown page explains how you can break the markdown for your presentations into multiple files and even share markdown files across multiple presentations.
I want to give the users of my repository some info on how they should report issues and what info they should provide. What is the best way to present this information, and where? I was hoping there would be a readme on the /issues tab but there seems no such option. Maybe I should create an 'issue' named 'Read before creating issue'?
If you're worried about the added clutter in the root directory of your project.
You can put CONTRIBUTING.md, ISSUE_TEMPLATE.md, and PULL_REQUEST_TEMPLATE.md files in the project directory.
Yes, it will easy both parties to creating the issue or pull request fill all info.
What is the best way to present this information, and where?
Put it into your this three files and file name should be same as here.
More information about it
I'm not sure if github exclusively provides any such feature. Alternatively, you could include the guidelines (or link to- how to create an issue) in the readme.md file at the main branch of the project (e.g. a section #HowToCreateAnIssue along with other sections). At least, this is what I follow.
For my Projects (and I guess thats how most People will handle it) I added a readme to the Projects repository and create a link to the most important wiki pages. The wiki will be managed as an additional repository and provides possibility to store Information and updates as needed.
If you also have a Webpage created this could also be a place to add some Information on how to participate as a contributor.
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