That sounds quite do-able. I'll chuck a good-first-issue label on this. The presentation folder is where all that stuff is handled and we could pass a config struct in saying what fields the user wants to be present

Hi @jesseduffield. I would like to work on this issue.

I made a prototype for the normal view which is available here.
For now, the config string looks like this:

gui:
  commitTemplate: short-sha|author|message

I would like to discuss:

• which information will be available to display in the commit panel
• what will be the format of the configuration string and which config will be holding the setting (gui, theme or commit config)

@sergey-suslov nice work! I've just pulled your code and gave it a test and it works great.

Which info will be available: anything on the commit model i.e. pkg/commands/models/commit.go, but I think sha/author/message suffices for now given that's the known usecase.

Format of the config: I have a few thoughts on this. Firstly, we may want to end up support customisations for the columns of other panels too, so perhaps we should have a panelColumns key under the gui key. Then I wonder if we should have two config values: one for what we display in the default commis panel, and one for when we've maximised it with the '+' key. So maybe:

gui:
  panelColumns:
    commits: 
      small: short-sha|author|message
      large: <whatever the other one is>

As for the format of the value itself, I don't have an issue with using a single string with a '|' separator. Some possible alternatives are:

1. use a yaml array, given we're essentially just passing an array of things anyway
2. use go template syntax to pull the info directly out of the commit struct. I think this option would be overkill at this point

What are your thoughts?

@jesseduffield
Go templates would be a nice option and we could save a lot of time making all similar configurations generic, but since we have to support formatting (truncating, coloring, mandatory fields such as actions) we will need to construct some FormattedCommit object as a template base. Therefore, I believe that the usage of a fixed allowed options list will be a better solution.

Questions:

• Is it acceptable to keep all the commit template keys and the CommitTemplateKey type itself on the level of gui/presentation/commits.go or it would be better to lift them up?
• Should the first part of a message be colored according to the commit's status field or sha only, whether it present or not?
• Should I consider any customizations of the Date's format?

Proposal:

Fields

• Sha (short) – short-sha
• Name - name
• Author - author
• Date - date

Formatting:

• First section of a message is colored according to the status of a commit's
• Author length is fixed to 17 symbols
• Commit's name is prefixed by its Tags if present
• First section of a message is prefixed by the Action field if present
• The date field is formatted according to Mon Jan 02 15:04:05 2006 -0700 (original git implementation's format)

Configuration string format

gui:
  panelColumns:
    commits: 
      small: ['short-sha', 'name']
      large:  ['short-sha', 'date', 'author', 'name']

What do you think?