This would be a huge usability boost when splitting a bunch of changes into smaller commits. It's hard in the current UI to see which files have changes which are staged, unstaged, or both.
I totally agree ! It's hard in SmartGit to clearly see what is staged... Plus it would be easier to work with file hunks.
Unfortunately not many users are missing this. But for me this is essential. Using SourceTree for years, but finally on the fence for another tool. But exactly this is what I don't want to miss as it is burned inside my brain.
Maybe it could be implement by allowing two "Files" windows open in the same view. By setting the appropriate filters we could have the split view. :)
Please make it optional because current approach is fine with me.
Alternatively staged files could have different color or background and there could be possibility to sort Files pane by several columns.
Of course, this would be optional. Otherwise we would be frustrating thousands of users who just like it as they know it.
Yep, I would be one of them. I hate the way SourceTree/GitKrakken split the views.
I would totally love this feature! When you have dozens of files, it becomes really difficult to keep track of which you ought to stage, which was accidentally staged etc.
I think the most flexible way to implement this is to allow multiple Files panels, and users are able to toggle the filters for each panel separately. That way, this satisfies those who want a single Files panel, and those who want two distinct Staged and Working Files panel.
We have some new team members who we're encouraging to migrate from SourceTree, and this is one of two missing features that is making it difficult for them to switch over to SmartGit (the other being this issue, which is already in progress).
So +1 on this item
I have implemented something like that but as some kind of super-filter to the current View options, so you only can see 1 list - either the current "mixed" style, the staged files or the files with local changes (for the current "mixed" style, no "Index" and "Working Tree" toggle buttons at the right will be shown, so it will look as always).
You can give it a try in 18.1 preview #12063 (Help | Check for Latest Build).
SmartGit 19.2 preview 2 now has the option to see 2 lists at the same time (if both, working tree and index changes are available).
I just seen this today.. I have mixed feelings about it on a day-to-day basis, but the problem is, it hides the fact that it is conflicting.
No mention of "conflict" here. I just happen to know this IS a conflict because if what I am working on.
The toggle is nice though. I can turn this feature on/off if I know i have some conflicts..
But would just be nice to see the word conflict in the top section.
Thanks for reporting. This bug should be fixed in the latest build.
Confirmed fixed. Very obvious now thank you.
Though, submodules seem to show up in both index changes and working tree changes. But inside the working tree changes, it shows "state as index". Which makes me think it it shouldn't be in the "working tree changes" section.
I really appreciate Syntevo working to add this functionality. I hate to, as they say, "look a gift horse in the mouth", but is there any way to configure it to
1) show them in separate windows so we can view them side-by-side vertically instead of the current horizontal split? I have lots of horizontal monitor space but vertical space is at a premium and I prefer to reserve it for the changes pane.
or, at the very least,
2) control whether the index is shown in the top pane versus bottom pane?
Please try the build 15033 and search for the low-level properties starting with files.split.
The vertical split works great when I enable that option. Thank you!
One note: that property required a restart before it took effect. That might be worth noting in the dialog.
The option should not require a restart, but only has influence on new windows.
I see. That's confusing, but I guess that's what you get if you muck around with low level properties ;)
Maybe just make a note in the description of the property?
I really like this new feature, but there's one minor annoyance. When the feature is disabled, and you are interactively staging changes with the "changes" window open, the Changes window retains the selected file and the selected file position. However, when this feature is enabled, as soon as you stage the first change, the changes window empties because the file is de-selected when it's moved from one pane to the other as a result of the first change being added to the index. This is pretty jarring when you're moving through a big file with lots of changes, trying to interactively stage bits and pieces.
Is it possible to preserve the selected file and position? My thinking is that the working tree version of the file would remain selected until it's fully staged, at which point the selection would switch to the Index version of the file.
The latest build should provide a 95% fix for that.
Customer support service by UserEcho