Your comments
Concerning the implementation: How about that columns that are hidden keep their place (are treated like zero width). Internally, all columns have a position and the user can arrange them once the column is visible.
If I move another column to a position where an invisible column is, it can be arbitrarily (but consistently) placed either behind or before the invisible column.
Let's assume we have a total of 6 columns, and Column3, Column2 and Column6 have just been hidden. Let me show an example of the internal state of the columns:
Column1(visible)|Column2(hidden)|Column3(hidden)|Column4(visible)|Column5(visible)|Column6(hidden)
The user would see this
Column1|Column4|Column5
If the user now drags Column5 between Column1 and Column4, what he expects to see would be
Column1|Column5|Column4
SmartGit would now have the internal ordering in either of the two ways. I think it doesn't matter too much, which one is chosen, as long as it's always handled that way.
Implementation1: moved before hidden columns:
Column1(visible)|Column5(visible)|Column2(hidden)|Column3(hidden)|Column4(visible)|Column6(hidden)|
Implementation1: moved after hidden columns:
Column1(visible)|Column2(hidden)|Column3(hidden)|Column5(visible)|Column4(visible)|Column6(hidden)|
Let's assume Implementation 1 is chosen, because it is easier. When the user now enables Column3, the internal state would change to
Column1(visible)|Column5(visible)|Column2(hidden)|Column3(visible)|Column4(visible)|Column6(hidden)|
And the user would see
Column1|Column5|Column3|Column4|
for case 2 the user would see the following after re-enabling Column3:
Column1|Column3|Column5|Column4|
I think both cases are better and less surprising than the current way it is handled:
Column1|Column5|Column4|Column3|
The user didn't move Column3, therefore he/she expects it to appear somewhere close to where he has last seen it.
The most important fact should be, that without any moving around, a column re-appears exactly at the position where it has been hidden.
Other programs that make heavy use of columns handle it the same way (I can think of Thunderbird and Outlook for example). In fact, I don't know any example where the column order is not retained (except for SmartGit).
Sorry for the wall of text, but you I find it hard to explain it more concisely, without leaving important detail out.
Great. I tried to exclude with regexes but this is much harder to type and remember. I couldn't find this info in the manual, maybe it should be documented more prominently. Anyway, this will make my life a lot easier. Thanks.
Edit: I just found out that it is possible to combine several of these excludes by using comma as a seperator. e.g.
!*.c,!*.h
Just saying to document it for others.
I'm working on a CAD library used by several users and every so often someone asks me to merge his changes to the main library. I start by viewing the differences between his fork and the main repo by selecting the two commits (great feature).
Often, for additions or deletions, I want to read the commit message, as they contain further information on the reason for that action. I use the log feature on the file in smartgit (while comparing commits), but found that it's often easier to go through the list directly rather than opening a new window for every item, just to read a single line. That's when this information would be valueable for me. I'd like to add that these are binary files, so the usual text compare that is displayed doesn't work.
I don't consider this high priority, especially since different git clients can work together flawlessly. But it is a thing that makes me leave smartgit and I wanted to mention it.
I understand that this might not be a good default setting. But if you need to click every line to find out whether e.g. any deletions took place, thats even more expensive from a user point of view.
Every time I need to do this I go back to tortoiseGIT or use git log --stat. I tought it would be nice if smartgit could display this information on demand. Since git log --stat already gives the available information (and has been pretty fast for me), I thought that it could be done.
Customer support service by UserEcho
Could we please get an option to make these settings (ignore line endings) enabled by default? Many other compare tools can do that.
While I welcome the possibility to view line ending changes, they usually obfuscate any other changes in the file. If the option will not be implemented, please consider to change the color of the line ending diff marks, so it is easy to separate them from content changes.