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 precisely as possible, so users will understand what you want. Please note that we appreciate your time and input, but we don't give any guarantees that a certain feature will be implemented. Usually, a minimum requirement is a sufficient number of votes. Hence, please don't comment like "when will this be implemented", but vote instead.

Follow the stackoverflow.com writing guidelines.

Thank you for your help!

+3
Completed

New Journal and Log: add "Full Name" width limit for Log (via low-level properties)

Sync 7 years ago updated by Thomas Singer 6 years ago 2

I have team mates with very long names, and I wish to use "Show Full Author" in the Log Window because I have team mates with similar initials.  The super long names are taking up too much width.


Please add property to limit the number of characters in the name field, after which an ellipsis will be used to truncate the name.

+3

Maintain state of Stash reveal arrow in Branches pane

griscom 7 years ago updated by W. Gauch 7 years ago 1

I like to see the list of stashes awaiting my attention, so I always keep the "reveal" triangle open on the "Stash" list in the "Branches" pane. However, SmartGit keeps closing it for me.


- If I close and reopen the application, the list always reappears closed.

- If I delete the last stash (the "Stash" list disappears, which is fine), and then add a new Stash, the list again reappears closed


It would be nice if SmartGit remembered my preference and kept the Stash list at its previous state.

+3

New Log and Journal: support log column headings (as in version 17.1)

colinw 7 years ago updated by Marc Strapetz 7 years ago 0

Image 222

+3

Add an option to switch back to compare algorithm of version 17

Jason Chen 7 years ago updated 7 years ago 2

I notice that `Reworked Compare` is a new feature of version 18. It compares code block by block rather than line by line. It looks cleaner than version 17.


However, the granularity of difference is much coarser than version 17. It lose the flexibility of editing code.


For example, the following picture is screen shot of version 18. I can only `stage` lines 5 to 7 or `discard` them all together.


Image 219


The following picture is screen shot of version 17. I can `discard` line 5 and 7 while `stage` line 6 individually just by three clicks. It is very convenient and flexible. I always think it is a best feature of `SmartGit` diff editor.


If I want to do the same thing in version 18 I must delete line 5 and 7 in my own editor and then `stage` line 6 in the `SmartGit`. It is very boring and inconvenient!


Image 220


I think it is easy to add an option to switch compare algorithm back to version 17. For example, add  button at the up-right corner of the compare pane. The default compare algorithm is version 18. If the button is clicked the compare algorithm is switched back to version 17. 


You can use the following sample code to check the algorithm difference between version 18 and version 17:


https://github.com/Jason2013/smartgit_compare.git


+3
Completed

Log: Rebase by drag and drop between Branches and Commits panels

MATSUDA Takashi 7 years ago updated by Marc Strapetz 4 years ago 8

On the 'Commits' panel, you can rebase by dragging and dropping branches.


But if the branch you want to rebase and the target commit are far
apart, drag & drop becomes hard and you have to check out once.


So how about dropping branch tags in the 'Commits' panel on the branch of
the 'Branches' panel, or conversely allowing branches on the 'Branches'
panel to be dropped onto the commit of the 'Commits' panel?


+3

New Journal and Log view: Set column widths and horizontal scroll

Mike 7 years ago updated 7 years ago 0

Restore the ability to set the column widths, even wider than than the pane, and horizontally scroll to see the columns that doesn't fit in the pane width for both the Journal pane and the Commits pane.

What exactly is the advantage of making the display area wider than the visible area? It means having parts of the information invisible.


  • It means I can set it so I see just a small part of a column (like just the month/day of the date (the year the time and the AM/PM are very much noise I rarely care to see), much more important to see more of another column like the message. Maybe I'd rather see half of the full name than just the compact name (initials).
  • It means that the pieces of information I'm usually interested are there and all I need to do is shift the horizontal scroll to see them when I want to know more about a particular commit, ie I can simply scroll back and forth with my eye still on the line of interest, not have to go take my eyes off the commit I'm interested in, find the menu to display another column, select that column or columns, find the line again, then do it all over to remove those columns.
  • Lastly, and this is related to the 1st reason, my Journal pane doesn't have enough room to display all of commit message summary. If I can change the width of the commit column, I can then read more of a particular commit message and then immediately make the column smaller. Or I could just leave it wide enough and horizontally scroll to read more when I want to.

The point is this is one of the things that make viewing a git repository via a GUI more useful than just using the command line, the ease with which you can view more information about commits together so you get a holistic view and understanding.

+3
Completed

Cancel in progress/scheduled background processes

Jeff Jensen 7 years ago updated by Marc Strapetz 5 years ago 5

With having more than a few dozen repos for different products (organized into groups), the SG background processes (e.g. fetch) can take awhile to run.  Sometimes I have to wait for them to finish before I can do something simple, such as open the log window, because SG disables nearly all UI actions while the background processes run.


When working offline, it takes so long to timeout that it's faster for me to restart SG.


At these moments I wish for a Cancel button to stop them.

+3

Sync horizontal scrolling in changes view

simgunz 7 years ago updated 7 years ago 1

In the changes view (within the log view), the horizontal scrolling should be synchronised also when the horizontal width of the two sides is different. Currently if one line in the right view is longer than any line in the left view, the horizontal scrolling of the two views is not properly synchronised.


(It can be seen also by the fact that the scroll bar in the right view is smaller than the one in the left view).

+3
Completed

Add "Fetch" button in the "Log" window

t linkowski 7 years ago updated by Thomas Singer 5 years ago 1

I love the "Fetch" button in the main SmartGit window. Please, add this button to the "Log" window too.

+3

Allow fetching a branch without checking it out

burbelgruff 7 years ago 0

I have a branch which is out of date with the server version.

I want to fetch the server code without switching to the branch.

Reason:

We have a very large c++ application that takes ~2 hours to build. If you have done a major change in a common header, everything needs to be recompiled.

Say you have three branches:

1. develop

2. Feature 1

3. Feature 2


1. You have done some long-term development of a library i feature 2

2. You switch to Feature 1 and change a common header

3. You build and commit and integrate to develop.

4. You want to switch to Feature 2 and continue working on it.

Problem: The time stamp of the common header changes, and you are forced to wait 2 hours for the build to complete. This is also the case if you integrate from develop after you have switched to Feature 2.


Our current solution:

a. Push Feature 2

b. Clone repository into a backup location

In backup location:

c. Check out Feature 2

d. Integrate develop into Feature 2 (Resolve conflicts if necessary)

e. Push Feature 2

Go back to main repository

f. Now we want to fetch Feature 2 without checking out, we use the command line:

git fetch origin feature/Feature_2:feature/Feature_2


We want this operation to be more automatic. The first step is to automate step f, which is the only step we currently cannot use SmartGit to solve.