Your comments

Awesome, - beside the now in 20.2 broken dark mode, but that's a different topic - it seems to work flawlessly! Would be nice to see this feature in the next stable release :-)

Thanks!

Displaying images on the left/right would be great! In addition to the image diff, it would be helpful to see some metadata like filesize and image size (in pixels).

A slider for the image diff would be cool, but not very important. Currently you don't see anything when changing an image, so just displaying old and new images side by side would already be a huge improvement ;)

Actually it would be great if syntax highlighting specs were saved in separate files, so that the user is even able to add custom highlighting specs. For example I'm currently developing an application which uses its own file format, and it would be great to enable syntax highlighting for these files in SmartGit.


For some text editors I was able to enable syntax highlighting by creating a GtkSourceView Language Definition. But in SmartGit it seems that there is no way to add such a definition(?).

> what line separator to enter when the user presses <enter>, especially if the file is empty. How to handle text copy-pasted from some other source?


Some (good) editors have options to configure the behavior for that. So it's possible to specify the default line ending in the editor preferences, this line ending is then used when editing an empty file. If there are already lines in the file, pressing <enter> or pasting text into the file should always use the same line ending as already used in the file (auto detection). IMHO this is a good option for most of the possible use cases.


> If mixed line separators were detected, it will reject editing.


I would not do that as it can be annoying in some situations. I would strongly prefer a warning which is shown when editing a file with mixed line endings. Maybe even with an option to convert all line endings to LF or CRLF.

Yes, I know that, maybe the log was a bad (too simple) example ;) Often I need to quickly look for local changes, make a commit, merge a branch, push some commits and so on.


Maybe it's not very usual that one work "simultaneously" on many projects, but at least in our department this is very common. So we have to switch between different project quite often. And also some of our projects are related to each other, so if one make a change in repo1, one also needs to make a change in repo2. Because of this, it is most efficient to always keep all repositories open which we work on in our daily business.


But at the time of writing, I had just a brilliant idea for a workaround :) I could create a new repository group for my favorite repositories, and as I just saw it is possible to open all repositories of one category at once...

As I wrote above, I keep them open because opening large repositories takes too much time. For example when I'm working on repo1 and then quickly want to have a look on the log of repo2, switching to repo 2 takes ~5s and switching back to repo1 takes ~5s again. This is very annoying and prevents me from working efficiently.


I understand your argument about memory hog and bad performance. Maybe there were a compromise, for example:

  • Add a configuration option (either in the settings dialog or just in config files) to disable automatic closing of repositories.
  • Only close other repositories if memory usage, or the count of opened repositories is above a specific limit.
  • When opening a repository, make it possible to choose whether other repositories should be closed or not. For example with a context menu entry like "Open without closing others" or a keyboard modifier when double-clicking.
  • When adding/cloning a repository, add a checkbox like "Open repository after adding/cloning" which can be unchecked to prevent closing other repositories.

I could understand it if you don't like to add new GUI elements for this (advanced) feature. I would still be happy if the option was only available in config files. Btw. I have already increased the memory limit for SmartGit, so memory usage should't be a problem for me (any my colleagues).

That's true, but I see some advantages of a separate "git clean" feature in SmartGit:

  • "git clean" can also remove empty directories (I guess SmartGit only removes the selected files, but no directories).
  • Changing the filter options (two times) in the files view for a standard task is quite cumbersome.
  • A clean feature is less dangerous than manually changing the filter options each time (one small mistake and your local changes are lost forever).

That would be great! By the way, gitk already has this feature: