You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Gitea Wiki does not count and show the available page(s).
Nearly the same as a repository does not show the size/count of files included inside.
But in Wiki this is important to show, as nobody knows that there is an entry without looking into it - a wast of time. I would suggest something like # / # (dirs/files), like
#/# for issues (open/closed), ... .
For test purposes I added Home and dir/wiki to a try.gitea.io for review to decide if an update of my instance makes sense.
The TOC and DIR support issues related to gitea (#822#823#7182#7225#7390#6998#10523#14477#15296) demonstrate, that there is no clear prefered direction or status on developing a solution for Gitea and on the other hand, just collecting issues does not lead to a good project management - same in all Git Tools, when ticket numbers mess up the real talk about a target. Lot's of "Open" ends.
Trying to migrate a Repository from Gitlab with it's related Wiki-structure by "just" pushing it's contents (dirs / .md files) to Gitea results into a different behaviour.
As Gitea does the / transformation into a file-name having %2F instead of the directory structure support.
Then working with an IDE and Git is a real option for managing the overal structure efficiently and doing quality checks like unique wordings, references, restructuring, ... , by editor templates outside of the website much more efficient.
As it is a git repo, it needs to support directory structures ;-)
Additonally, for that, the markdown needs to be documented, that is supported by gitea/wiki - minimum a link inside the editor for where to find the markdown cheat sheet or the related implemented markdown version (help for the gitea standard markdown) and which IDEs Editors might support that efficiently.
Screenshots
The text was updated successfully, but these errors were encountered:
Gitea Version
1.17.2 try.gitea.io
Operating System
win 10
Browser Version
firefox 93.0
Can you reproduce the bug on the Gitea demo site?
Yes
Description
Issues, Pull, Release, Projects, ... counts work.
Gitea Wiki does not count and show the available page(s).
Nearly the same as a repository does not show the size/count of files included inside.
But in Wiki this is important to show, as nobody knows that there is an entry without looking into it - a wast of time. I would suggest something like # / # (dirs/files), like
#/# for issues (open/closed), ... .
For test purposes I added
Home
anddir/wiki
to a try.gitea.io for review to decide if an update of my instance makes sense.The TOC and DIR support issues related to gitea (#822 #823 #7182 #7225 #7390 #6998 #10523 #14477 #15296) demonstrate, that there is no clear prefered direction or status on developing a solution for Gitea and on the other hand, just collecting issues does not lead to a good project management - same in all Git Tools, when ticket numbers mess up the real talk about a target. Lot's of "Open" ends.
Trying to migrate a Repository from Gitlab with it's related Wiki-structure by "just" pushing it's contents (dirs / .md files) to Gitea results into a different behaviour.
As Gitea does the
/
transformation into a file-name having%2F
instead of the directory structure support.Then working with an IDE and Git is a real option for managing the overal structure efficiently and doing quality checks like unique wordings, references, restructuring, ... , by editor templates outside of the website much more efficient.
As it is a git repo, it needs to support directory structures ;-)
Additonally, for that, the markdown needs to be documented, that is supported by gitea/wiki - minimum a link inside the editor for where to find the markdown cheat sheet or the related implemented markdown version (help for the gitea standard markdown) and which IDEs Editors might support that efficiently.
Screenshots
The text was updated successfully, but these errors were encountered: