Share your ideas on how to improve SmartGit!
This is no support platform! To report bugs or request support, please contact us directly. If in doubt ask us.
First search for a similar request and add your votes or comments there.
Take the time to describe your request as precise as possible, so we (Syntevo) and other users will understand what you want. A plain request "SmartGit should look cool" is too vague because we don't know what we should change, and hence will not be approved by us.
Thank you for your help!
Newly released Git LFS 2.0.0 comme with centralized "File locking".
- For now it is only supported by Github.com, but I expect Gitlab and Bitbucket to follow sooner or latter.
- It is only working with a centralized repository, that is when sharing a repository in a Github Organization, or when using a dedicated "on premise" server (using Gitlab there).
- It would be great to add support for the new "git lfs lock", "git lfs unlock" and "git lfs locks" commands.
- This would require at least a new status icon (Lock) but probably two (Lock by other), a row with the name of the user locking the file,
Note that in my experience, the command line is currently a bit confusing (HTTPS seems to work reliably only when basic authentication got through an explicit https://firstname.lastname@example.org URL).
There is a great feature in Log which gives changes between two commits.
But Details tab does not work at this mode.
Could you, please, put details of every commit in a selected file, so all of the details can bee seen at once for the file?
Or even more advanced feature: show in Details a committer when a particular change is shown in Changes window. So once the change is shown one can see who made the change.
Well, I always use SmartGit except when I want to clone a repository from our bitbucket server. For that purpose I use SourceTree. The explorer window is quite handy when you have so many repositories.
this would be handy eg. to ignore local changes made in configuration files.
i know there is staging, assume-unchanged, git-ignore and so on, but these are too complex and svn's changelist (IMHO) just the right thing for that.
there is also an stackoverflow thread with more info:
As a small aesthetic matter I'd suggest "local", over "Local Branches", would have the benefit of being visually consistent with the standard remote names "origin" and "upstream" that are often also displayed in the Branches window.
Customer support service by UserEcho