brainless / gitplay Goto Github PK

As a GUI developer I need the file sizes for the list of open files and folders to show what changes are happening as we play the repository.

The API request will have a list of all paths that the GUI is tracking (files and folders), starting commit ID and batch size.

The response should contain a list of sizes for each path, keyed by the commit ID when the size changed. Total number of file size changes (keyed by commit ID) will be up to the batch size.

As a user I would like to see a background colour change (or something similar) to indicate the file size change as the git log is played.

Following error is thrown when mouse hovers at the beginning point of the timeline:

[Error] Unhandled Promise Rejection: invalid args `startIndex` for command `get_commits`: invalid value: integer `-100`, expected usize

TL;DR

handleTimelineEnter is called for onMouseOver on the timeline bar.
handleTimelineEnter calls loadCommits which in turn invokes a RPC call to get_commits

This is not directly related to gitplay. But a git feature that would be great, a better devX

Problem statement

We all have worked on a feature intensively and had to refractor a lot of the code base (in early projects). But can't spend the mental expense to context switch from writing code to make meaningful commit messages.

A good commit history is at the expense of the developer, which results in breaking the "flow". As pg mentioned in his blog post Holding a program in one's head, it be better to work in long stretches to have better developer productivity. And it is very common for devs to have to make code cleanups which are unrelated to the feature they are working on (example tweet)

• Commit small and commit often
• Writing good git commit messages goes a long way
• get gud at git

Scenario

Lets say you are building a feature and mid way you came across a variable name that could be fixed. Or a piece of code that is no longer needed. But you don't want to include this unrelated changes in your working commit. So for good practice you need to create a new commit for those changes.

Current solution

1. git-worktree
   We can currently use git-worktree to create a parellel repo in your local directory and make the changes in that, push a commit, pull the changes in the feature working tree and continue. This is long and hard

2. stash and make changes
   Make a stash of the current feature changes and then make the required changes, commit and pop the stash. So bad my eyes are bleeding

3. Make the changes in the current working tree and use git add -p to make patches when creating a commit
   This is what I currently do. But the flaw of this approach is that it looses the essense of story-telling, You may make changes that don't show a history, instead shows a bunch of unrelated changes on top of each other.

The solution

If we could patch changes into commit groups and then finally commit those changes when all the related changes are ready, it will let the developer write code in a long stretch 1 and also build a story for the commit history.

Why commit groups?

We can currently create patches. But using this new feature we can add patches into groups as we read the code to make patches. We will have more than one stages files "area".

Cross posted on hackernews - Link