show both staged and unstaged changes for a file

[ianhi]

Fixes: #627

As discussed in the issue if you have both staged and unstaged changes to a file:

then the file will only show in the Staged Files list in jupyterlab-git.

I added another option to the Status token that accounts for this state and modified the FileList and FileItem accordingly. Note how the same file appears in both Staged and Unstaged lists with different status codes, and these give different results for the diff.

When you select one instance of the file both list items are selected. I can't decide if this is a feature or a bug. But it seems that this didn't affected any of the context menu commands that depend on tracking which file is selected.

In simple staging mode it reduces to showing the diff from WORKING to HEAD:

[fcollonval]

@ianhi nice work

I propose to rename the new category to 'partially-staged' this may be less ambiguous.

Then I add a trick to remove the need for a new component property.

Regarding the double selection, you should add the status attribute in the comparison src/components/FileList#_isSelectedFile

       this.state.selectedFile.x === candidate.x &&
       this.state.selectedFile.y === candidate.y &&
       this.state.selectedFile.from === candidate.from &&
-      this.state.selectedFile.to === candidate.to
+      this.state.selectedFile.to === candidate.to  &&
+      this.state.selectedFile.status === candidate.status

This should fix the double selection.

Do you have time to work on this and to rebase on the master?

[ianhi]

Do you have time to work on this and to rebase on the master?

Yes, will try to do this evening.

[ianhi]

What should Discard changes do to partially staged files? Currently it also discards both staged and unstaged changes.

[ianhi]

Rebased. Not sure what to do about discarding changes. There is a fun failure mode where if you stage the creation of a file, make further changes, then revert those changes you get the below error:

I think this happens because the discard function first calls reset then tries to checkout a file that no longer exists.

[fcollonval]

@ianhi thanks a lot for the quick action. I modify the discardChanges function to skip calling checkout in the case you mentioned. I also modify the case where the index contains modifications but the file was deleted in the working folder to be coherent.

Is this PR good to go for you like that?

[ianhi]

Oops sorry I accidentally commented out your action button lines! Looking at this again there are two things I might change:

1. Put the discard changes action button on the left of the buttons. This will make the button positions line up for staged and unstaged files.
2. Make discarding changes to a partially staged file only remove the unstaged changes.

My intuition as user is that discarding changes through a button in the unstaged section would only remove the the unstaged changes. So removing both staged and unstaged changes is dangerous because I can lose more changes than I expect.

I think my position boils down to: Hitting discard changes on a FileItem in the unstaged section should call git checkout but not git reset. It looks like the git reset is in there because

jupyterlab-git/src/components/FileList.tsx

Line 236 in bd87296

/** Discard changes in a specific unstaged or staged file */

the function is meant to apply to both staged and unstaged files. Though there doesn't currently seem to be a way to unstage changes to a staged file. Can we just get rid of the git reset and change DiscardChanges -> DiscardUnstagedChanges?

Or perhaps discard changes should result in a git restore command. Unfortunately that was only introduced in git version 2.23, But we can easily get the same effect with:

git stash push file
git stash drop

[fcollonval]

• Put the discard changes action button on the left of the buttons. This will make the button positions line up for staged and unstaged files.

I will not change it. The current order follows the one of VS code. And this seems to be ok if double clicking opens the diff view, then the user action for a given file will be adding or discarding the changes. So it sounds logical the two buttons are next to each other.

• Make discarding changes to a partially staged file only remove the unstaged changes.

Done, staged file are reset only and unstaged file are checkout only.

We cannot get ride of the method as we need to cover the simple UI case in which discarding changes means reset + checkout for partially staged files (although this should not happen when using only the UI).

[ianhi]

🎉 Just tried it out again and everything seems to work as expected, so good to go for me.

Thanks for the help on this one.

[ianhi]

Oops wait I take that back, if the only staged file is a partially staged file then you will be unable to commit. I will fix and then I think it will be good to go

[ianhi]

I also realized that there was no way to access the option to discard changes to a staged files in simple mode. So I added a discard action to files in simple staging mode and also added a contextmenu.

[fcollonval]

Thanks @ianhi for the latest updates. The context menu should at some point be simplified to not have to deal with 5 menu but to use selectors for the actions. But let's keep it aside for now.

[fcollonval]

@meeseeksdev backport to 0.11.x