Color in git-log

前端 未结 5 1360
灰色年华
灰色年华 2020-12-02 08:01

When you run git log --decorate --pretty=oneline the output will have entries like (HEAD, refs/published/master, master) with coloration.

I

相关标签:
5条回答
  • 2020-12-02 08:12

    The config option log.decorate can enable/disable default decorations in logs.

    git config --global log.decorate full
    

    Once that is done you can use color.decorate.* to play with the colors

    0 讨论(0)
  • 2020-12-02 08:15

    Some may want to use this : %C(colorname) This doesn't need to change the color config.

    Example : Coloring the author name in yellow

    --pretty=format:"%C(yellow)%an%Creset"
    

    Regular ANSI colors should work https://en.wikipedia.org/wiki/ANSI_escape_code

    • black
    • red
    • green
    • yellow
    • blue
    • magenta
    • cyan
    • white
    0 讨论(0)
  • 2020-12-02 08:19

    Parenthesize them:

    %C(...): color specification, as described in color.branch.* config option

    So %C(yellow reverse) would work.

    0 讨论(0)
  • 2020-12-02 08:23

    As of git 1.8.3 (May 24, 2013), you can use %C(auto) to decorate %d in the format string of git log.

    From the release notes:

     * "git log --format" specifier learned %C(auto) token that tells Git
       to use color when interpolating %d (decoration), %h (short commit
       object name), etc. for terminal output.)
    
    0 讨论(0)
  • 2020-12-02 08:38

    The git log --decorate will put by default:

    • the HEAD in cyan
    • the remote branches in red
    • the tag in green

    and can be changed through color.decorate config.

    But the git log --format don't offer a way to display specifically the HEAD or remotes or branch: all three are displayed through %d, with one color possible.


    Update May 2013, as mentioned below by Elad Shahar (upvoted), git 1.8.3 offers one more option:

    git log –format now sports a %C(auto) token that tells Git to use color when resolving %d (decoration), %h (short commit object name), etc. for terminal output.

    This Atlassian blog post comments that this feature is part of several others focused on format (git rebase, git count-objects) and colors (git branch -vv)

    This comes in addition of the previous auto,reset of 1.8.2, which automatically disables colors when the output is not used for a terminal1

    %C(auto,blue)Hello%C(auto,reset)
    

    Note: git 2.4+ (Q2 2015) will do a better job of resetting color around branch names.
    See commit 5ee8758 by Junio C Hamano (gitster):

    log --decorate: do not leak "commit" color into the next item

    In "git log --decorate", you would see the commit header like this:

    commit ... (HEAD, jc/decorate-leaky-separator-color)
    

    where "commit ... (" is painted in color.diff.commit, "HEAD" in color.decorate.head, ", " in color.diff.commit, the branch name in color.decorate.branch and then closing ")" in color.diff.commit.

    If you wanted to paint the HEAD and local branch name in the same color as the body text (perhaps because cyan and green are too faint on a black-on-white terminal to be readable), you would not want to have to say

    [color "decorate"]
        head = black
        branch = black
    

    because that you would not be able to reuse same configuration on a white-on-black terminal. You would naively expect

    [color "decorate"]
        head = normal
    branch = normal
    

    to work, but unfortunately it does not.
    It paints the string "HEAD" and the branch name in the same color as the opening parenthesis or comma between the decoration elements.
    This is because the code forgets to reset the color after printing the "prefix" in its own color.


    Note that git 2.5 (Q2 2015) fixes a bug:

    See commit 429ad20 by Junio C Hamano (gitster), 13 May 2015.
    (Merged by Junio C Hamano -- gitster -- in commit fd70780, 22 May 2015)

    log: do not shorten decoration names too early

    The "log --decorate" enhancement in Git 2.4 that shows the commit at the tip of the current branch e.g. "HEAD -> master", did not work with --decorate=full.


    Git 2.9.x+ (Q3 2016) will fix another bug and honor color=auto for %C(auto)


    Git 2.10.2 (Oct. 2016) fixes other bugs with commit 82b83da (29 Sep 2016), and commit c99ad27 (17 Sep 2016) by René Scharfe (``).
    (Merged by Junio C Hamano -- gitster -- in commit 76796d4, 28 Oct 2016)

    pretty: avoid adding reset for %C(auto) if output is empty

    We emit an escape sequence for resetting color and attribute for %C(auto) to make sure automatic coloring is displayed as intended.
    Stop doing that if the output strbuf is empty, i.e. when %C(auto) appears at the start of the format string, because then there is no need for a reset and we save a few bytes in the output.

    pretty: let %C(auto) reset all attributes

    Reset colors and attributes upon %C(auto) to enable full automatic control over them; otherwise attributes like bold or reverse could still be in effect from previous %C placeholders.

    0 讨论(0)
提交回复
热议问题