vscode-gitlens
vscode-gitlens copied to clipboard
gitkraken
Addition of Work In Progress row
This PR attaches a "WIP" row to the top of the graph when there are changes in the working directory.
Note: To support this, I have utilized git-ls-files: https://git-scm.com/docs/git-ls-files/2.9.5
I also generated a new "work dir stats" model which represents the number of added, deleted and modified files.
Additional notes:
- We currently aren't sending the work dir stats into the graph as we cannot handle renames just yet. They are incredibly tricky to detect with unstaged files using git and it needs to be thought out more.
- We are using ls-files instead of diff shortstat because git diff does not pick up unstaged stuff by itself (which is a shame, because git diff DOES have rename detection).
@eamodio Need a review pass on this since I'm touching core git logic.
@axosoft-ramint Heads up you'll want to bump the current version of the component-library and change the package.json to use the new version, probably v1.0.0-rc.4
@axosoft-ramint Since this isn't a requirement for 12.2 and I'm still swamped in 12.2 task, I won't get to review this until later in the week.
@eamodio This PR is updated. Would you mind giving it a look when you have the chance? Thanks!
Looks like our new paging strategy broke this after rebasing it. When paging, we get a WIP node for every page of commits and the edges break on it. Having a look.
NOTE: Updated this to just send workDirStats as a prop and update it when needed. We will take care of adding the WIP node row on the component side: https://github.com/gitkraken/GitKrakenComponents/pull/89
Quality gate: Failed
3 Code issues
Quality gate: Failed
9 Issues
9 Code issues
@eamodio Some of the warnings from the Embold analysis make sense, and I've updated the code for those, but...
...all I did was move an import from the type list to the non-type list. Why would this trigger such a warning?
We do this everywhere already in the existing code? I counted 131 other instances, including one in updateAvatars right above.
We also do this everywhere already in the existing code.
Should I change these anyway?
Please ignore any Embold checks -- I was trying an evaluation and it apparently added all this without asking.
Component-side logic has landed. Once this merges I can bump the library version and it should enable the feature.