Thanks for pointing out the unexpected setup in our .mailmap file, I will fix that.

I confirm that SmartGit works as expected if I change to

 Vladimir Shulev <badfiles(at)mail.ru>

That being said, I would have expected SmartGit's behavior to match that of Git, and therefore be able to handle this more gracefully.

Hello Marc,

Thanks for the feedback.I checked (running SmartGit 22.1.7 #19285, installed: #19259). and it does seem that .mailmap is indeed taken into consideration somehow, but not in the expected way. Let me explain.

Looking at commits authored by badfiles in repository for MantisBT (https://github.com/mantisbt/mantisbt.git) with the following mailmap:

Vladimir Shulev <badfiles(at)mail.ru> badfiles
Vladimir Shulev <badfiles(at)mail.ru> root

Some examples from the log file, demonstrating correct transformation of the commit author by Git (column 2 shows the actual, "raw" commit author, column 3 after transformation):

$ git log --format="%h|%an|%aN" --author=badfiles |sort -k 2 -u
29cc2eb3c|Vladimir Shulev|Vladimir Shulev
ceae796e3|badfiles|Vladimir Shulev
128e3af17|root|Vladimir Shulev

Looking at these commits in SmartGit, I don't see the expected name (should be Vladimir Shulev), but it appears there is some transformation applied - the "B" in the avatar I guess is coming from "badfiles" (but should be "VS")

I hope this helps.

Well I did not expect my comment to cause this RFE to be unplanned :-(

Hopefully this can be reconsidered

Hello, is there any news on this enhancement's implementation ? The last update, 2 years ago, says it is Planned... But for when ?

Thanks in advance :-)

So this has been planned for 7 years now... Maybe an indication on when it is planned for would be good ;-)

Hi Thomas thanks for your reply.

I did, but it's not always an option unfortunately. Sometimes there are several remotes and the names are fixed due to external constraints; It may also be needed to work with different remotes depending on context, and it's not practical to keep changing the remote names as one could get confused and not know where they push anymore.

The Commit dialog should offer a button (and optionally a keyboard shortcut) to hard-wrap the selected text at word boundaries by inserting newline characters at the preset line length.

If no text is selected, wrapping should apply to the current paragraph, based on caret position. A paragraph is defined as a series of lines separated by one or more empty lines.

Long lines without spaces (e.g. a long URL), as well as the commit message's first line, should not be wrapped.

After reformatting, trailing whitespace on each line should be trimmed. Caret should be placed at the end of the wrapped paragraph's last line, or the initial selection restored.

To illustrate the expected behavior, see the VIM editor's gq command. Specifically, the {gq} performs wrapping on the current paragraph.

Optionally, an option (e.g. checkbox) to automatically apply word-wrapping while typing would be nice to have; this should be turned off by default, and preferences kept

I hope this helps.

I agree this can be closed; if the Use font configured... and Show linelength guides settings are enabled, then the Commit dialog

• shows a guideline at 50 for the first line and 72 for the message body
• highlights in red the line(s) that go over this limit

Which IMO fully satisfies the requirement.

I'm confused... Running SmartGit 20.1.4, I do not see these settings in the preferences dialog (or anywhere else for that matter). Did they move or were they removed since 18.1 ?

It was a little difficult to find the setting and somewhat painful to configure it, but in the end I managed to make it work.

Thanks for providing the possibilty to configure the certificates in Enterprise context.