Skip to content

Conversation

flashios09
Copy link

@flashios09 flashios09 commented Sep 23, 2025

See #3404

@flashios09 flashios09 force-pushed the feat/3404-add-git-signs-option branch from 5ad42cf to 02dbe87 Compare September 23, 2025 03:44
@flashios09
Copy link
Author

@sand4rt take a look and tell me what you think :)

@Enselic
Copy link
Collaborator

Enselic commented Oct 9, 2025

Hi! What is the problem with the default signs? If they are problematic somehow it's probably better to fix the problems they have than to add complexity to the code and for users.

@flashios09
Copy link
Author

flashios09 commented Oct 9, 2025

than to add complexity to the code and for users

Hi @Enselic ,
Which complexity are you talking about ?

This PR will just add --gitsigns option, just like the --style option, used to customize user preferences.

This is how gitsigns looks with the modern preset(bat --gitsigns=modern path/to/file):
image

The whole feature is about 100 lines, 90% of those +1000 lines are just tests :)

@Enselic
Copy link
Collaborator

Enselic commented Oct 10, 2025

Ok, let's start with the first question.

What is the problem with the default signs?

@sand4rt
Copy link
Contributor

sand4rt commented Oct 10, 2025

Ok, let's start with the first question.

What is the problem with the default signs?

They are not the same as other terminal apps like gitsigns.nvim

@Enselic
Copy link
Collaborator

Enselic commented Oct 10, 2025

Why not make gitsigns configurable instead of bat?

@sand4rt
Copy link
Contributor

sand4rt commented Oct 10, 2025

Why not make gitsigns configurable instead of bat?

It is configurable in gitsigns, but i find the line-based indicators much clearer and easier to parse visually. In my opinion they reduce visual noise compared to the current symbols, and make diffs easier to scan. Popular editors like VSCode and JetBrains IDEs also use line markers as the default.

@flashios09
Copy link
Author

Ok, let's start with the first question.

What is the problem with the default signs?

Hi @Enselic , what is the problem with the default cat binary that comes with almost all UNIX based systems ?
The answer is OUTDATED, that's why we have bat, rg instead of grep, fd instead of find, eza instead of ls ...

What it the problem with the default signs ?

OUTDATED, we aren't in 2015 anymore when SublimeText2 was the most popular text editor(all the respect for SublimeText, still one of the best text editors), at that time, the default gitsigns was:

  • ~ in orange for modified lines
  • + in green for new(added) lines
  • - in red for deleted lines

Those aren't the "default" anymore, with the new era of text editors/IDE, VSCode and all its fork(Cursor ...), Intellij IDE, Neovim with gitsigns.nvim plugin, all are using new gitsigns:

  • | in blue for modified lines
  • | in green for new(added) lines
  • - in red for deleted lines

With this PR, we will be able to:

  1. Use the TextMate theme file to apply the colors to gitsigns(if the scope exists, otherwise use the current default colors), like this we can change/customize the modified/added/deleted sign colors
  2. Use the --gitsigns option to customize the signs, via the classic/modern preset or a custom 4 comma-separated characters(already mentioned/explained in the help command).

BEFORE(classic gitsigns):
image

AFTER(modern gitsigns):
image

Now tell me, which one is easier to get the git changes from ? classic preset or the modern one used by all modern text editors/IDE ?

PS:
This PR has 0 breaking changes, no effect at all on the default bat command with all the already existent options/config, classic(the current one) is still the default preset for gitsigns, which means only the user who wants to customize gitsigns, will need to use the new --gitsigns option or the BAT_GITSIGNS env var, just like the --style or --theme options.

@Enselic
Copy link
Collaborator

Enselic commented Oct 11, 2025

Sorry for being annoying. I just needed to be convinced this was a worthwhile thing to change, and now you have convinced me. Thank you for taking the time to do so.

I (or some other maintainer) will look at the details later when I get the time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants