Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

--color option does not always work #1308

Open
benoit-pierre opened this issue May 7, 2024 · 4 comments
Open

--color option does not always work #1308

benoit-pierre opened this issue May 7, 2024 · 4 comments
Labels
bug Something isn't working good first issue Good for newcomers has-workaround

Comments

@benoit-pierre
Copy link

Description of the bug

▸ git sl --color always | cat
# → no colors…

▸ git branchless smartlog --color always | cat
# → no colors…

▸ git branchless --color always smartlog | cat
# → colors!

Expected behavior

Colors in all 3 cases, no matter the position of the --color xxx option in the command line.

Actual behavior

Inconsistent behavior.

Version of rustc

rustc 1.75.0 (82e1608df 2023-12-21)

Automated bug report

No response

Version of git-branchless

git-branchless-opts 0.8.0

Version of git

git version 2.45.0

@benoit-pierre benoit-pierre added the bug Something isn't working label May 7, 2024
@arxanas
Copy link
Owner

arxanas commented May 11, 2024

Hi @benoit-pierre! I hope you're doing well. It's been a while since we corresponded on Plover-related stuff!

Unfortunately, I think this feature never worked as intended: #512. It seems like that PR caused the flag to be accepted in all positions, but, for whatever reason, the actual value is only processed in some positions. I see this note in the documentation now:

NOTE: Global arguments only propagate down, not up (to parent commands), however their values once a user uses them will be propagated back up to parents. In effect, this means one should define all global arguments at the top level, however it doesn’t matter where the user uses the global argument.

That being said, it might also be a misuse of the way that we parse global options while ignoring errors.

I don't know what the best solution is in this case —

  • It might be possible to read the value from the actual subcommand being executed.
  • I've also started seeing some applications permit global options only at the top-level, before any subcommands, which doesn't seem wholly unreasonable to me.

@mfulbright
Copy link

Hi - new git-branchless user here. I just wanted to say I was trying to figure out how to set up a pager for 'smartlog' output, while also keeping the color, and had no idea at all why it wasn't working. Every variation of git sl --color=always | less -R I tried was not maintaining the colors. Thank you very much Benoit! git branchless --color=always smartlo | less -R is working for me now.

(As an aside - are the rest of git-branchless users not piping smartlog output to a pager? Or they are, and just aren't having colored output? I can barely imagine living like that!)

@talios
Copy link

talios commented May 27, 2024 via email

@arxanas
Copy link
Owner

arxanas commented May 27, 2024

I've also started seeing some applications permit global options only at the top-level, before any subcommands, which doesn't seem wholly unreasonable to me.

This wouldn't work for most cases of aliases, namely git sl --color=XXX, so probably not a good option here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers has-workaround
Projects
None yet
Development

No branches or pull requests

4 participants