Wishlist

[wmertens]

I'm really excited by this project and therefore I can't sleep until I write down this wishlist. It's heavily borrowing from GitUp, with some influences from other projects.

UI - visual

• Un/fold all button on file lists (but refuse more than x lines of diff)
• Merge branch indicators for branches with the same name. E.g. [master local|origin].
• Indicate upstream of a local branch
• Draggable line selection for adding to /removing from index (patch view), or at least allow toggling all patch checkboxes Click & Drag Selection on Patch Changes #1421
• Show branch labels at the top for all branches, even for commits that aren't loaded yet
• Add compact view of current branch, with only subjects, and smaller dots
• Make staged/unstaged less subtle
  • Perhaps keep the current look with checkboxes, but also show the staged files in a separate list?
• Add a committing view that shows staged/unstaged in separate panes
• Allow moving branch tips but keeping changes
• Use right mouse click for a dropdown menu with more actions
• Request a diff of the current commit with any other commit
• Request interactive rebase from a commit
• Show interactive rebase state, allow cancel/continue etc
• Add a reflog view that shows missing commits
• Preferences panel that stores config.js settings in a cookie
• Automatic links to git providers like github/gitlab for commits/branches
• Specialized differs for e.g. images and json data

UI - mechanics

• undo/redo
  • Before doing any change, store the undo information with a description. Since everything is a ref, this allows full undo/redo, except for remote actions. [1]
  • GitUp has a history view that shows the state of the tree for any past action using the undo log, but I didn't use it a lot
• searching
  • Index all commit text and patches for full-text searching [1 again]
• committing
  • Actually show staged/unstaged instead of a local in-memory representation
  • Allow launching tools on files, like an editor, or p4merge for 3-way commit resolution
• interactive rebasing and merging
  • Show the committing interface at the commit that is being edited, so that the "before" branch is visible above it. This provides context.
  • Show merge conflict files as a third state
  • Common rebase shortcuts: move/squash/remove any commit with a single click. This performs an interactive rebase behind the scenes. In case of conflicts, it becomes a real interactive rebase
  • Likewise, allow editing any commit, which does an interactive rebase again
• performance
  • Load all the refs and the commit tree entirely into memory. [2]
  • Extra commit data, like author and subject, should only be requested for visible commits, and the file changes only for hovered/opened commits.
  • All data is immutable, so it's super cacheable

Backend

• use Babel or webpack so that we can use async/await, which makes the code much more legible and faster to load
• use webpack with the start-server-webpack-plugin so the server can be live-reloaded
• use graphql instead of express routes:
  • forces separation of concerns
  • allows clients to request only data they need, save cycles
  • reuse data resolvers across all resolvers, so you can return entire commits instead of post-processing in each route
  • very nice tooling available
  • type checking of input/outputs

Notes

• [1] I believe GitUp stores this information in a sqlite db in the .git/gitup directory
• [2] The biggest project I know (Linux) has almost a million commits. Suppose that the first 32 bits of the commit ids are unique (we should check and possibly alias duplicates server-side), then that's 4MB of data. We also need the parents, so that's another 4MB, and then some extra data for commits with multiple parents. So it seems likely that the Linux commit tree can be represented in 10MB with some clever data structures. Entirely manageable.