[Bug]: The color setting new-in-index is not working

[tummetott]

Version

• latest

version

lsd 1.0.0

What OS are you seeing the problem on?

macOS

installation

brew install lsd

term

wezterm

ls-colors

di=34:ln=37:so=33:pi=33:ex=31:bd=33:cd=33:su=35:sg=35:tw=35:ow=35:or=90:mi=90

What happened?

My colors.yaml looks like this:

git-status:
  new-in-index: dark_green
  modified: dark_yellow

When I change a already commited file in a git repo, the color of the identifier in the git column changes to yellow (as expected). However when I add the change to the index with git add <file>, the color is still yellow.

What expected?

I'd expect staged files to be colored with new-in-index

[tummetott]

@hpwxf could you provide some insight into this matter, considering your involvement in implementing this feature?

[tummetott]

I've realized that in a Git repository, new-in-index colors files that are both created and staged (but new to the git repo). Perhaps my initial understanding of this setting was incorrect. Is there an option to color files that are staged but not new? Many git-status color settings seem superfluous, while a crucial one appears absent. Ideally, color codes should clearly indicate if a file is modified (but not staged), staged, conflicted or unmodified (analog to the color coding of git status)

[hpwxf]

Is there an option to color files that are staged but not new?

In your case, the file already exists (not new) and something happens to it: it sounds related to the statuses typechange, deleted, renamed, or modified.
However, the staging is not identified by color but by the column like below:

left column: about the state in the index
right column: about the state in the directory (not yet in the index)

The statuses we can handle are those coming from git (git2-rs) itself and in the theme, we merge in the same color those appearing on the index and the directory (e.g. modified, renamed, typechange; the only exception we did was about new)

lsd/src/meta/git_file_status.rs

Line 27 in d2538a6

s if s.contains(git2::Status::INDEX_MODIFIED) => GitStatus::Modified,

lsd/src/meta/git_file_status.rs

Line 36 in d2538a6

s if s.contains(git2::Status::WT_MODIFIED) => GitStatus::Modified,

It would be possible to unmerge those statuses that were merged, but it would add 4 new status colors to do so.
Feel free to vote to identify whether this is a truly useful feature or an unnecessary complication.

[tummetott]

Sorry for my late reply; I've been very busy lately. Thank you for your response. I understand that staging is already indicated by the git-status column. However, I was wondering if it would be possible to implement the same color coding as used by git status. While it's acceptable to interpret the information from the symbols, I believe this approach is not ideal due to the numerous states, many of which are not crucial. In my opinion, merging them into three classes and allowing for the coloring of these classes would provide sufficient information:

class modified: [ 
    new_file_and_staged_and_then_modified,
    already_exists_and_modified, 
    already_exists_and_modified_and_staged_and_then_modified
]
class staged: [ 
    new_file_and_staged, 
    already_exists_and_modified_and_staged,
]
class conflicted: [ 
    conflicted_file
]

Is there a practical use case for differentiating between, for example, already_exists_and_modified_and_staged_and_then_modified and already_exists_and_modified? I think it's more important to know if any file is modified but not staged, so I can run git add before committing.

Another question: I noticed that you've implemented a patch allowing users to define icons for the git-status column, presumably in the git-theme branch. Is there any update on when this might be merged? Also, is there an issue tracking the discussion around the git-theme?