Dealing with large working directory/untracked files (ability to search/filter/collapse)

[jceipek]

Problem description

When the working directory and/or untracked files list are long, which tends to be the case with asset-heavy projects like games and websites, it is frustrating and time consuming to find the specific files I would like to stage or discard. This becomes especially problematic when the working directory/untracked files list is long and I try to pull, can't because the commit(s) I'm pulling add/modify files that are untracked or modified locally, and then I can't quickly find the affected files I need to commit or discard.

Preferred solution

A way to filter and/or search for files in the working directory (the existing search seems to only search through past commits), possibly combined with a way to re-order the modified/untracked files such that files that conflict with remote commits are visible at the top of the screen.

Alternatives

Something similar to the merge UI might help to address the specific problem of conflicts when pulling.

Adding the ability to collapse untracked/modified files based on the directory tree would make it much easier to manage files in general, and would make it possible to stage/track a large number of files at once (particularly when performing a large refactoring or adding individual asset files). This is somewhat related to #259.

For now, I'm going back to the terminal and using git add PATH and git rm --cached PATH when I need to deal with many changes at once. I'm going to recommend that the artists on our team stick with Source Tree for now. Even though it's less friendly over all, it does make navigating the working directory less painful.

[ransagy]

In relation to this; Is there a specific reason why the search module doesn't work for the "working commit"/"commit changes"? because it's not structured as a commit in git yet?

I'd really like to see at least some basic support to minimize the working directory file list. I easily get the situation where i have (in my case of .NET projects) a few solution files, a few project files and lots of other code files, Where i want to double and triple check those specific types of files before staging/committing. Finding those out of the 100+ unstaged files i have when making any kind of a wide change is just needlessly hard.

[safield]

I think there should be a string filter box like Git Extensions and Git-Cola use where I can enter filter strings.

For example if I entered "*.xml", my view would be filtered to only xml files.

In addition, this filter box should be added to the contents view as well.

[andrejohansson]

As a suggestion, It would be awesome if the search/filtering used ripgrep to search. Then we would get both speed, find in files etc. I think that the file search in vs code uses ripgrep behind the curtains if I'm not mistaken. It´s a well done project!

[dpjohnst]

Hi all,

We have added fuzzy-filtering of files in Sublime Merge Build 2052 (development)! Feel free to share your feedback here, or open a new issue if you feel the issue deserves one.

Kind regards, - Dylan

[stinos]

It works ok, but it's not super convenient; perhaps I'm missing something but it does seem to require a lot of different steps:

• repository opens in commits view (for me)
• use Ctrl-3 to go to file view
• then depending on whether the search box is already open either use Ctrl-Alt-F once, or twice (coulnd't figure out how to focus the search fiels when it is open already). Suggestion: always show it then focus it with Ctrl-Alt-F or something like that. Or never show upon entering the view. Or maybe even just always show and always focus. Should just be consistent.
• start typing: the modified/untracked/unstaged items are still collapsed so I have no clue what I'm actually doing, I just see that these are counting less files
• I cannot figure out how to expand these with the keyboard; I can use tab to shift focus from search box to the files, but how to expand the tree? Standard keys like space/enter do not work. So: reach for the mouse to do that.
• (my main gripe: I expected/hoped the diff view to shrink as well. I spent most of my time in SM in the diffe view and assume others do as well, being able to filter that easily would be the real deal)
• even forgetting the previous point, it is inconsistent that when in the files view tree I click on something which says 'untracked files (4)' where the 4 is the result from filtering 10 items, it does actually show all 10 files in the diff view

[dpjohnst]

Hi @stinos,

Thank you for sharing your feedback - it's much appreciated and we'll definitely take this in board for future improvements.

A couple of things to note:

• You don't have to press Ctrl + 3 to switch to the files view - you can just press Ctrl + Alt + F once to switch to the files view and open the filter (if it's not already open). As you suggested though, it would be nice if pressing Ctrl + Alt + F when there is no input focus just updates the focus - stay tuned.
• The modified / staged files should not be collapsed in the files bar by default (only untracked). If you're seeing this behavior, would you mind submitting a bug report?
• After typing in a filter, you can use the TAB key to navigate to the files list, and use the arrow keys to view the diffs for each of these files - these diffs will never be collapsed. To expand / collapse a section, you can use the Left / Right arrows.

In regards to filtering the whole sections, this will be something that requires future design work to implement. The files panel is independent to the details panel and can be hidden from the user entirely. Having the filter apply to the details panel may result in confusion for the user if they are not aware that the files filter is enabled. That being said, I can see the utility in having the filter apply to sections, and this is definitely something we'll be exploring further - stay tuned.

[stinos]

@dpjohnst thanks for the quick reply. Good points about not needing Ctrl-3, left/right arrows (can't believe I didn't try those) and collapsing of modified files.

The latter indeed happens by default, but it's a bit of a friction point because once collapsed (which I likely did to test things, at least I cannot reproduce it being done by SM) it won't expand again when going back and forth between commits and files views, which is understandable. But on the other hand just closing the repository and opening it again will again have things expanded. Unlike say ST which will remember individual collpased state of everything in the tree, right? At least I assume that's where my feeling of inconsistency comes from :) But I don't think it is worth spending time on such details.

The files panel is independent to the details panel and can be hidden from the user entirely. Having the filter apply to the details panel may result in confusion for the user if they are not aware that the files filter is enabled

I understand, but the thing is that the 2 are actually coupled already because a selection in the Files tree will lead to individual files being shown in the datails panel. E.g. if one clicks on a single modified file in the Files panel, then hides it, the details will still show that one file. So you end up with the Commits view telling you there are e.g. 5 unstaged files, but the only thing shown on the right is one single modified file. So having the filter do the same would at this point perhaps even be more consistent. Especially because when clicking modified/staged/untracked in the tree already applies that selection to the details pane. Again persisting the selection even when hiding the Files tree.

[baileystokes6]

It's a fantastic blog post that is also really useful. Gogetdeals Discount Codes & Vouchers

[ljak]

Any followup on this ? :pray: