Or, even better, the SmartGit merge / interactive staging tool could ignore mismatched line endings and just do what I tell it to do. My other merge tools (e.g. Araxis Merge) don't seem to have any problems at all dealing with mismatched line endings.

Exactly. Sometimes line endings get screwed up for other reasons, after commit (misconfigured merge tool, using a different editor with different settings, etc).

I'd love a button that says "convert all line endings to <whatever is the dominant line ending in the file>". Would save me a lot of work.

I expanded upon this in a new request: "Add full support for shallow clone workflow"

I think what people may be look for here is something akin to the Perforce Revision Graph.

IMO that tool is the gold standard for understanding branching history.

It's possible that git may present some unique branching situations that Perforce did not have to handle (e.g. there was no 'rebase' in Perforce last time I used it). But since Perforce now lets you run on top of git, there must be some way of representing git revision history using their Revision Graph.

It avoids cluttering the graph with commit message information by only showing the selected revision's information in a separate pane (and tooltip, IIRC)

It's a workaround, but clumsy for a very common use case:

• I'm working on a task, but have to switch to something else, so I stash all the files so I can come back to it later.
• Some time later (perhaps weeks), I'm working on a different task, and I want to apply some -- but not all -- changes from the previous stash. A common example would be taking a single settings file from a previous multi-file stash.
• Currently I must first either A) stash all my current work away, apply the old stash, delete the files I don't want, then reapply the other stash, or B) apply the stash on top of my current work, hope that there are no conflicting files preventing me from unstashing, resolve any unwanted conflicts, and delete the unwanted files.

It's especially painful in our ~250,000 file repo in which individual stash/unstash and full refresh operations can take 20-30 seconds or more.

It would be much nicer if I could just select the individual files I wanted from the old stash and apply them in one operation.

Would it become harder to implement if the UI dialog was just an interface (again, key-value string pairs, no fancy widgets) that read from and wrote to the existing smartgit.properties file?

If smartgit did the following at startup:

• read in smartgit.properties
• wrote out smartit.properties after inserting any missing properties with their default values, perhaps with a comment containing the documentation

and then the dialog was just an interface to that document, would that be an acceptable level of work?

I agree that it's all very complicated, and that I don't quite understand how complicated it is -- which underscores the need to reduce the complexity of the current settings/customization options.

I don't have the perfect solution here, but it does appear to be a usability issue in its current incarnation; how much of an issue I suppose depends on how many votes this suggestion receives.

Anyone else have a better idea how to improve this situation?

It makes sense to me to have global settings all in one dialog (perhaps organized in tabs by area), and then per-branch settings in a separate dialog.

Example:

Before:

• Repository -> Settings
• Remote -> Properties
• Edit -> Preferences
• Edit -> Customize
• Changes -> Settings
• smartgit.properties file

After:

• Edit -> Settings -> Current Repository -> <keep existing dialog tabs>
• Edit -> Settings -> Current Repository -> <new tab: "Remote Properties>
• Edit -> Settings -> Application -> <keep existing structure>
• Edit -> Settings -> Application -> <old "Edit->Customize" tabs become new "Customize->Accelerators, Customize->ToolBars">
• Edit -> Settings -> Application -> <old "Changes->Settings" tabs become new "Customize->Changes Window" items>
• Edit -> Settings -> Application -> <smartgit.properties items now editable/discoverable via new "Advanced" item>

That solves the problem of having global vs per-repo properties clustered separately, yet reduces the 6 different settings dialogs down to 2

Thomas, I've read that interactive rebase on Windows is now 5x faster starting in git for windows 2.10. It may be worth revisiting the performance. https://blogs.msdn.microsoft.com/visualstudioalm/2016/09/03/whats-new-in-git-for-windows-2-10/

Here's a use case: we have a VM running some internal automation, and it has an older version of smartgit whose license we do not intend to update to a newer version. That version of smartgit presents us with notifications about new versions all the time, even though we never intend to upgrade it.

In this situation we would like to suppress these notifications.