sirnewton01 / ghfs Goto Github PK

When a repo is forked, it currently shows that it is forked but there is no way to know what repo it was forked from. It would be good to have that as a path you can easily navigate on to drill down to the original repo.

Certain repositories are missing the repo.md with the metadata and actions, like star and watch. An example is this one: https://github.com/paul-lalonde/twittergo

It would be good to have a feed of the activity of a particular repo so that you can see if there is any current work happening there.

It will be useful to have the starred repos visible at a glance so that you can easily navigate back to them amongst the user's other repos that are of no interest.

The graphviz format can be used to render graphs for the forks of a repo. It's also fairly readable in its text form, which is consistent with the rest of the ghfs design.

The current multi-line text boxes are surrounded by code fences using the back-ticks. The textual representation is ugly and it causes escaping difficulties in the Go code.

Instead, several tildes could be used with a much better visual effect. Tildes as code fences appears to be part of the original standard and a variable number of them could be used to help and avoid escaping collisions within the descriptions.

Also, the three underscores after the block are unnecessary and waste vertical space. Instead, if there is a fenced code block the variable should be bound to the literal contents of the block. There should be no need for them in this case. They should remain for the single-line text case though as they serve as a good visual cue and it is sometimes unclear where the end of the text should be.

Allow a user to edit the repo.md in their text editor and effect changes to the project metadata provided that they have permission.

Due to the excessive chattiness of OSes when they go through FUSE and the odd bug in ghfs there can be quite a few round trips with GitHub retrieving the same data over and over. I haven't seen a case yet where I went over the rate limit, but it does slow things down. The go-github library does mention that there is a way to hook up an HTTP cache with another go library and it will make use of the ETag and IF-Matches headers along with a cache to avoid the round trips. Another option, that is much more Unix/Plan 9 in philosophy would be to set up a proxy that does the caching and ETag checking.

In either case this setup should be documented in the README to help people to make it work in their setup.

The README.md in the repo directory doesn't show whether the project is a fork. If it is a fork it doesn't show the original repo.

Provide the ability to follow or unfollow other users, which would affect the activities and the default owners that show up under /repos.

I'm getting the error

# github.com/sirnewton01/ghfs/dynamic
dynamic/server.go:369:5: undefined: protocol.Debug
dynamic/server.go:370:8: undefined: protocol.DebugServer

when trying to build on a Mac.

When a client is writing a file, they may divide their writes into blocks if the file is beyond a certain size. There's no real way to know when they are done writing except when they "clunk" the FID they used to write. At the moment, simple cases like the ctl file in the issues directory are assuming a single write and immediately attempt an update after that write. In that case, the file is usually so small that clients write the buffer in one shot. However, with larger items the client may break it up.

The dynamic server should expose the FID used to open on writes so that handlers can detect when clunking the writes to that FID in order to perform an update or produce an error if the update fails. Also, the issues ctl file should adopt this approach.

Under the owner folder it would be good to have an activity feed to see what you or anyone else has done.

When browsing users or organizations with a very large number of repos such as google or mattn the directories are showing up as empty.

There's a good chance that users you watch will have repos that are interesting to you. They should be automatically populated in the repos directory so that you can easily navigate to their repos.

There should be a file that dynamically loads the commits is descending order. The file is conceptually limitless, loading on-demand as a reader reads it allowing the user to make use of a pager. There is no need to support a tail/head command.

Perhaps it doesn't really make sense for ghfs to run in unauthenticated mode. If this capability will continue to be supported then this bug should be fixed.

It should be possible to edit an issue by modifying the text in the markdown document provided that I have permission. Also, there will be a comment template at the bottom to allow me to easily fill it in and create a new comment on the issue.

To create a new issue a variant of the clone file used in other Plan 9 filesystems can be used. When you open the clone file you see an issue template that allows you to fill it out easily. Once you write to the clone file it creates the issue.

If we were to follow the typical Plan 9 pattern for clone files, the write to the clone file causes it to rename itself dynamically to the new file. However, it is unclear how well text editors can handle the renaming of the file on the fly with the same QID/FID. It is possible that they won't handle it well. But, at least modifications and subsequent saves won't create new issues.

A workaround could be to have writes to the clone file produce a message somehow that "2.md has been created" so that in acme at least the user could navigate to it with a right click. It seems that the only way to do this is to have the clone file always return a Terror on write, which is very confusing semantics.

Another workaround is to have the write to the clone file succeed and have the user manually open the new issue, which is not super usable but the semantics are better. It could be solved with a bit of inline documentation ("Check the issues directory for your new file after you save").

This becomes really useful when you are looking at issues and want to view/sort them according to how old they are or if there is recent activity.

You can do a simple ls -l to browse them yourself or even sort them using ls -lt or ls -Ult

When navigating to a large organization (e.g. google or microsoft) it is very slow to iterate through the hundreds of repos. It blocks acme and continue to bog down ghfs after the the owner is loaded. The performance should be analyzed to consider any optimizations that may be possible.

Also, perhaps the loading of all of the repos for large organizations should be reconsidered. It wculd be worthwhile to load only the first 50/100 and allow the user to access specific named repos afterwards. If the user truly wants to look at all of the repos then there could be a special file (more) that can be opened to cause all of the repos to be loaded.

There doesn't seem to be any way to get the blackfriday dependency to clone on 9front. dgit crashes, and the git rc script says the url is not supported.

A number of the handlers and even the server itself allow modification of its state from multiple threads without any explicit synchronization. This is bad because it can lead to subtle data corruption problems. The code should be fixed up before we begin to have any true editing capabilities so that users are certain what they are editing.

When attempting to change the label on an issue and you don't have permission no error is produced. The file saves fine but there is no change to the labels.

It would be great to be able to have a directory or directories related to topics. They would be empty by default like "/repos." The repo.md for a particular repo would have links in to topics that are tagged for the project.

Some thought needs to go into how to handle paging. A topic could be a single file or a directory with files in it.

With a single file, it could be infinitely scrolling but then most text editors probably won't handle it well even if a pager or the plan9 command line might. The file could be writable, which would provide the trigger for the next page, but there are no universal reload semantics.

A topic could be two files. One for the content and another "control" file to expand its size. The workflow wouldn't be too dissimilar from the issue filters workflow with the issues file. The user needs to know to reload the content file after touching the control file.

Alternatively, a topic could be a directory with a control file exactly like the issue.

Another option is to divide pages for a topic among different incrementing page files. Open the first "001.md" and it shows the first page, "002.md" for the second, etc. "cat *.md | more" on the directory will give you a single page. Editors open one at a time with a link to the next at the bottom.

It would be good to show at least the top-level contents of a repo, which usually includes a readme, license information and other information that can provide a lot of context when browsing different repos. It will be good to show the contents under a hierarchy that represents the different branches or tags.

The issues directory could use an overview file that allows you to see the issues, summaries, owners and last modified dates at a glance. You can open each issue using a link in the table. The table can be filtered using the filter.md used to populate the issues directory but with some guidance on how to use it. In the future this overview could be used to provide an entry point to create new issues.

It would be nice if there was a way to issue a PR, since you can't do it with the standard git command line.

There should be a way to watch, unwatch or completely ignore repos.

When I look at the issues for a project I'm also seeing pull requests. Either the directory name should be updated to reflect this, pull requests should be filtered out initially unless requested or some kind of documented workaround should be in place. It is rather interesting that the GitHub REST API lumps the two together.

If you watch another really large owner of repos it takes a very long time to list your own repos and access your own items with plan9port on Mac. This should be optimized in some way to avoid this hit when it is not needed.

It is useful to be able to change the sort order on this file. The filter.md should support changes to the list query that affect not only the content but the sort order. This sort order would impact only the 0list.md file and not the directory listing. There should be a note made in the filter.md that those settings only affect the 0list.md file.

The current ctl file is JSON, mapping directly to the object used in the ListByRepo query. Instead, there should be a markdown conversion to/from this object so that the markdown can have helpful comments on how to use the different flags. Also, the markdown can skip the properties that have no effect when the user tries to customize them, such as the page size used to transfer the issues and the sorting order.

Allow a search file to be written with search criteria. The results can come back with file paths and commits where the matches were found allowing you to use a git tool to find them.

Allow a user to change the title of an issue or the description. Also, there should be a template at the bottom of the comments that they can fill in to create a new comment.

Provide a way to write to a search file and get back a new file with the results and links to the issues that match. The issue links will be simple file path links allowing you to navigate using acme to the issue easily and perhaps even navigate to the matching text/line number.

There is a very good chance that the logged-in user will want to see their repos right away and so we should automatically show it under repos. Other repos will show up on-demand as usual and by navigating cross-links or by direct navigation to a specific place.

Only open issues are displayed, there's no way to read issues after they've been closed.

Maybe the issues directory should have new/closed/all subdirectories to match the possible states in the GitHub API?