Show Files View as a Tree

You already can select the directory in the Repository's view. For those who prefer at tree-like display we already offer the Relative Path table column since SmartGit 8. With a real tree we would have different items in the control: directories and files, resulting in possible duplicate selection: what should happen if a directory and some files inside it are selected?

Um... just look at Sourcetree and GitKraken? The former has offered tree view for years now.

I had hoped for a better suggestion. IMHO, tree views for showing directories and files are a - err - suboptimal approach.

Well, it's obviously your call. I just find it a shame because otherwise, SmartGit's UI looked pretty appealing to me.

Also, I've never had issues with the tree view in the other products.

Just to throw my hat in the ring: it's totally up to you, but having just switched to smartgit from gitkraken (since the latter is full of bugs), this is (so far) the only feature that I'm seriously missing.

Having to go through each file and read its path to ensure that it's in the directory I'm meant to be working in before staging/commiting adds heaps of cognitive load to setting up commits. Working in Unity means that often lots of random files are updated in other directories while the application is running and generally I don't want to stage those (to keep commits clean). I imagine many other people have similar workflows of using directories to check that they're not committing things they shouldn't be / to group commits.

If I could offer a suggestion for the problem of duplicate selections - selecting/deselecting a folder should just apply its selection state to all files and folders inside of it. Having it as a non-default option would mean that, even if it's 'suboptimal', the users who prefer it could still have it enabled.

What SmartGit version you are using 18.2 or 19.1 preview?

Just my 2¢: I've been using SmartGit for, I guess, 7-8 years or so, and I was using SmartCVS (I recall it was a differently named product before) and SmartSVN before that. I really love the software/and I believe it's the most powerful (GUI) Git client out there. Btw, I use Smart Synchronize as well.

For years, it was my only (GUI) Git client (simply because it was the best client out there), and currently it's still my only tool for complex operations, like merging/history rewriting/rebasing/conflict resolution and etc.

I do simpler stuff in Smart Git as well, however, for simple operations, like composing commits/checking the worktree state, browsing the history and comparison between the branches/commits, I find myself using Fork "by default", for 3 years already, since I discovered it. Those things are *noticeably* simpler there in terms of UX: less visual load, fewer clicks, everything is optimized/results in less friction. The (combined) tree view is the main view available there, and I had *zero* thoughts about the need for file separation there (for all these years). *Probably* it's related to the fact that there's *no* "all files" view in there for the workspace, I see only the tree of "changed"/"uncommitted" files or index. But I doubt about that, as I can still see "big trees" when comparing commits. But again, I can't recall any 2nd thought that such a tree view is not optimal.

I *really* welcome the Standard Window in 22.1 from the perspective of simplification of the layout/letting me focus on one single repository/single workflow. I'm really trying to use it instead of Fork atm.

However, it's still a pity that the "combined" tree viewer is still not there. That would be yet another step towards the simplification/optimization of UI. Leaving aside the personal preferences, let me note that it would actually save a lot of screen space, that could be used for other things! (From that perspective, SmartGit UIs looks really clunky (unfortunately) compared to Fork, as SmartGit's file lists typically occupy extra width of the screen/span half of the screen at the very minimum, therefore pushing "useful" panes below/above the list - in Fork the useful panes are typically to the right of the tree view). Btw, what bothers me with the file browser in Standard Window, is that there's no way to see files related to a specific directory (typically root), but not from subdirectories (that is of course available in the old style window).

I'm asking myself why it may feel suboptimal for you, while it feels really natural to me. Probably because you don't use Macs a lot/get used it? I mean, such a "combined" tree is one of the default views (called list view) in macOS Finder. It's there for more than 30 years already, introduced in classic Mac OS (that, in my opinion, had one of the most optimized UXes), and used for working exactly with files... On the contrary, there's no way to reproduce the current SmartGit "file browser" in Finder. All in all, this sentiment is probably in sync with other folks below, that never had issues with the tree view.

Trying to answer this:

> With a real tree we would have different items in the control: directories and files, resulting in possible duplicate selection: what should happen if a directory and some files inside it are selected?

At quick glance, Fork basically treats that as the directory selection (selection of all files in the directory). It may sound questionable, but that really does not bother me. Moreover, given that (if I recall it correctly) Git does not "manage" directories, rather just files in certain locations, probably that helps to come up with simple UX solutions in such questionable cases.

Wrapping up, I'm not sure what would be an ideal proposal to solve the issue, because apparently there are people who want the separation and people that want the opposite. But I feel like both camps have their own very valid arguments, and I would love to see that SmartGit accounts both. Btw, I really wonder if something like this may result in less adoption on macOS platform. In several companies that I worked over the last years, I tried to advocate SmartGit - from what I see, people get excited with the powerful features but still keep using other clients... Adding support for more familiar UI for macOS, probably could change it for the better.

If this is the only reason you wouldn't provide this functionality, then just prevent selecting the directory and files at the same time. Tree view would be so helpful to look through the overall repository structure.

On the other hand, disabling showing subdirectories' files (shortcut ctrl + 0) gives me what I needed. Thx :)

In the meanwhile, the GUI design is relying even more on the separation of directory and files control (for example, due to the new split views). Technically, this would require significant effort to implement both options. Hence, it's very unlikely that this will ever be addressed.

Yeah, understood, but that's still a pity/something that really makes me see towards other clients, that gain momentum/actively try to catch up with SmartGit in terms of its powerful features.

State was reverted by accident.

Please consider to vote for this issue: https://smartgit.userecho.com/en/communities/1/topics/1474-