~patmaddox: Fossil Wishlist

There are a few things I wish Fossil did, that I will perhaps try to implement.

They are listed in the order that I intend to work on them, based on a combination of interest and difficulty.

Integrate GFM - fork cmark-gfm and incorporate Fossil-specific markdown rendering
Single simple browser - separate /doc /file /dir seems unnecessary
Auto-redirect on 404 - so I can move files without breaking links
Merge request / diff review - to review changes in a branch before merging

Markdown checklists

Interest: High
Difficulty: Low
Status: Not started

Example:

- [ ] unchecked
- [x] checked

Current behavior:

[ ] unchecked
[x] checked

Desired behavior:

unchecked
checked

Auto-redirect docs on 404

Interest: High
Difficulty: Medium
Status: Not started

I want to use Fossil's docs feature to publish my writing. One problem I've run into is if I re-organize or re-name anything, links are broken. Fossil will have a record of any moves that happen, so requesting a doc should 301 to the current location.

Seems like I can't rely on event mtime for ordering. Try searching for the same manifest id instead.

SELECT filename.fnid,
       filename.name,
       tag.tagname
FROM   mlink
       JOIN tagxref
         ON tagxref.rid = mlink.mid
       JOIN tag
         ON tagxref.tagid = tag.tagid
       JOIN filename
         ON filename.fnid = mlink.fnid
WHERE  tagname = 'sym-trunk'
       AND filename.name = 'foo.md'
	   LIMIT 1;

Draft post to Fossil forum:

Hi there, I have a contribution to submit for consideration and feedback.

The basic purpose of this contribution is that I should be able to publish a link to `/doc/trunk/foo.md`, later rename it to `bar.md`, and have visitors be redirected to `bar.md` rather than get a 404.

- **Problem**: moving files breaks `/doc` links, which may be published / shared outside of the Fossil repo
- **Desired outcome**: Fossil redirects to the new file name, because it has a history of the move
- **Contribution**: [doc-mv-301-redirect-branch](https://chiselapp.com/user/patmaddox/repository/fossil-scm/timeline?r=doc-mv-redirect-301)

How it works: when a user requests a `/doc` link that would result in a 404, Fossil checks to see if it was previously a valid file name that has since been moved. If so, it responds with a 301 redirect

## Concern: Potential memory leak

I'm concerned it introduces a memory leak. Do I need to call `fossil_free` on `zTagName` and/or `zNewFileName`?

## Implementation note: `tip`

I opted not to make this work with `/doc/tip/filename`. Because `tip` could refer to any branch at any time, I'm not sure it makes sense to apply this behavior. If there are no leaves with `foo.md` in them, I think `/doc/tip/foo.md` should reflect that and 404.

## Implementation note: branch history

1. add foo, commit to trunk
2. rename to bar, commit to branch1
3. rename to baz, commit to branch2

A request for /doc/branch2/foo.md will 404 because branch2 has no commits that reference foo. I think this is okay, as the point is to have links redirected on a particular branch, not necessarily on any branch.

## Potential for improvement: Recursive resolution

Right now, this will 301 with the next known path.
If the file has been moved a few times, the browser will make multiple requests, receiving a 301 each time until it reaches the end.
Fossil could resolve the final destination as part of the request, so only a single 301 is necessary.

## Question: What to do when a file has been removed?

1. add foo, commit
2. rename foo to bar, commit
3. add foo again, commit
4. remove foo, commit

Requesting /foo will direct to /bar, even though /foo has explicitly been removed.

This should potentially filter based on mlink mtime to not redirect to a path that occured before a delete, or reference the manifest to determine if there was a move.

Syntax highlighting

Basically I want GFM + whatever Fossil-specific features it needs to support links.

Merge requests / diff review

Some kind of diff review would be helpful. I've used GitHub / GitLab style a bunch, but also liked what FreeBSD does with differential.

Doc links to dir / files using `$CURRENT`

Interest: Medium
Difficulty: Low
Status: Not started

Docs are part of a current checkout. They should be able to produce links with $CURRENT in the target. Even better would be to have a special link command. [foo](dir:foo) to link to relative, [foo](dir:/foo) to link to absolute.

Potential snag: files on disk may not have been added to the repo. How will the file explorer handle this? e.g. if I have a link `foo where foo is uncommitted.

Summary Commits

Interest: High
Difficulty: High
Status: Not started

Tag a range of commits so they appear as a single commit on the timeline. Expand the summaries to see the details.

Annexed files

Interest: Very high
Difficulty: Very high
Status: Not started

git-annex for Fossil.

One big question: how many files can Fossil handle? Git is slow when you get to ~200k files or more.

(Maybe) Show / link to history in docs

Docs are great for presenting information, but they can change. It's probably a simple matter of updating a template to link to the doc history.

(Maybe) Render dir markdown as docs

Or more likely support the ?ci=ckout special checkin.

I want to link to the dir page so I can see the file structure. Links in markdown files (especially README) should still work.

~patmaddox