Bug 521071 - Make max commit message width a workspace level configurable preference instead of having it hard-coded to 72
Summary: Make max commit message width a workspace level configurable preference inste...
Status: NEW
Alias: None
Product: EGit
Classification: Technology
Component: UI (show other bugs)
Version: 4.7   Edit
Hardware: PC Linux
: P3 enhancement with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-08-17 11:21 EDT by Michael Vorburger CLA
Modified: 2022-08-05 10:44 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Vorburger CLA 2017-08-17 11:21:57 EDT
That little fine dark grey line shown in the Git Staging view seems to be hard-coded to 72 columns.

I work all day along on a project where someone decided that 50 characters was enough for the a commit message header.

Therefore it would be cool if I could change the 72 to 50 in a Preference.

In fact, if that preference would let me put e.g. "50,72" and it would draw two such lines, that would be even more useful and cooler! ;)

Thanks a lot for EGit.
Comment 1 Michael Vorburger CLA 2017-08-17 11:23:12 EDT
> Therefore it would be cool if I could change the 72 to 50 in a Preference.

UI wise, Team > Git > Commiting > General is probably where I would look for this, maybe just under the "Maximum number of commit messages in history".
Comment 2 Thomas Wolf CLA 2017-08-21 05:09:58 EDT
Good idea. Maybe you would like to contribute this? Needs the preference UI and default setting, plus using the preference in SpellCheckableMessageArea. Plus tests.

Note that there may be strange effects when the preference changes. (Such as a message already wrapped at 72 characters getting re-wrapped at 50: we'll probably get a bunch of 22-character lines.)

Also: as long as you're only working on one "project", a workspace-global setting may be good enough. But what if you're working on different "projects" with different requirements in the same workspace? Maybe we'd need a project-level preference? Or a setting that could be set per repository?
Comment 3 Gayan Perera CLA 2020-05-01 11:08:20 EDT
I came across the same problem today when committing a change to JDT. I would say having it on the workspace level to start with will be more than enough. If there is a demand for project-level configuration we can add that as well, it also depends on how much effort we need to support the latter.