Maybe remove color output from tar_scm?

[jengelh]

Color codes from obs-service-tar_scm is copied verbatim into OBS status messages. I am impartial; the message is still readable, which is good enough for me. What do people think about removing (or keeping) the color codes?

# osc r -v
Debian_9.0           x86_64     broken: service error: [31mThe chosen parent_tag is not an ancestor of the checked out commit. Cannot compute a (meaningful) tag offset.[0m

(This error messages comes from PR #211 as I am running my own dogfood.)

[M0ses]

IIRC - tar_scm is not adding any color codes and I guess osc is doing neither. I would guess the git output contains the color codes from the beginning.

Maybe you also could solve your issue with a modification of your git config - color.* seems to be promising to me:

https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

[aspiers]

We should expect and support users who configure their git to output in colour, so it might be worth making tar_scm enforce disabling of colour, so that it works without requiring them to change their config.

[jengelh]

Nah, I should just make tar_scm do a isatty test, because (as I found out once again) it was myself who added the color codes.

[aspiers]

@M0ses commented on 19 Apr 2018, 20:09 BST:

IIRC - tar_scm is not adding any color codes

Actually it is, e.g.

obs-service-tar_scm/TarSCM/scm/git.py

Line 196 in c15f106

sys.exit("\033[31mNo parent tag present for the checked out "

@jengelh commented on 19 Jun 2018, 12:30 BST:

Nah, I should just make tar_scm do a isatty test, because (as I found out once again) it was myself who added the color codes.

Yeah, adding an isatty test sounds like a good option.

[jengelh]

I have an update, though it's based on the PR for #211 , so I'm waiting until that has gotten through.

[aspiers]

Thanks for the nudge - I'm not getting notifications from GitHub when new commits are pushed to PRs I'm watching, so I hadn't realised you'd updated it. Not sure how to fix that.