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 users will understand what you want.


Follow the stackoverflow.com writing guidelines.

Thank you for your help!

+2

Highlight matches of the the token at the cursor or selection in source viewers/editors

Pavel Novikov 3 years ago updated 3 years ago 3

When the viewer or editor highlights parts of code that match the token that is currently at the editing cursor or the current selection is a super useful productivity aid and I miss it a lot in SmartGit.

So called "match margin" would be cool to have as well.

You can see how it work in a lot of editors, e.g. godbolt.org: move the editing cursor to a token or select text, notice how matches are highlighted and the locations of matches are indicated on the vertical scroll bar (the "match margin").

Would be extremely useful while looking at changes and blaming/investigating to quickly locate where in code things are used.

+2

Improve stashing on fast-forward merge to the same commit

Gxost 3 years ago 0

I often have the following scenario:

  1. Current branch with non-clean working tree/index.
  2. A branch I want to switch to with origin head pointing to the same commit as current branch and with local head pointing to some older commit.
  3. When I switch to the target branch SmartGit asks for fast-forward merge and after accept I get lots of conflicts just because stashed changes are unstashed too early.

    I suggest the following fast-forward merge for such scenario:

    1. Stash changes.
    2. Switch to the target branch and perform fast-forward merge.
    3. Unstash changes.

    In this case because stashed changes are applied to the same commit no conflicts occur.

    +2

    Default username and email for new repository in a group

    shockworker 3 years ago updated by Jeff Jensen 3 years ago 3

    It would be great to have such an option. This will help to not to forget to change default username and email for just cloned repository in "job" or "home" group and don't push commit signed with your private email to repository in "job" group and vise versa.

    +2

    Multi-repository Support: Simultaneous Git-Flow Transactions

    Sean McNeill 3 years ago updated by Marc Strapetz 3 years ago 2

    I have many repositories, organized into groups. For example Project A will consists of four or five different repositories. When I do  a hotfix, I do it to all of the repositories used by that project, so they all have a 1.70.10 tag that I can build from, even if only one of the repositories changes. 

    So, it would be nice to perform operations like "finish hotfix" on multiple repositories (perhaps all in a Group) all at the same time, and have them all working on the git flow operations simultaneously. Right now I do them one at a time and it can be tedious. I have external scripts to accomplish this but it would be nice to be able to do it right from Smartgit.

    +2

    "revert whitespace changes" command

    benblo 3 years ago 0

    Tools like Visual Studio or Resharper often introduce lots of whitespace changes (mixed line endings, tabs), automatically.

    Sometimes I want them, to cleanup the files, but sometimes I just want to commit the bare minimum diff to reduce noise.

    I'd be nice to have an option to revert all the whitespace-only changes at once, either in the context menu, review pane, or file compare window.

    This should follow the same pattern as the "ignore no/leading/all whitespace" radio menu in the file compare window, ie the lines that are highlighted or not would be the ones reverted, so I can preview the revert and know it's safe.

    +2

    Commit: check for "hack" or "debug" markers in file modifications and make it hard to commit such files

    CodeBehemoth 3 years ago updated by Marc Strapetz 3 years ago 5

    Some changes ( hacks, debug code ) should not be committed. Therefore, the modified lines of files should be inspected for possible "hack" markers and on commit, I want to be asked to check these files.

    +2

    Give access to conflict solver even on non-conflicted files

    griscom 4 years ago updated 1 year ago 5

    I'm doing a complex merge between two branches. The five files with conflicts let me use the Conflict Solver to compare the two source branches to the mis-merged file, so I was able to resolve and stage the issues. Now, though, I have 365 changed, staged files, and I'd like to review the changes. I can see how they differ from the previous version of the master branch, but there's no way to see how they differ from the merged branch.

    I'd like to access the Conflict Solver, but it's dimmed out. Even if I un-stage the files, it's still dimmed out.

    Please allow use of the Conflict Solver on any file during a merge. Ideally I wouldn't have to un-stage each file to use it, but ideally I'd also be able to edit the merged file; not sure how you'd make both options possible.

    +2

    Copy repository name

    Jeff Jensen 4 years ago updated 4 years ago 2

    We can copy branch name but not a repository name (if that feature exists, I could not find it).  Please have Ctrl+c copy the highlighted repo name.

    Working with many repos I regularly need to message someone with a repository name and branch name; copying the branch name works nicely but must type the repo name.


    +2

    Ability to view size on disk difference of modified files

    Danny Lake 4 years ago 0

    We are coming from a centralized source control repository and adopting Git. One thing we loved about our old tool (SourceGear Vault) was that for our modified files, it showed us the difference of the modified file's size on disk compared to the current version in source control. This was helpful for us and provided some context on the size of the change we made to each file. 


    For example if one file has +10kb of changes, then we know that is a significant change and should be reviewed closely before committing, where as a +1 byte delta would tell us it was a trivial/minor change to the file.


    Having the ability to also sort on the file size delta was helpful to get the most significant changes (largest deltas) grouped together before committing, helping us see the biggest changes in one spot rather than sorted by filename or by folder. Sometimes we'd catch a 'console.log' statement in a file when sorting by size as well, as that change would be around +18 bytes to a file, which is easier to detect and remove before committing when sorting changes by size.

    See screenshots for where this would be great in SmartGit, and how it is displayed in SourceGear Vault: 

    Image 541

    Image 543

    +2
    Completed

    Partial Clone support (Git 2.19 and higher) [SG-13863]

    Marc Strapetz 4 years ago updated 3 years ago 7

    Support for the new "partial clone" feature of Git, as described at:

    https://git-scm.com/docs/partial-clone

    For SmartGit, this especially means to fetch missing blobs on-demand (status, Log display, ...).

    Related topics: