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.

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.

I'm not sure about that. It would be definitely nice to have all the old functionality available for directory tree, but I can't say now that it's a must. I can imagine things like ignoring directories (adding them to .gitignore) as an obvious example of the stuff that might have sense in such a directory tree.

Hi folks, is it possible to somehow show "directory tree" together with "log window"? I mean, I kind of lack ability to browse the working tree, i.e. navigate to particular directory in the tree and *then* focus on stuff (e.g. modifications) specific to that directory? It's probably not directly related to "log window" feature, but in it's current implementation it's a bit inconvenient...

As a side note, did you consider making "directory tree" part of file pane? I mean, I always questioned why directory browsing is part of repository pane (where it's intermixed with other repositories, especially, if the repository is not the first one in the list)? I mean, most of the times, I don't need to switch repositories, but I do want to focus on different directories in the working tree. So if the "Directory tree" was part of file pane it would let me close repositories pane not to be distracted by other stuff, as well as it would solve the above problem for "log window" mode.

Hi, I've just thought about something similar, probably in another context: quite often I split commit to make changes to particular files included in the commit, part of another commit. I.e. I "split to extract selected file". Making it a single command would be really great (the command could be available in context menu for a selected file in the commit view).

If we take the above to extreme, it would be great to support extraction of a file from multiple commits. I.e. scenario would be like this: 1) open log for a (single) file 2) select interesting commits 3) select "Split to extract". As result every commit of the selected that contains multiple files would be split to extract the selected file changes.

I do understand that again, probably it's not for 99% of users, but I kind of believe that it might be chicken-egg problem: I would say I'd never do commit splitting/editing/squashing if SmartGit didn't make it *dead simple*. So probably being Git user, I wouldn't imagine it would be a "common task" for me. However now I use it daily, without hesitating. Such features make SmartGit different from all the other Git clients that don't challenge the status quo in terms of making previously complex stuff simple.

I, as a user, completely support this proposal to make Log window as powerful as the main window. Actually I kind of thought of making it third/alternate perspective in the main window. I miss it while Splitting/Squashing/Reordering commits, currently I had to use Journal in main window, that lacks the ability to see the committed changes right away. Also, it makes perfect sense for things like Edit Commit Message and etc.