名稱

git-log  - 顯示提交日志

概要

git log [<options>] [<revision range>] [[\--] <path>…]

描述

顯示提交日志。

該命令將采用適用于該git rev-list命令的選項來控制顯示的內(nèi)容和方式，以及適用于這些git diff-*命令的選項以控制每個提交所引發(fā)的更改的方式。

選項

--follow

繼續(xù)列出除重命名之外的文件歷史記錄（僅適用于單個文件）。

--no-decorate   --decorate=short|full|auto|no

打印出任何提交的 ref 名稱。如果short被指定，ref 名稱前綴refs/heads/，refs/tags/并且refs/remotes/將不被打印。如果full指定，將打印完整的參考名稱（包括前綴）。如果auto被指定，那么如果輸出到達(dá)終端，則 ref 名稱顯示為如果short給定，否則不顯示 ref 名稱。默認(rèn)選項是short。

--source

打印出每個提交到達(dá)的命令行給定的 ref 名稱。

--use-mailmap

使用郵件地圖文件將作者和提交者姓名和電子郵件地址映射到規(guī)范的實名和電子郵件地址。參見  git-shortlog [1]。

--full-diff

沒有此標(biāo)志，git log -p <path>...顯示提交觸摸指定的路徑，并且差異關(guān)于相同的指定的路徑。通過這個，完整的差異顯示為觸及指定路徑的提交; 這意味著“<path> ...”限制僅提交，并且不會限制這些提交的差異。

請注意，這會影響所有基于差異的輸出類型，例如由其生成的輸出類型--stat等。

--log-size

在每個提交的輸出中包含一行“l(fā)og size <number>”，其中<number>是該提交消息的長度（以字節(jié)為單位）。旨在git log通過提前分配空間來加速從輸出中讀取日志消息的工具。

-L <start>,<end>:<file>   -L :<funcname>:<file>

跟蹤<file>中由“<start>，<end>”（或函數(shù)名稱 regex <funcname>）給出的行范圍的演變。您不可以提供任何路徑限制器。這目前僅限于從單一修訂開始，也就是說，您可能只給出零個或一個正面修訂參數(shù)。您可以多次指定此選項。

<開始>和<結(jié)束>可以采取以下形式之一：

• 數(shù)字如果<開始>或<結(jié)束>是一個數(shù)字，它將指定一個絕對行號（行數(shù)從1開始）。

• / regex /此表單將使用與給定的POSIX正則表達(dá)式匹配的第一行。如果<start>是一個正則表達(dá)式，它將從前一個-L范圍的末尾（如果有的話）開始搜索，否則從文件起始處開始搜索。如果<start>是“^ / regex /”，它將從文件開頭搜索。如果<end>是一個正則表達(dá)式，它將從<start>給出的行開始搜索。

• + offset或-offset這僅對<end>有效，并將在<start>給出的行之前或之后指定行數(shù)。

如果給出“：<funcname>”來代替<start>和<end>，它是一個正則表達(dá)式，表示從匹配<funcname>的第一個funcname行到下一個funcname行的范圍?！埃?lt;funcname>”從上一個-L范圍的末尾（如果有）搜索，否則從文件開頭搜索?！癪：<funcname>”從文件開頭搜索。

<revision range>

僅顯示指定修訂范圍內(nèi)的提交。當(dāng)沒有指定<revision range>時，它默認(rèn)為HEAD（即導(dǎo)致當(dāng)前提交的整個歷史記錄）。origin..HEAD指定從當(dāng)前提交（ie HEAD）可訪問的所有提交，但不從origin。有關(guān)拼寫<修訂范圍>的完整列表，請參閱gitrevisions [7]Specifying Ranges部分。

-- <path>…

僅顯示足以解釋如何匹配指定路徑的文件的提交。有關(guān)History Simplification詳細(xì)信息和其他簡化模式，請參閱下文。

出現(xiàn)混淆時，路徑可能需要加前綴“ - ”，以將它們與選項或修訂范圍分開。

提交限制

除了指定應(yīng)使用描述中解釋的特殊符號列出的提交范圍之外，還可以應(yīng)用其他提交限制。

除非另有說明，否則使用更多選項通常會進(jìn)一步限制輸出（例如--since=<date1>限制為提交更新<date1>，并將其與--grep=<pattern>對其日志消息具有匹配的提交的進(jìn)一步限制進(jìn)行使用<pattern>）。

請注意，在提交排序和格式化選項之前應(yīng)用這些選項，例如--reverse。

-<number>   -n <number>   --max-count=<number>

限制提交輸出的數(shù)量。

--skip=<number>

在開始顯示提交輸出之前跳過提交number。

--since=<date>   --after=<date>

顯示比特定日期更近的提交。

--until=<date>   --before=<date>

顯示比特定日期更早的提交。

--author=<pattern>   --committer=<pattern>

將提交輸出限制為與指定模式（正則表達(dá)式）匹配的作者/提交者標(biāo)題行。使用多于一個--author=<pattern>，選擇作者匹配任何給定模式的提交（類似地為多個--committer=<pattern>）。

--grep-reflog=<pattern>

將提交輸出限制為具有與指定模式（正則表達(dá)式）匹配的 reflog 條目的提交輸出。使用多于一個--grep-reflog，選擇其 reflog 消息匹配任何給定模式的提交。除非--walk-reflogs正在使用，否則使用此選項是錯誤的。

--grep=<pattern>

將提交輸出限制為符合指定模式（正則表達(dá)式）的日志消息。使用多于一個--grep=<pattern>，提交的消息匹配任何給定模式的提交被選中（但請參閱--all-match）。

當(dāng)--show-notes生效時，來自筆記的消息就好像它是日志消息的一部分一樣。

--all-match

將提交輸出限制為匹配所有給定的提交--grep，而不是至少匹配一個提交。

--invert-grep

將提交輸出限制為與日志消息不匹配的模式--grep=<pattern>。

-i   --regexp-ignore-case

匹配正則表達(dá)式限制模式而不考慮字母大小寫。

--basic-regexp

考慮限制模式是基本的正則表達(dá)式； 這是默認(rèn)值。

-E   --extended-regexp

考慮限制模式是擴(kuò)展正則表達(dá)式而不是默認(rèn)的基本正則表達(dá)式。

-F   --fixed-strings

考慮限制模式為固定字符串（不要將模式解釋為正則表達(dá)式）。

-P   --perl-regexp

考慮限制模式是與 Perl 兼容的正則表達(dá)式。

對這些類型的正則表達(dá)式的支持是可選的編譯時間依賴性。如果 Git 沒有編譯支持它們，提供這個選項會導(dǎo)致它死亡。

--remove-empty

當(dāng)給定的路徑從樹上消失時停止。

--merges

僅打印合并提交。這與--min-parents=2完全一樣。

--no-merges

不要打印與多個父代的提交。這與--max-parents=1完全一樣。

--min-parents=<number>   --max-parents=<number>   --no-min-parents   --no-max-parents

僅顯示至少（或至多）多次父級提交的提交。特別--max-parents=1是一樣的--no-merges，--min-parents=2是一樣的--merges。--max-parents=0給出所有的根提交和--min-parents=3所有子分支合并。

--no-min-parents和--no-max-parents重新設(shè)置這些限制（無限制）。等價形式是--min-parents=0（任何承諾有0或更多父母）和--max-parents=-1（負(fù)數(shù)表示沒有上限）。

--first-parent

在查看合并提交后，只跟蹤第一個父提交。當(dāng)查看特定主題分支的演變時，此選項可以提供更好的概述，因為合并到主題分支往往只是適應(yīng)不斷更新的上游時間，并且此選項允許您忽略單獨提交到你的歷史通過這樣的合并。不能與--bisect結(jié)合使用。

--not

顛倒^所有后續(xù)修訂說明符的前綴（或缺少）的含義，直到下一個--not。

--all

假設(shè)所有的參考文件refs/，以及HEAD命令行都列為<commit>。

--branches=<pattern>

假設(shè)所有的參數(shù)refs/heads都在命令行中列為<commit>。如果<pattern>給出，則將分支限制為與給定shell glob 匹配的分支。如果模式?jīng)]有?，*或者[，/*在結(jié)束時暗示。

--tags=<pattern>

假設(shè)所有的參數(shù)refs/tags都在命令行中列為<commit>。如果<pattern>給出，則將標(biāo)簽限制為與給定 shell glob 匹配的標(biāo)簽。如果模式?jīng)]有?，*或者[，/*在結(jié)束時暗示。

--remotes=<pattern>

假設(shè)所有的參數(shù)refs/remotes都在命令行中列為<commit>。如果<pattern>給出，則將遠(yuǎn)程跟蹤分支限制為與給定 shell glob 匹配的分支。如果模式?jīng)]有?，*或者[，/*在結(jié)束時暗示。

--glob=<glob-pattern>

假設(shè)所有與 shell glob 匹配的 ref <glob-pattern>都在命令行中列出<commit>。領(lǐng)導(dǎo)refs/，如果失蹤，會自動添加前綴。如果模式?jīng)]有?，*或者[，/*在結(jié)束時暗示。

--exclude=<glob-pattern>

不包括裁判匹配<glob-pattern>，未來--all，--branches，--tags，--remotes，或--glob原本考慮。這個選項排除累積模式到下一個的重復(fù)--all，--branches，--tags，--remotes，或--glob選擇（其他選項或參數(shù)不清除積累的模式）。

給予不應(yīng)該開始的模式refs/heads，refs/tags或refs/remotes當(dāng)應(yīng)用到--branches，--tags或--remotes分別，他們必須開始refs/在應(yīng)用于--glob或--all。如果尾隨/*是有意的，則必須明確給出。

--reflog

假設(shè)所有 reflog 提到的對象都在命令行中列為<commit>。

--ignore-missing

在輸入中看到一個無效的對象名稱時，假裝沒有給出錯誤的輸入。

--bisect

假裝好壞的二等分參考文獻(xiàn)refs/bisect/bad被列出，并且仿佛它被跟隨，--not并且良好的平分參考refs/bisect/good-*命令行。不能與--first-parent 結(jié)合使用。

--stdin

除了<commit>在命令行上列出之外，還要從標(biāo)準(zhǔn)輸入中讀取它們。如果--看到分隔符，請停止讀取提交并開始讀取路徑以限制結(jié)果。

--cherry-mark

Like --cherry-pick (see below) but mark equivalent commits with = rather than omitting them, and inequivalent ones with +.

--cherry-pick

Omit any commit that introduces the same change as another commit on the “other side” when the set of commits are limited with symmetric difference.

For example, if you have two branches, A and B, a usual way to list all commits on only one side of them is with --left-right (see the example below in the description of the --left-right option). However, it shows the commits that were cherry-picked from the other branch (for example, “3rd on b” may be cherry-picked from branch A). With this option, such pairs of commits are excluded from the output.

--left-only   --right-only

List only commits on the respective side of a symmetric difference, i.e. only those which would be marked < resp. > by --left-right.

For example, --cherry-pick --right-only A...B omits those commits from B which are in A or are patch-equivalent to a commit in A. In other words, this lists the + commits from git cherry A B. More precisely, --cherry-pick --right-only --no-merges gives the exact list.

--cherry

A synonym for --right-only --cherry-mark --no-merges; useful to limit the output to the commits on our side and mark those that have been applied to the other side of a forked history with git log --cherry upstream...mybranch, similar to git cherry upstream mybranch.

-g   --walk-reflogs

Instead of walking the commit ancestry chain, walk reflog entries from the most recent one to older ones. When this option is used you cannot specify commits to exclude (that is, ^commit, commit1..commit2, and commit1...commit2 notations cannot be used).

With --pretty format other than oneline (for obvious reasons), this causes the output to have two extra lines of information taken from the reflog. The reflog designator in the output may be shown as ref@{Nth} (where Nth is the reverse-chronological index in the reflog) or as ref@{timestamp} (with the timestamp for that entry), depending on a few rules:

1. If the starting point is specified as ref@{Nth}, show the index format.

2. If the starting point was specified as ref@{now}, show the timestamp format.

3. If neither was used, but --date was given on the command line, show the timestamp in the format requested by --date.

4. Otherwise, show the index format.

• Under --pretty=oneline, the commit message is prefixed with this information on the same line. This option cannot be combined with --reverse. See also git-reflog[1].

--merge

After a failed merge, show refs that touch files having a conflict and don’t exist on all heads to merge.

--boundary

Output excluded boundary commits. Boundary commits are prefixed with -.

History Simplification

Sometimes you are only interested in parts of the history, for example the commits modifying a particular <path>. But there are two parts of History Simplification, one part is selecting the commits and the other is how to do it, as there are various strategies to simplify the history.

The following options select the commits to be shown:

<paths>

Commits modifying the given <paths> are selected.

--simplify-by-decoration

Commits that are referred by some branch or tag are selected.

Note that extra commits can be shown to give a meaningful history.

The following options affect the way the simplification is performed:

Default mode

Simplifies the history to the simplest history explaining the final state of the tree. Simplest because it prunes some side branches if the end result is the same (i.e. merging branches with the same content)

--full-history

Same as the default mode, but does not prune some history.

--dense

Only the selected commits are shown, plus some to have a meaningful history.

--sparse

All commits in the simplified history are shown.

--simplify-merges

Additional option to --full-history to remove some needless merges from the resulting history, as there are no selected commits contributing to this merge.

--ancestry-path

When given a range of commits to display (e.g. commit1..commit2 or commit2 ^commit1), only display commits that exist directly on the ancestry chain between the commit1 and commit2, i.e. commits that are both descendants of commit1, and ancestors of commit2.

A more detailed explanation follows.

Suppose you specified foo as the <paths>. We shall call commits that modify foo !TREESAME, and the rest TREESAME. (In a diff filtered for foo, they look different and equal, respectively.)

In the following, we will always refer to the same example history to illustrate the differences between simplification settings. We assume that you are filtering for a file foo in this commit graph:

          .-A---M---N---O---P---Q         /     /   /   /   /   /
        I     B   C   D   E   Y
         \   /   /   /   /   /
          `-------------'   X

The horizontal line of history A---Q is taken to be the first parent of each merge. The commits are:

• I is the initial commit, in which foo exists with contents “asdf”, and a file quux exists with contents “quux”. Initial commits are compared to an empty tree, so I is !TREESAME.

• In A, foo contains just “foo”.

• B contains the same change as A. Its merge M is trivial and hence TREESAME to all parents.

• C does not change foo, but its merge N changes it to “foobar”, so it is not TREESAME to any parent.

• D sets foo to “baz”. Its merge O combines the strings from N and D to “foobarbaz”; i.e., it is not TREESAME to any parent.

• E changes quux to “xyzzy”, and its merge P combines the strings to “quux xyzzy”. P is TREESAME to O, but not to E.

• X is an independent root commit that added a new file side, and Y modified it. Y is TREESAME to X. Its merge Q added side to P, and Q is TREESAME to P, but not to Y.

rev-list walks backwards through history, including or excluding commits based on whether --full-history and/or parent rewriting (via --parents or --children) are used. The following settings are available.

Default mode

Commits are included if they are not TREESAME to any parent (though this can be changed, see --sparse below). If the commit was a merge, and it was TREESAME to one parent, follow only that parent. (Even if there are several TREESAME parents, follow only one of them.) Otherwise, follow all parents.

This results in:

          .-A---N---O         /     /   /
        I---------D

Note how the rule to only follow the TREESAME parent, if one is available, removed B from consideration entirely. C was considered via N, but is TREESAME. Root commits are compared to an empty tree, so I is !TREESAME.

Parent/child relations are only visible with --parents, but that does not affect the commits selected in default mode, so we have shown the parent lines.

--full-history without parent rewriting

This mode differs from the default in one point: always follow all parents of a merge, even if it is TREESAME to one of them. Even if more than one side of the merge has commits that are included, this does not imply that the merge itself is! In the example, we get

        I  A  B  N  D  O  P  Q

M was excluded because it is TREESAME to both parents. E, C and B were all walked, but only B was !TREESAME, so the others do not appear.

Note that without parent rewriting, it is not really possible to talk about the parent/child relationships between the commits, so we show them disconnected.

--full-history with parent rewriting

Ordinary commits are only included if they are !TREESAME (though this can be changed, see --sparse below).

Merges are always included. However, their parent list is rewritten: Along each parent, prune away commits that are not included themselves. This results in

          .-A---M---N---O---P---Q         /     /   /   /   /
        I     B   /   D   /
         \   /   /   /   /
          `-------------'

Compare to --full-history without rewriting above. Note that E was pruned away because it is TREESAME, but the parent list of P was rewritten to contain E's parent I. The same happened for C and N, and X, Y and Q.

In addition to the above settings, you can change whether TREESAME affects inclusion:

--dense

Commits that are walked are included if they are not TREESAME to any parent.

--sparse

All commits that are walked are included.

Note that without --full-history, this still simplifies merges: if one of the parents is TREESAME, we follow only that one, so the other sides of the merge are never walked.

--simplify-merges

First, build a history graph in the same way that --full-history with parent rewriting does (see above).

Then simplify each commit C to its replacement C' in the final history according to the following rules:

• Set C' to C.

• Replace each parent P of C' with its simplification P'. In the process, drop parents that are ancestors of other parents or that are root commits TREESAME to an empty tree, and remove duplicates, but take care to never drop all parents that we are TREESAME to.

• If after this parent rewriting, C' is a root or merge commit (has zero or >1 parents), a boundary commit, or !TREESAME, it remains. Otherwise, it is replaced with its only parent.

The effect of this is best shown by way of comparing to --full-history with parent rewriting. The example turns into:

          .-A---M---N---O         /     /       /
        I     B       D
         \   /       /
          `---------'

Note the major differences in N, P, and Q over --full-history:

• N's parent list had I removed, because it is an ancestor of the other parent M. Still, N remained because it is !TREESAME.

• P's parent list similarly had I removed. P was then removed completely, because it had one parent and is TREESAME.

• Q's parent list had Y simplified to X. X was then removed, because it was a TREESAME root. Q was then removed completely, because it had one parent and is TREESAME.

Finally, there is a fifth simplification mode available:

--ancestry-path

Limit the displayed commits to those directly on the ancestry chain between the “from” and “to” commits in the given commit range. I.e. only display commits that are ancestor of the “to” commit and descendants of the “from” commit.

As an example use case, consider the following commit history:

            D---E-------F           /     \       \
          B---C---G---H---I---J         /                     \
        A-------K---------------L--M

A regular D..M computes the set of commits that are ancestors of M, but excludes the ones that are ancestors of D. This is useful to see what happened to the history leading to M since D, in the sense that “what does M have that did not exist in D”. The result in this example would be all the commits, except A and B (and D itself, of course).

When we want to find out what commits in M are contaminated with the bug introduced by D and need fixing, however, we might want to view only the subset of D..M that are actually descendants of D, i.e. excluding C and K. This is exactly what the --ancestry-path option does. Applied to the D..M range, it results in:

                E-------F
                 \       \
                  G---H---I---J
                               \
                                L--M

The --simplify-by-decoration option allows you to view only the big picture of the topology of the history, by omitting commits that are not referenced by tags. Commits are marked as !TREESAME (in other words, kept after history simplification rules described above) if (1) they are referenced by tags, or (2) they change the contents of the paths given on the command line. All other commits are marked as TREESAME (subject to be simplified away).

Commit Ordering

By default, the commits are shown in reverse chronological order.

--date-order

Show no parents before all of its children are shown, but otherwise show commits in the commit timestamp order.

--author-date-order

Show no parents before all of its children are shown, but otherwise show commits in the author timestamp order.

--topo-order

Show no parents before all of its children are shown, and avoid showing commits on multiple lines of history intermixed.

For example, in a commit history like this:

    ---1----2----4----7
        \               \         3----5----6----8---

where the numbers denote the order of commit timestamps, git rev-list and friends with --date-order show the commits in the timestamp order: 8 7 6 5 4 3 2 1.

With --topo-order, they would show 8 6 5 3 7 4 2 1 (or 8 7 4 2 6 5 3 1); some older commits are shown before newer ones in order to avoid showing the commits from two parallel development track mixed together.

--reverse

Output the commits chosen to be shown (see Commit Limiting section above) in reverse order. Cannot be combined with --walk-reflogs.

Object Traversal

These options are mostly targeted for packing of Git repositories.

--no-walk=(sorted|unsorted)

Only show the given commits, but do not traverse their ancestors. This has no effect if a range is specified. If the argument unsorted is given, the commits are shown in the order they were given on the command line. Otherwise (if sorted or no argument was given), the commits are shown in reverse chronological order by commit time. Cannot be combined with --graph.

--do-walk

Overrides a previous --no-walk.

Commit Formatting

--pretty=<format>   --format=<format>

Pretty-print the contents of the commit logs in a given format, where <format> can be one of oneline, short, medium, full, fuller, email, raw, format:<string> and tformat:<string>. When <format> is none of the above, and has %placeholder in it, it acts as if --pretty=tformat:<format> were given.

See the "PRETTY FORMATS" section for some additional details for each format. When =<format> part is omitted, it defaults to medium.

Note: you can specify the default pretty format in the repository configuration (see git-config[1]).

--abbrev-commit

Instead of showing the full 40-byte hexadecimal commit object name, show only a partial prefix. Non default number of digits can be specified with "--abbrev=<n>" (which also modifies diff output, if it is displayed).

This should make "--pretty=oneline" a whole lot more readable for people using 80-column terminals.

--no-abbrev-commit

Show the full 40-byte hexadecimal commit object name. This negates --abbrev-commit and those options which imply it such as "--oneline". It also overrides the log.abbrevCommit variable.

--oneline

This is a shorthand for "--pretty=oneline --abbrev-commit" used together.

--encoding=<encoding>

The commit objects record the encoding used for the log message in their encoding header; this option can be used to tell the command to re-code the commit log message in the encoding preferred by the user. For non plumbing commands this defaults to UTF-8. Note that if an object claims to be encoded in X and we are outputting in X, we will output the object verbatim; this means that invalid sequences in the original commit may be copied to the output.

--expand-tabs=<n>   --expand-tabs   --no-expand-tabs

Perform a tab expansion (replace each tab with enough spaces to fill to the next display column that is multiple of <n>) in the log message before showing it in the output. --expand-tabs is a short-hand for --expand-tabs=8, and --no-expand-tabs is a short-hand for --expand-tabs=0, which disables tab expansion.

By default, tabs are expanded in pretty formats that indent the log message by 4 spaces (i.e. medium, which is the default, full, and fuller).

--notes=<treeish>

Show the notes (see git-notes[1]) that annotate the commit, when showing the commit log message. This is the default for git log, git show and git whatchanged commands when there is no --pretty, --format, or --oneline option given on the command line.

By default, the notes shown are from the notes refs listed in the core.notesRef and notes.displayRef variables (or corresponding environment overrides). See git-config[1] for more details.

With an optional <treeish> argument, use the treeish to find the notes to display. The treeish can specify the full refname when it begins with refs/notes/; when it begins with notes/, refs/ and otherwise refs/notes/ is prefixed to form a full name of the ref.

Multiple --notes options can be combined to control which notes are being displayed. Examples: "--notes=foo" will show only notes from "refs/notes/foo"; "--notes=foo --notes" will show both notes from "refs/notes/foo" and from the default notes ref(s).

--no-notes

Do not show notes. This negates the above --notes option, by resetting the list of notes refs from which notes are shown. Options are parsed in the order given on the command line, so e.g. "--notes --notes=foo --no-notes --notes=bar" will only show notes from "refs/notes/bar".

--show-notes=<treeish>   --no-standard-notes

These options are deprecated. Use the above --notes/--no-notes options instead.

--show-signature

Check the validity of a signed commit object by passing the signature to gpg --verify and show the output.

--relative-date

Synonym for --date=relative.

--date=<format>

Only takes effect for dates shown in human-readable format, such as when using --pretty. log.date config variable sets a default value for the log command’s --date option. By default, dates are shown in the original time zone (either committer’s or author’s). If -local is appended to the format (e.g., iso-local), the user’s local time zone is used instead.

--date=relative shows dates relative to the current time, e.g. “2 hours ago”. The -local option has no effect for --date=relative.

--date=local is an alias for --date=default-local.

--date=iso (or --date=iso8601) shows timestamps in a ISO 8601-like format. The differences to the strict ISO 8601 format are:

• a space instead of the T date/time delimiter

• a space between time and time zone

• no colon between hours and minutes of the time zone

--date=iso-strict (or --date=iso8601-strict) shows timestamps in strict ISO 8601 format.

• --date=rfc (or --date=rfc2822) shows timestamps in RFC 2822 format, often found in email messages.

• --date=short shows only the date, but not the time, in YYYY-MM-DD format.

• --date=raw shows the date as seconds since the epoch (1970-01-01 00:00:00 UTC), followed by a space, and then the timezone as an offset from UTC (a + or - with four digits; the first two are hours, and the second two are minutes). I.e., as if the timestamp were formatted with strftime("%s %z")). Note that the -local option does not affect the seconds-since-epoch value (which is always measured in UTC), but does switch the accompanying timezone value.

• --date=unix shows the date as a Unix epoch timestamp (seconds since 1970). As with --raw, this is always in UTC and therefore -local has no effect.

• --date=format:... feeds the format ... to your system strftime, except for %z and %Z, which are handled internally. Use --date=format:%c to show the date in your system locale’s preferred format. See the strftime manual for a complete list of format placeholders. When using -local, the correct syntax is --date=format-local:....

• --date=default is the default format, and is similar to --date=rfc2822, with a few exceptions:

• there is no comma after the day-of-week

• the time zone is omitted when the local time zone is used

--parents

Print also the parents of the commit (in the form "commit parent…"). Also enables parent rewriting, see History Simplification below.

--children

Print also the children of the commit (in the form "commit child…"). Also enables parent rewriting, see History Simplification below.

--left-right

Mark which side of a symmetric difference a commit is reachable from. Commits from the left side are prefixed with < and those from the right with >. If combined with --boundary, those commits are prefixed with -.

For example, if you have this topology:

             y---b---b  branch B            / \ /           /   .          /   / \
         o---x---a---a  branch A

you would get an output like this:

        $ git rev-list --left-right --boundary --pretty=oneline A...B        >bbbbbbb... 3rd on b        >bbbbbbb... 2nd on b        <aaaaaaa... 3rd on a        <aaaaaaa... 2nd on a        -yyyyyyy... 1st on b        -xxxxxxx... 1st on a

--graph

Draw a text-based graphical representation of the commit history on the left hand side of the output. This may cause extra lines to be printed in between commits, in order for the graph history to be drawn properly. Cannot be combined with --no-walk.

This enables parent rewriting, see History Simplification below.

This implies the --topo-order option by default, but the --date-order option may also be specified.

--show-linear-break=<barrier>

When --graph is not used, all history branches are flattened which can make it hard to see that the two consecutive commits do not belong to a linear branch. This option puts a barrier in between them in that case. If <barrier> is specified, it is the string that will be shown instead of the default one.

Diff Formatting

Listed below are options that control the formatting of diff output. Some of them are specific to git-rev-list[1], however other diff options may be given. See git-diff-files[1] for more options.

-c

With this option, diff output for a merge commit shows the differences from each of the parents to the merge result simultaneously instead of showing pairwise diff between a parent and the result one at a time. Furthermore, it lists only files which were modified from all parents.

--cc

This flag implies the -c option and further compresses the patch output by omitting uninteresting hunks whose contents in the parents have only two variants and the merge result picks one of them without modification.

-m

This flag makes the merge commits show the full diff like regular commits; for each merge parent, a separate log entry and diff is generated. An exception is that only diff against the first parent is shown when --first-parent option is given; in that case, the output represents the changes the merge brought into the then-current branch.

-r

Show recursive diffs.

-t

Show the tree objects in the diff output. This implies -r.

Pretty formats

If the commit is a merge, and if the pretty-format is not oneline, email or raw, an additional line is inserted before the Author: line. This line begins with "Merge: " and the sha1s of ancestral commits are printed, separated by spaces. Note that the listed commits may not necessarily be the list of the direct parent commits if you have limited your view of history: for example, if you are only interested in changes related to a certain directory or file.

There are several built-in formats, and you can define additional formats by setting a pretty.<name> config option to either another format name, or a format: string, as described below (see git-config[1]). Here are the details of the built-in formats:

• oneline<sha1> <title line>

This is designed to be as compact as possible.

• shortcommit <sha1> Author: <author>

<title line>

• mediumcommit <sha1> Author: <author> Date:   <author date>

<title line>

<full commit message>

• fullcommit <sha1> Author: <author> Commit: <committer>

<title line>

<full commit message>

• fullercommit <sha1> Author:     <author> AuthorDate: <author date> Commit:     <committer> CommitDate: <committer date>

<title line>

<full commit message>

• emailFrom <sha1> <date> From: <author> Date: <author date> Subject: PATCH <title line>

<full commit message>

• rawThe raw format shows the entire commit exactly as stored in the commit object. Notably, the SHA-1s are displayed in full, regardless of whether --abbrev or --no-abbrev are used, and parents information show the true parent commits, without taking grafts or history simplification into account. Note that this format affects the way commits are displayed, but not the way the diff is shown e.g. with git log --raw. To get full object names in a raw diff format, use --no-abbrev.

• format:<string>The format:<string> format allows you to specify which information you want to show. It works a little bit like printf format, with the notable exception that you get a newline with %n instead of \n. E.g, format:"The author of %h was %an, %ar%nThe title was >>%s<<%n" would show something like this:  The author of fe6e0ee was Junio C Hamano, 23 hours ago The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<

The placeholders are:

-  `%H`: commit hash

-  `%h`: abbreviated commit hash

-  `%T`: tree hash

-  `%t`: abbreviated tree hash

-  `%P`: parent hashes

-  `%p`: abbreviated parent hashes

-  `%an`: author name

-  `%aN`: author name (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ae`: author email

-  `%aE`: author email (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ad`: author date (format respects --date= option)

-  `%aD`: author date, RFC2822 style

-  `%ar`: author date, relative

-  `%at`: author date, UNIX timestamp

-  `%ai`: author date, ISO 8601-like format

-  `%aI`: author date, strict ISO 8601 format

-  `%cn`: committer name

-  `%cN`: committer name (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ce`: committer email

-  `%cE`: committer email (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%cd`: committer date (format respects --date= option)

-  `%cD`: committer date, RFC2822 style

-  `%cr`: committer date, relative

-  `%ct`: committer date, UNIX timestamp

-  `%ci`: committer date, ISO 8601-like format

-  `%cI`: committer date, strict ISO 8601 format

-  `%d`: ref names, like the --decorate option of [git-log[1]](git-log)

-  `%D`: ref names without the " (", ")" wrapping.

-  `%e`: encoding

-  `%s`: subject

-  `%f`: sanitized subject line, suitable for a filename

-  `%b`: body

-  `%B`: raw body (unwrapped subject and body)

-  `%N`: commit notes

-  `%GG`: raw verification message from GPG for a signed commit

-  `%G?`: show "G" for a good (valid) signature, "B" for a bad signature, "U" for a good signature with unknown validity, "X" for a good signature that has expired, "Y" for a good signature made by an expired key, "R" for a good signature made by a revoked key, "E" if the signature cannot be checked (e.g. missing key) and "N" for no signature

-  `%GS`: show the name of the signer for a signed commit

-  `%GK`: show the key used to sign a signed commit

-  `%gD`: reflog selector, e.g., `refs/stash@{1}` or `refs/stash@{2 minutes ago`}; the format follows the rules described for the `-g` option. The portion before the `@` is the refname as given on the command line (so `git log -g refs/heads/master` would yield `refs/heads/master@{0}`).

-  `%gd`: shortened reflog selector; same as `%gD`, but the refname portion is shortened for human readability (so `refs/heads/master` becomes just `master`).

-  `%gn`: reflog identity name

-  `%gN`: reflog identity name (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%ge`: reflog identity email

-  `%gE`: reflog identity email (respecting .mailmap, see [git-shortlog[1]](git-shortlog) or [git-blame[1]](git-blame))

-  `%gs`: reflog subject

-  `%Cred`: switch color to red

-  `%Cgreen`: switch color to green

-  `%Cblue`: switch color to blue

-  `%Creset`: reset color

-  `%C(…)`: color specification, as described under Values in the "CONFIGURATION FILE" section of [git-config[1]](git-config). By default, colors are shown only when enabled for log output (by `color.diff`, `color.ui`, or `--color`, and respecting the `auto` settings of the former if we are going to a terminal). `%C(auto,...)` is accepted as a historical synonym for the default (e.g., `%C(auto,red)`). Specifying `%C(always,...) will show the colors even when color is not otherwise enabled (though consider just using `--color=always` to enable color for the whole output, including this format and anything else git might color). `auto` alone (i.e. `%C(auto)`) will turn on auto coloring on the next placeholders until the color is switched again.

-  `%m`: left (`<`), right (`>`) or boundary (`-`) mark

-  `%n`: newline

-  `%%`: a raw `%`

-  `%x00`: print a byte from a hex code

-  `%w([<w>[,<i1>[,<i2>]]])`: switch line wrapping, like the -w option of [git-shortlog[1]](git-shortlog).

-  `%<(<N>[,trunc|ltrunc|mtrunc])`: make the next placeholder take at least N columns, padding spaces on the right if necessary. Optionally truncate at the beginning (ltrunc), the middle (mtrunc) or the end (trunc) if the output is longer than N columns. Note that truncating only works correctly with N >= 2.

-  `%<|(<N>)`: make the next placeholder take at least until Nth columns, padding spaces on the right if necessary

-  `%>(<N>)`, `%>|(<N>)`: similar to `%<(<N>)`, `%<|(<N>)` respectively, but padding spaces on the left

-  `%>>(<N>)`, `%>>|(<N>)`: similar to `%>(<N>)`, `%>|(<N>)` respectively, except that if the next placeholder takes more spaces than given and there are spaces on its left, use those spaces

-  `%><(<N>)`, `%><|(<N>)`: similar to `% <(<N>)`, `%<|(<N>)` respectively, but padding both sides (i.e. the text is centered)

-  %(trailers): display the trailers of the body as interpreted by [git-interpret-trailers[1]](git-interpret-trailers)

If you add a + (plus sign) after % of a placeholder, a line-feed is inserted immediately before the expansion if and only if the placeholder expands to a non-empty string.

If you add a - (minus sign) after % of a placeholder, all consecutive line-feeds immediately preceding the expansion are deleted if and only if the placeholder expands to an empty string.

If you add a  (space) after % of a placeholder, a space is inserted immediately before the expansion if and only if the placeholder expands to a non-empty string.

• tformat:The tformat: format works exactly like format:, except that it provides "terminator" semantics instead of "separator" semantics. In other words, each commit has the message terminator character (usually a newline) appended, rather than a separator placed between entries. This means that the final entry of a single-line format will be properly terminated with a new line, just as the "oneline" format does. For example:  $ git log -2 --pretty=format:%h 4da45bef \   | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' 4da45be 7134973 -- NO NEWLINE  $ git log -2 --pretty=tformat:%h 4da45bef \   | perl -pe '$_ .= " -- NO NEWLINE\n" unless /\n/' 4da45be 7134973

In addition, any unrecognized string that has a % in it is interpreted as if it has tformat: in front of it. For example, these two are equivalent:

$ git log -2 --pretty=tformat:%h 4da45bef $ git log -2 --pretty=%h 4da45bef

Common diff options

-p   -u   --patch

Generate patch (see section on generating patches).

-s   --no-patch

Suppress diff output. Useful for commands like git show that show the patch by default, or to cancel the effect of --patch.

-U<n>   --unified=<n>

Generate diffs with <n> lines of context instead of the usual three. Implies -p.

--raw

For each commit, show a summary of changes using the raw diff format. See the "RAW OUTPUT FORMAT" section of git-diff[1]. This is different from showing the log itself in raw format, which you can achieve with --format=raw.

--patch-with-raw

Synonym for -p --raw.

--indent-heuristic   --no-indent-heuristic

These are to help debugging and tuning experimental heuristics (which are off by default) that shift diff hunk boundaries to make patches easier to read.

--minimal

Spend extra time to make sure the smallest possible diff is produced.

--patience

Generate a diff using the "patience diff" algorithm.

--histogram

Generate a diff using the "histogram diff" algorithm.

--diff-algorithm={patience|minimal|histogram|myers}

Choose a diff algorithm. The variants are as follows:

default, myers

The basic greedy diff algorithm. Currently, this is the default.

minimal

Spend extra time to make sure the smallest possible diff is produced.

patience

Use "patience diff" algorithm when generating patches.

histogram

This algorithm extends the patience algorithm to "support low-occurrence common elements".

For instance, if you configured diff.algorithm variable to a non-default value and want to use the default one, then you have to use --diff-algorithm=default option.

--stat[=<width>[,<name-width>,<count>]]

Generate a diffstat. By default, as much space as necessary will be used for the filename part, and the rest for the graph part. Maximum width defaults to terminal width, or 80 columns if not connected to a terminal, and can be overridden by <width>. The width of the filename part can be limited by giving another width <name-width> after a comma. The width of the graph part can be limited by using --stat-graph-width=<width> (affects all commands generating a stat graph) or by setting diff.statGraphWidth=<width> (does not affect git format-patch). By giving a third parameter <count>, you can limit the output to the first <count> lines, followed by ... if there are more.

These parameters can also be set individually with --stat-width=<width>, --stat-name-width=<name-width> and --stat-count=<count>.

--numstat

Similar to --stat, but shows number of added and deleted lines in decimal notation and pathname without abbreviation, to make it more machine friendly. For binary files, outputs two - instead of saying 0 0.

--shortstat

Output only the last line of the --stat format containing total number of modified files, as well as number of added and deleted lines.

--dirstat=<param1,param2,…>

Output the distribution of relative amount of changes for each sub-directory. The behavior of --dirstat can be customized by passing it a comma separated list of parameters. The defaults are controlled by the diff.dirstat configuration variable (see git-config[1]). The following parameters are available:

changes

Compute the dirstat numbers by counting the lines that have been removed from the source, or added to the destination. This ignores the amount of pure code movements within a file. In other words, rearranging lines in a file is not counted as much as other changes. This is the default behavior when no parameter is given.

lines

通過執(zhí)行常規(guī)基于行的差異分析來計算 dirstat 數(shù)字，并且將移除/添加的行數(shù)相加。（對于二進(jìn)制文件，取而代之的是計算64字節(jié)的塊，因為二進(jìn)制文件沒有自然的行概念）。這是一種--dirstat比changes行為更為昂貴的行為，但它可以像其他更改一樣對文件中的重新排列的行進(jìn)行計數(shù)。結(jié)果輸出與您從其他--*stat選項中獲得的結(jié)果一致。

files

通過計算更改的文件數(shù)量來計算 dirstat 數(shù)字。dirstat 分析中每個更改的文件都相同。這是計算上最便宜的--dirstat行為，因為它根本不需要查看文件內(nèi)容。

cumulative

計數(shù)父目錄的子目錄中的更改。請注意，使用時cumulative，報告的百分比總和可能超過100％。默認(rèn)（非累積）行為可以用noncumulative參數(shù)指定。

<limit>

整數(shù)參數(shù)指定截斷百分比（默認(rèn)為3％）。輸出中不顯示貢獻(xiàn)小于此百分比的目錄。

示例：以下內(nèi)容將計數(shù)已更改的文件，同時忽略占已更改文件總數(shù)少于10％的目錄，并累積父目錄中的子目錄計數(shù)：--dirstat=files,10,cumulative。

--summary

輸出擴(kuò)展頭信息的精簡摘要，如創(chuàng)建，重命名和模式更改。

--patch-with-stat

-p --stat的同義詞。

-z

用多個 NUL 分開提交，而不用新的換行符。

此外，當(dāng)--raw或--numstat已經(jīng)給出，請勿使用路徑名并將 NUL 用作輸出字段終止符。

如果沒有這個選項，帶有“不尋?！弊址穆窂矫麑凑张渲米兞康恼f明引用core.quotePath（請參閱 git-config [1]）。

--name-only

僅顯示已更改文件的名稱。

--name-status

僅顯示已更改文件的名稱和狀態(tài)。有關(guān)--diff-filter狀態(tài)字母的含義，請參閱選項說明。

--submodule=<format>

指定如何顯示子模塊中的差異。指定使用--submodule=short的short格式時。這種格式只顯示范圍開始和結(jié)束處的提交名稱。當(dāng)--submodule或者--submodule=log被指定時，使用log格式。這種格式列出了像 git-submodule [1] summary那樣的提交。當(dāng)--submodule=diff指定時，使用diff格式。這種格式顯示了提交范圍內(nèi)子模塊內(nèi)容變化的內(nèi)聯(lián)比較。如果配置選項未設(shè)置，則默認(rèn)為diff.submodule或short格式。

--color=<when>

顯示有色差異。--color（即沒有=<when>）是一樣的--color=always。<when>可以是一個always，never或auto。

--no-color

關(guān)閉有色差異。它和--color=never一樣。

--word-diff=<mode>

顯示一個單詞 diff，使用<mode>分隔已更改的單詞。默認(rèn)情況下，單詞由空格分隔; 見--word-diff-regex下文。<mode>默認(rèn)為plain，并且必須是以下之一：

color

僅使用顏色突出顯示更改的詞。意味著--color。

plain

將單詞顯示為[-removed-]和{+added+}。如果輸入中出現(xiàn)分隔符，則不會嘗試跳過分隔符，因此輸出可能不明確。

porcelain

使用專門用于腳本消費的基于行的格式。以通常的統(tǒng)一差異格式打印已添加/已刪除/未更改的運行，以行開頭處的+/ -/字符開始并延伸至行尾。輸入中~的換行符通過它自己的一行代字符表示。

none

再次禁用字差異。

請注意，盡管第一個模式的名稱，如果啟用，顏色將用于突出顯示所有模式中更改的部分。

--word-diff-regex=<regex>

使用<regex>來決定一個單詞是什么，而不是將非空白的運行視為一個單詞。也意味著--word-diff除非已經(jīng)啟用。

每個<regex>的非重疊匹配都被視為一個單詞。為了找到差異，這些匹配之間的任何內(nèi)容都被認(rèn)為是空白并被忽略（?。?。你可能想追|[^[:space:]]加到你的正則表達(dá)式，以確保它匹配所有非空白字符。包含換行符的匹配在換行符處被無提地截斷（！）。

例如，--word-diff-regex=.將每個字符看作單詞，并相應(yīng)地逐個字符地顯示差異。

正則表達(dá)式也可以通過 diff 驅(qū)動程序或配置選項來設(shè)置，請參閱 gitattributes [5]或 git-config [1]。明確給予它覆蓋任何 diff 驅(qū)動程序或配置設(shè)置。差異驅(qū)動程序覆蓋配置設(shè)置

--color-words=<regex>

相當(dāng)于--word-diff=color加（如果指定了正則表達(dá)式）--word-diff-regex=<regex>。

--no-renames

關(guān)閉重命名檢測，即使配置文件提供了默認(rèn)設(shè)置。

--check

警告如果更改引入沖突標(biāo)記或空白錯誤。認(rèn)為空白錯誤是由core.whitespace配置控制的。默認(rèn)情況下，尾隨空格（包括單獨由空格組成的行）和空格字符（緊跟該行的初始縮進(jìn)內(nèi)的制表符后面的空格字符）將被視為空白錯誤。如果發(fā)現(xiàn)問題，則退出非零狀態(tài)。與--exit-code 不兼容。

--ws-error-highlight=<kind>

突出顯示空白的錯誤context，old或者new把差異線。多個值以逗號分隔，none重置以前的值，default將列表重置為new和all簡寫為old,new,context。如果未給出此選項，并且diff.wsErrorHighlight未設(shè)置配置變量，則只會new突出顯示行中的空白錯誤?？瞻族e誤是彩色的color.diff.whitespace。

--full-index

在生成補(bǔ)丁格式輸出時，在“索引”行上顯示完整的映像前和映像后blob對象名稱，而不是第一批字符。

--binary

除了--full-index，輸出可以應(yīng)用git-apply的二進(jìn)制差異。

--abbrev=<n>

不是在 diff-raw 格式輸出和 diff-tree 標(biāo)題行中顯示完整的40字節(jié)十六進(jìn)制對象名稱，只顯示部分前綴。這與--full-index上面的選項無關(guān)，后者控制 diff-patch 輸出格式。非默認(rèn)的位數(shù)可以用指定--abbrev=<n>。

-B<n>   --break-rewrites[=<n>]

將完全重寫更改分解為刪除和創(chuàng)建對。這有兩個目的：

它影響到一種改變的方式，這種改變相當(dāng)于整個文件的重寫，而不是像一系列刪除和插入混合在一起，只有幾行文本與上下文相匹配，但是作為一個單一的刪除舊的一切，隨后是一個單次插入所有新事物，并且數(shù)字m控制-B 選項的這個方面（默認(rèn)為60％）。-B/70%指定只有少于30％的原始數(shù)據(jù)應(yīng)保留在 Git 的結(jié)果中，以便將其視為全部重寫（否則結(jié)果補(bǔ)丁將是一系列與上下文行混合的刪除和插入）。

與-M 一起使用時，完全重寫的文件也被認(rèn)為是重命名的來源（通常-M僅考慮作為重命名源消失的文件），并且該數(shù)字n控制著-B 選項的這個方面（默認(rèn)為50％）。-B20%指定添加和刪除相對于文件大小的20％或更多的更改有資格作為可能的重命名源到另一個文件。

-M<n>   --find-renames=<n>

如果生成差異，則檢測并報告每次提交的重命名。在遍歷歷史記錄時跨越重命名后續(xù)文件，請參閱--follow。如果n被指定，則它是相似度指數(shù)的閾值（即與文件大小相比的添加/刪除量）。例如，-M90%如果超過90％的文件沒有改變，Git 應(yīng)該考慮刪除/添加對是一個重命名。如果沒有%符號，該數(shù)字應(yīng)作為分?jǐn)?shù)讀取，并在其前面加小數(shù)點。即，-M5變成0.5，并且因此是相同的-M50%。同樣的，-M05也是一樣的-M5%。要將檢測限制為精確重命名，請使用-M100%。默認(rèn)相似度指數(shù)為50％。

-C<n>   --find-copies=<n>

檢測副本以及重命名。另見--find-copies-harder。如果n被指定，它的含義與-M<n>。

--find-copies-harder

出于性能原因，默認(rèn)情況下，-C只有當(dāng)副本的原始文件在相同的變更集中被修改時，選項才會查找副本。該標(biāo)志使命令檢查未修改的文件作為復(fù)制源的候選項。對于大型項目來說，這是一項非常昂貴的操作，因此請謹(jǐn)慎使用。給予多個-C選項具有相同的效果。

-D   --irreversible-delete

省略原圖像進(jìn)行刪除，即僅打印標(biāo)題，但不打印原像和之間的差異/dev/null。由此產(chǎn)生的補(bǔ)丁不適用于patch或git apply; 這僅適用于那些想專注于更改后查看文本的人。另外，輸出顯然缺乏足夠的信息來反向應(yīng)用這樣的補(bǔ)丁，即使是手動補(bǔ)丁也是如此，因此也就是選項的名稱。

在與-B刪除/創(chuàng)建對的刪除部分一起使用時，還要省略原圖。

-l<num>

在-M和-C選項需要為O（n ^ 2）的處理時間，其中n是/復(fù)制目標(biāo)潛在的重命名的數(shù)目。如果重命名/復(fù)制目標(biāo)的數(shù)量超過指定的數(shù)量，則此選項可防止重命名/復(fù)制檢測運行。

--diff-filter=[(A|C|D|M|R|T|U|X|B)…*]

選擇僅添加（A），復(fù)制（C），刪除（D），修改（M），重命名（R），其類型（即常規(guī)文件，符號鏈接，子模塊，...）更改（T），Unmerged（U），未知（X）或已配對 Broken（B）。可以使用任何過濾字符的組合（包括無）。當(dāng)*（全部或無）添加到組合中時，如果有任何文件與比較中的其他條件匹配，則選擇所有路徑; 如果沒有與其他標(biāo)準(zhǔn)匹配的文件，則不會選擇任何內(nèi)容。

此外，這些大寫字母可以降低排除。例如--diff-filter=ad排除添加和刪除的路徑。

-S<string>

查找改變文件中指定字符串出現(xiàn)次數(shù)（即添加/刪除）的差異。旨在供劇本使用。

當(dāng)你尋找一個精確的代碼塊（比如一個結(jié)構(gòu)體）并且想知道該塊自第一次出現(xiàn)以來的歷史記錄時，它非常有用：迭代地使用該特征將原始圖像中的有趣塊返回到-S，并繼續(xù)前進(jìn)，直到獲得該塊的第一個版本。

-G<regex>

尋找補(bǔ)丁文本包含與<regex>匹配的添加/刪除行的差異。

為了說明之間的區(qū)別-S<regex> --pickaxe-regex和-G<regex>，考慮在同一個文件中的以下DIFF提交：

+    return !regexec(regexp, two->ptr, 1, &regmatch, 0);...-    hit = !regexec(regexp, mf2.ptr, 1, &regmatch, 0);

雖然git log -G"regexec\(regexp"會顯示此提交，但git log -S"regexec\(regexp" --pickaxe-regex不會（因為該字符串的出現(xiàn)次數(shù)沒有改變）。

有關(guān)pickaxe更多信息，請參閱 gitdiffcore [7]中的條目。

--pickaxe-all

當(dāng)-S或-G發(fā)現(xiàn)更改時，顯示該更改集中的所有更改，而不僅僅是包含<string>中的更改的文件。

--pickaxe-regex

將給定的<string> -S視為擴(kuò)展的POSIX正則表達(dá)式進(jìn)行匹配。

-O<orderfile>

控制文件在輸出中出現(xiàn)的順序。這覆蓋了diff.orderFile配置變量（請參閱git-config [1]）。取消diff.orderFile，使用-O/dev/null。

輸出順序由<orderfile>中的全局模式順序決定。所有具有與第一個模式相匹配的路徑名的文件將首先輸出，接下來將輸出所有具有匹配第二個模式（但不是第一個）的路徑名的文件，依此類推。最后輸出所有不匹配任何模式的路徑名的文件，就好像文件末尾有一個隱含的匹配模式一樣。如果多個路徑名具有相同的排名（它們匹配相同的模式但沒有更早的模式），則它們的輸出順序相對于彼此是正常順序。

按以下方式解析<orderfile>：

• 空白行被忽略，所以它們可以用作分隔符以提高可讀性。

• 以散列（“ #”）開頭的行會被忽略，因此它們可以用于注釋。如果以散列開頭，則在模式的開頭添加反斜杠（“ \”）。

• 每隔一行包含一個模式。

模式與沒有 FNM_PATHNAME 標(biāo)志的 fnmantch（3）使用的模式具有相同的語法和語義，但如果刪除任何數(shù)量的最終路徑名組件都與模式匹配，則路徑名也與模式匹配。例如，模式“ foo*bar”匹配“ fooasdfbar”和“ foo/bar/baz/asdf”但不是“ foobarx”。

-R

交換兩個輸入； 即顯示索引或磁盤文件與樹內(nèi)容的差異。

--relative=<path>

當(dāng)從項目的子目錄運行時，可以通過該選項告知排除目錄外的更改并顯示與其相關(guān)的路徑名。如果不在子目錄中（例如，在裸存儲庫中），可以通過給出<path>作為參數(shù)來命名將哪個子目錄作為輸出的相對位置。

-a   --text

將所有文件視為文本。

--ignore-space-at-eol

忽略 EOL 中的空白變化。

-b   --ignore-space-change

忽略空白量的變化。這會忽略行結(jié)束處的空白，并認(rèn)為一個或多個空白字符的所有其他序列是等價的。

-w   --ignore-all-space

比較行時忽略空格。即使一行有空白，而另一行沒有空白，這也會忽略差異。

--ignore-blank-lines

忽略其行全部空白的更改。

--inter-hunk-context=<lines>

顯示差異 hunk 之間的上下文，直到指定的行數(shù)，從而融合彼此接近的hunk。如果配置選項未設(shè)置，則默認(rèn)為diff.interHunkContext或0。

-W   --function-context

顯示整個周圍的變化功能。

--ext-diff

允許執(zhí)行一個外部比較助手。如果你用 gitattributes [5]設(shè)置外部差異驅(qū)動程序，你需要在 git-log [1]和朋友中使用這個選項。

--no-ext-diff

禁止外部差異驅(qū)動程序。

--textconv   --no-textconv

在比較二進(jìn)制文件時，允許（或不允許）運行外部文本轉(zhuǎn)換過濾器。有關(guān)詳細(xì)信息，請參閱 gitattributes [5]。由于 textconv 過濾器通常是單向轉(zhuǎn)換，因此生成的差異適合人類消費，但無法應(yīng)用。出于這個原因，默認(rèn)情況下，textconv 過濾器僅針對 git-diff [1]和 git-log [1]啟用，但不適用于 git-format-patch [1]或 diff plumbing命令。

--ignore-submodules=<when>

忽略差異代中子模塊的更改。<when>可以是“none”，“untracked”，“dirty”或“all”，這是默認(rèn)設(shè)置。如果子模塊包含未跟蹤或已修改的文件，或者 HEAD 與超級項目中記錄的提交不同，并且可用于覆蓋 git-config [1]或 gitmodules [5]中的任何ignore選項設(shè)置，則使用“none” ]。當(dāng)使用“未跟蹤”時，如果子模塊僅包含未跟蹤內(nèi)容（但仍然針對修改內(nèi)容進(jìn)行掃描），則子模塊不會被認(rèn)為是臟的。使用“dirty”會忽略對子模塊工作樹的所有更改，只會顯示超級項目中存儲的提交更改（這是1.7.0之前的行為）。使用“全部”

--src-prefix=<prefix>

顯示給定的源前綴而不是“a /”。

--dst-prefix=<prefix>

顯示給定的目的地前綴而不是“b /”。

--no-prefix

不要顯示任何來源或目的地前綴。

--line-prefix=<prefix>

為每行輸出添加一個額外的前綴。

--ita-invisible-in-index

默認(rèn)情況下，由“git add -N”添加的條目顯示為“git diff”中的現(xiàn)有空文件和“git diff --cached”中的新文件。這個選項使條目在“git diff”中顯示為新文件，在“git diff --cached”中不存在。這個選項可以恢復(fù)--ita-visible-in-index。這兩個選項都是實驗性的，可以在將來刪除。

有關(guān)這些常用選項的更詳細(xì)的解釋，請參閱 gitdiffcore [7]。

用-p生成補(bǔ)丁

當(dāng)使用選項運行“git-diff-index”，“git-diff-tree”或“git-diff-files”時，不帶-p選項運行“git diff” --raw，使用“-p”運行“git log”選項，它們不會產(chǎn)生上述輸出; 相反，他們生成一個補(bǔ)丁文件。您可以通過GIT_EXTERNAL_DIFF和GIT_DIFF_OPTS環(huán)境變量自定義這些修補(bǔ)程序的創(chuàng)建。

-p選項產(chǎn)生的東西與傳統(tǒng)的diff格式略有不同：

1. 它前面有一個“git diff”頭文件，它看起來像這樣：diff --git a / file1 b / file2

在a/和b/文件名是，除非重命名/副本所涉及的相同。尤其是，即使是創(chuàng)建或刪除，/dev/null也可not用于替換文件名a/或b/文件名。

當(dāng)重命名/復(fù)制參與，file1和file2示出了重命名/復(fù)制的源文件的名稱和重命名/復(fù)制分別產(chǎn)生，該文件的名稱。

1. 它后跟一個或多個擴(kuò)展標(biāo)題行：舊模式<mode>新模式<mode>已刪除文件模式<mode>新文件模式<mode>從<path>復(fù)制到<path>從<path>重命名重命名為<path>相似索引<number>不相似索引<number>索引<hash> .. <hash> <mode>

文件模式打印為6位八進(jìn)制數(shù)字，包括文件類型和文件權(quán)限位。

擴(kuò)展標(biāo)題中的路徑名稱不包含a/和b/前綴。

相似性指數(shù)是未改變的行的百分比，不相似性指數(shù)是改變的行的百分比。它是一個向下舍入的整數(shù)，后面跟著一個百分號。100％的相似性指數(shù)值因此被保留給兩個相同的文件，而100％相異性意味著來自舊文件的行不會將其轉(zhuǎn)換為新的文件。

索引行包含更改前后的 SHA-1校驗和。如果文件模式?jīng)]有改變，則包含<mode>; 否則，單獨的行表示舊模式和新模式。

1. 帶有“不常用”字符的路徑名將按照配置變量的說明引用core.quotePath（請參閱 git-config [1]）。

2. file1輸出中的所有文件在提交之前引用文件，所有file2文件在提交之后引用文件。將每個更改順序應(yīng)用于每個文件是不正確的。例如，這個補(bǔ)丁會將 a 和 b：diff --git a / ab / b重命名為重命名為 b diff --git a / bb / a將重命名從 b 重命名為 a

結(jié)合 diff 格式

任何 diff-generating 命令都可以使用-c或--cc選項combined diff在顯示合并時生成一個。這是顯示與 git-diff [1]或 git-show [1]合并時的默認(rèn)格式。還要注意，您可以-m選擇這些命令中的任何一個來強(qiáng)制生成合并的單個父代的差異。

一個combined diff格式如下：

diff --combined describe.c
index fabadb8,cc95eb0..4866510--- a/describe.c+++ b/describe.c
@@@ -98,20 -98,12 +98,20 @@@        return (a_date > b_date) ? -1 : (a_date == b_date) ? 0 : 1;  }- static void describe(char *arg) -static void describe(struct commit *cmit, int last_one)++static void describe(char *arg, int last_one)  { +        unsigned char sha1[20]; +        struct commit *cmit;
        struct commit_list *list;        static int initialized = 0;
        struct commit_name *n; +        if (get_sha1(arg, sha1) < 0) +                usage(describe_usage); +        cmit = lookup_commit_reference(sha1); +        if (!cmit) +                usage(describe_usage); +        if (!initialized) {
                initialized = 1;                for_each_ref(get_name);

1. 它前面有一個“git diff”頭，看起來像這樣（當(dāng)使用-c選項時）：diff  - 組合文件

或者像這樣（當(dāng)使用--cc選項時）：

diff --cc file

1. 它后面跟著一個或多個擴(kuò)展標(biāo)題行（此示例顯示與兩個父級合并）：index <hash>，<hash> .. <hash> mode <mode>，<mode> .. <mode>新文件模式<mode>刪除文件模式<mode>，<mode>

mode <mode>,<mode>..<mode>行僅在至少有一個<mode>與其他行不同時出現(xiàn)。具有關(guān)于檢測到的內(nèi)容移動（重命名和復(fù)制檢測）的信息的擴(kuò)展標(biāo)頭被設(shè)計為與兩個<tree-ish>的差異一起工作，并且不被組合的差異格式使用。

1. 緊接著是兩行文件/文件頭--- a/file +++ b/file

類似于傳統(tǒng)unified差異格式的雙行標(biāo)題，/dev/null用于表示創(chuàng)建或刪除的文件。

1. 塊頭格式被修改以防止人們意外地將其提供給patch -p1。組合的差異格式是為了審查合并提交更改而創(chuàng)建的，并不適用于應(yīng)用。此更改與擴(kuò)展index標(biāo)頭中的更改類似：@@@ <from-file-range> <from-file-range> <to-file-range> @@@

組合 diff 格式的塊頭中有（雙親數(shù)+ 1）個@字符。

與傳統(tǒng)的unified差異格式不同，該格式顯示兩個文件A和B，其中有一列-（減號 - 出現(xiàn)在 A 中但在 B 中刪除），+（加 - 在 A 中丟失，但添加到 B 中）或" "（空格 - 不變）前綴，這種格式將兩個或多個文件 file1，file2，...與一個文件X進(jìn)行比較，并顯示 X 與每個 fileN 的不同之處。每個 fileN 的一列都被預(yù)置在輸出行中，以指出X的行與其不同。

N列中的字-符表示該行出現(xiàn)在 fileN 中，但不出現(xiàn)在結(jié)果中。N列中的+字符表示該行出現(xiàn)在結(jié)果中，而 fileN 沒有該行（換句話說，從該父母的角度來看，該行被添加）。

在上面的輸出示例中，函數(shù)簽名已從兩個文件中更改（因此file1和file2中的兩個-刪除，以及++意味著已添加的一行不會出現(xiàn)在 file1或 file2中）。還有八個其他行與 file1相同，但不會出現(xiàn)在 file2中（因此前綴為+）。

在顯示時git diff-tree -c，它將合并提交的父項與合并結(jié)果進(jìn)行比較（即 file1..fileN為父項）。如圖所示git diff-files -c，它將兩個未解決的合并父項與正在運行的樹文件進(jìn)行比較（即 file1為階段2 aka“我們的版本”，file2為階段3 aka“他們的版本”）。

示例

git log --no-merges

顯示整個提交歷史記錄，但跳過任何合并

git log v2.6.12.. include/scsi drivers/scsi

顯示自版本以來v2.6.12更改include/scsi或drivers/scsi子目錄中的任何文件的所有提交

git log --since="2 weeks ago" -- gitk

在過去的兩周內(nèi)向文件顯示更改gitk?！?- ”是避免與名稱分支混淆的必要條件gitk

git log --name-status release..test

顯示“test”分支中但尚未位于“release”分支中的提交以及每個提交修改的路徑列表。

git log --follow builtin/rev-list.c

顯示更改的提交builtin/rev-list.c，包括文件被賦予其當(dāng)前名稱之前發(fā)生的提交。

git log --branches --not --remotes=origin

顯示任何本地分支中的所有提交，但不包含任何遠(yuǎn)程跟蹤分支中的提交origin（您擁有該來源的分支）。

git log master --not --remotes=*/master

顯示本地主服務(wù)器中的所有提交，但不顯示任何遠(yuǎn)程資源庫主分支中的提交。

git log -p -m --first-parent

顯示歷史記錄，包括變化差異，但僅從“主分支”角度看，跳過來自合并分支的提交，并顯示由合并引入的變化的完全差異。這只有在遵循嚴(yán)格的合并所有主題分支的策略時才有意義。

git log -L '/int main/',/^}/:main.c

顯示main()文件中的main.c功能隨著時間的推移如何演變。

git log -3

限制顯示的提交數(shù)量為3。

討論

Git 在某種程度上是字符編碼不可知的。

• blob 對象的內(nèi)容是未解釋的字節(jié)序列。在核心層面沒有編碼翻譯。

• 路徑名以 UTF-8標(biāo)準(zhǔn)化形式 C 編碼。這適用于樹對象，索引文件，ref 名稱，以及命令行參數(shù)，環(huán)境變量和配置文件中的路徑名.git/config（請參閱 git-config [1]） ，gitignore [5]，gitattributes [5]和 gitmodules [5]）。請注意，核心級 Git 將路徑名視為非 NUL 字節(jié)序列，不存在路徑名編碼轉(zhuǎn)換（Mac 和 Windows除外）。因此，即使在使用傳統(tǒng)擴(kuò)展 ASCII編碼的平臺和文件系統(tǒng)上，使用非 ASCII路徑名也可以工作。但是，在這樣的系統(tǒng)上創(chuàng)建的存儲庫在基于 UTF-8的系統(tǒng)（例如 Linux，Mac，Windows）上無法正常工作，反之亦然。此外，許多基于 Git 的工具只是假設(shè)路徑名稱為 UTF-8，并且無法正確顯示其他編碼。

• 提交日志消息通常以 UTF-8編碼，但也支持其他擴(kuò)展 ASCII編碼。這包括 ISO-8859-x，CP125x和許多其他版本，但notUTF-16/32，EBCDIC 和 CJK 多字節(jié)編碼（GBK，Shift-JIS，Big5，EUC-x，CP9xx等）。

雖然我們鼓勵提交日志消息使用 UTF-8編碼，但核心和 Git 瓷器（Porcelain）都設(shè)計為不強(qiáng)制項目使用 UTF-8。如果特定項目的所有參與者發(fā)現(xiàn)使用遺留編碼更方便，Git 不會禁止它。但是，有幾件事要牢記。

1. git commit和git commit-tree如果提交給它的提交日志消息看起來不像一個有效的 UTF-8字符串，則會發(fā)出警告，除非您明確聲明您的項目使用了舊版編碼。說這個的方法是在.git/config文件中有 i18n.commitencoding ，像這樣：i18n commitEncoding = ISO-8859-1

使用上述設(shè)置創(chuàng)建的提交對象記錄i18n.commitEncoding其encoding標(biāo)題中的值。這是為了幫助稍后看到他們的其他人。缺少這個頭部意味著提交日志消息以UTF-8編碼。

2. git log，git show，git blame和看起來像encoding一個提交對象的報頭，并且嘗試除非另有規(guī)定重新代碼日志消息轉(zhuǎn)換成 UTF-8。您可以i18n.logOutputEncoding在.git/config文件中指定所需的輸出編碼，如下所示：i18n logOutputEncoding = ISO-8859-1

如果您沒有此配置變量，i18n.commitEncoding則會使用該值。

請注意，在提交對象級別強(qiáng)制使用 UTF-8時，我們故意選擇不重新編寫提交日志消息，因為重新編碼為 UTF-8不一定是可逆操作。

組態(tài)

關(guān)于核心變量，請參閱 git-config [1]，關(guān)于 diff 生成的設(shè)置，請參閱 git-diff [1]。

format.pretty

--format選項的默認(rèn)值。（請參閱上文Pretty Formats。）默認(rèn)為medium。

i18n.logOutputEncoding

顯示日志時使用編碼。（請參閱Discussion上文。）如果設(shè)置默認(rèn)的值為i18n.commitEncoding，否則為 UTF-8。

log.date

人可讀日期的默認(rèn)格式。（比較--date選項。）默認(rèn)為“默認(rèn)”，這意味著要寫日期Sat May 8 19:35:34 2010 -0500。

log.follow

如果true，git log將作為如果--follow選項當(dāng)單個<path>在給定的使用。這與--follow具有相同的限制，即它不能用于跟蹤多個文件，并且在非線性歷史記錄上不能很好地工作。

log.showRoot

如果false，git log和相關(guān)的命令將不會把最初的承諾作為一個大的創(chuàng)建事件。在git log -p輸出中的任何根提交將顯示沒有附加差異。默認(rèn)是true。

log.showSignature

如果true，git log和相關(guān)命令將充當(dāng)如果--show-signature選項被傳遞給他們。

mailmap.*

參見 git-shortlog [1]。

notes.displayRef

除了由core.notesRef或者GIT_NOTES_REF設(shè)置的缺省值之外，還引用了在用log命令系列顯示提交消息時的注釋。參見 git-notes [1]。

可能是一個未縮寫的參考名稱或 glob，可能會多次指定。對于不存在的 ref，將發(fā)出警告，但不匹配任何 ref 的 glob 默默無視。

該設(shè)置可以通過該--no-notes選項禁用，由GIT_NOTES_DISPLAY_REF環(huán)境變量覆蓋并由--notes=<ref>選項覆蓋。