What does git name-rev do?

Asked 5/10, 2018 at 13:39 Answered 1/8 at 12:18

Finds symbolic names suitable for human digestion for revisions given in any format parsable by git rev-parse.

But I could not understand this. What is the use of this command ? How is it different from git describe command ? I think that both also does the same thing - give a SHA1 Id , gives us back the nearest reference name to it ?

Jobi answered 5/10, 2018 at 13:39 Comment(0)

Marek R's answer is correct, but a bit incomplete.

Essentially, git name-rev comes up with a name plus some relative expression, if needed, to move from the name to the commit, while git describe comes up with some name—usually a tag name, but potentially some other name—plus some additional string if needed, that's not particularly "relative": there is a count in some cases, but it's not as useful as the count(s) in git name-rev. If git describe was not able to use a raw name, it adds g and an abbreviated hash ID:

$ git describe
v2.19.1-272-gf84b9b09d4

but:

$ git name-rev HEAD
HEAD master

If we add --all to git describe's arguments, git describe does use the branch name, but the output differs:

$ git describe --all
heads/master

In particular it was careful to note that it was using a branch name, since if there is a collision between branch and tag names—if there is a refs/tags/master as well—parsing master alone would produce the hash ID associated with the tag, rather than the branch-name.

Besides these, git describe can add -dirty if the work-tree does not match the commit, and—since Git 2.16.0—can produce a name:pathname string to give you an expression that names a particular stored blob:

$ git describe HEAD:Makefile
v2.19.0-237-ge3d4ff037d:Makefile

which is not something git name-rev can manage.

The purposes are different

What is the use of [git name-rev]?

I have never actually seen anyone use it myself, but see below. Let's start with the purpose of git describe: git describe is used very commonly to produce useful descriptions of a particular build. Because it defaults to using only tags, its output is relatively stable (well, it is if we assume that tags never change). When git describe says v2.19.1-272-gf84b9b09d4, we know:

the commit comes some time after v2.19.1
the actual commit's hash ID starts with f84b9b09d4

and future git describe outputs for this same commit are likely to be identical (though they could change if we add a new annotated tag). The count of 272 commits reachable via v2.19.1..f84b9b09d4:

$ git rev-list --count v2.19.1..f84b9b09d4
272

will not change. Running git rev-parse v2.19.1-272-gf84b9b09d4 will always produce f84b9b09d40408cf91bbc500d9f190a7866c3e0f, whether I do it again tomorrow or next week or next year, as long as tag v2.19.1 remains where it is. If we use this string as a build identifier, and we avoid using branch names and are careful to note if the build is "dirty", we can immediately tell whether we can easily reproduce this same build again later, and if so, how (i.e., by running git checkout v2.19.1-272-gf84b9b09d4).

On the other hand, when git name-rev says master or master~3 or whatever, there's no guarantee that I can go back to that repository tomorrow and use that same expression to find the same commit. Next year, it's almost guaranteed to be wrong. So git name-rev output is only good for a little while—essentially, until you move some of the branch names.

Meanwhile, git name-rev has a trick that git describe does not: it can parse its input (--annotate-stdin), looking for things that appear to be hash IDs. When it finds them, it will copy them to standard output and add (expression), provided the hash translates to a name:

$ X=$(git rev-parse master)
$ echo embedded $X hash | git name-rev --annotate-stdin
embedded f84b9b09d40408cf91bbc500d9f190a7866c3e0f (master) hash
$ Y=$(echo $X | sed s/f/0/)
$ echo embedded invalid $Y hash | git name-rev --annotate-stdin
embedded invalid 084b9b09d40408cf91bbc500d9f190a7866c3e0f hash

This means that you can, as shown in the documentation, run git log | git name-rev --annotate-stdin and have all of those commit hashes become decorated hashes. However, the hashes do have to be full hashes. Compare:

$ git log --oneline -n 10 | git name-rev --annotate-stdin
f84b9b09d4 Sync with 2.19.1
cae598d998 Git 2.19.1
1958ad504b Sync with 2.18.1
268fbcd172 Git 2.18.1
44f87dac99 Sync with 2.17.2
6e9e91e9ca Git 2.17.2
1a7fd1fb29 fsck: detect submodule paths starting with dash
a124133e1e fsck: detect submodule urls starting with dash
e43aab778c Sync with 2.16.5
27d05d1a1a Git 2.16.5

with:

$ git log --pretty=tformat:'%H %s' -n 10 | git name-rev --annotate-stdin
f84b9b09d40408cf91bbc500d9f190a7866c3e0f (master) Sync with 2.19.1
cae598d9980661a978e2df4fb338518f7bf09572 (tags/v2.19.1^0) Git 2.19.1
1958ad504befa6a09c475cc8ab9de43b359de137 (tags/v2.19.1~1) Sync with 2.18.1
268fbcd172cdb306e8a3e7143cc16677c963d6cd (tags/v2.18.1^0) Git 2.18.1
44f87dac99574a8073ffb1ba8b10bd4d3945f61b (tags/v2.18.1~1) Sync with 2.17.2
6e9e91e9cae74cd7feb9300563d40361b2b17dd2 (tags/v2.17.2^0) Git 2.17.2
1a7fd1fb2998002da6e9ff2ee46e1bdd25ee8404 (tags/v2.17.2~1) fsck: detect submodule paths starting with dash
a124133e1e6ab5c7a9fef6d0e6bcb084e3455b46 (tags/v2.17.2~2) fsck: detect submodule urls starting with dash
e43aab778c72250e11eb00e31dc6be90072a1637 (tags/v2.17.2~3) Sync with 2.16.5
27d05d1a1a62273aa3749f4d0ab8a126ef11ff66 (tags/v2.16.5^0) Git 2.16.5

Bottom line: use whichever suits your particular purpose best. Which one that is depends on what your purpose is.

Vacant answered 9/10, 2018 at 16:10 Comment(0)

With Git 2.25 (Q1 2020), you can see an illustration of what "git name-rev" does.

See commit 2866fd2, commit 49f7a2f, commit fee984b (09 Dec 2019), and commit 8c5724c, commit 3a52150, commit dd432a6, commit dd090a8, commit 766f9e3, commit d59fc83, commit bf43abc, commit e0c4da6, commit c593a26, commit d91ce88 (12 Nov 2019) by SZEDER Gábor (szeder).
See commit c3794d4 (12 Nov 2019) by René Scharfe (``).
^{(Merged by Junio C Hamano -- gitster -- in commit f3c520e, 25 Dec 2019)}

t6120: add a test to cover inner conditions in 'git name-rev's name_rev()

^{Signed-off-by: SZEDER Gábor}

In 'builtin/name-rev.c' in the name_rev() function there is a loop iterating over all parents of the given commit, and the loop body looks like this:
if (parent_number > 1) {
    if (generation > 0)
        // branch #1
        new_name = ...
    else
        // branch #2
        new_name = ...
    name_rev(parent, new_name, ...);
} else {
    // branch #3
    name_rev(...);
}
These conditions are not covered properly in the test suite.

As far as purely test coverage goes, they are all executed several times over in 't6120-describe.sh'.

However, they don't directly influence the command's output, because the repository used in that test script contains several branches and tags pointing somewhere into the middle of the commit DAG, and thus result in a better name for the to-be-named commit.

This can hide bugs: e.g. by replacing the 'new_name' parameter of the first recursive name_rev() call with 'tip_name' (effectively making both branch #1 and #2 a noop) 'git name-rev --all' shows thousands of bogus names in the Git repository, but the whole test suite still passes successfully.

In an early version of a later patch in this series I managed to mess up all three branches (at once!), but the test suite still passed.

So add a new test case that operates on the following history:
A--------------master
 \            /
  \----------M2
   \        /
    \---M1-C
     \ /
      B
and names the commit 'B' to make sure that all three branches are crucial to determine 'B's name:

There is only a single ref, so all names are based on 'master', without any undesired interference from other refs.

Each time name_rev() follows the second parent of a merge commit, it appends "^2" to the name. Following 'master's second parent right at the start ensures that all commits on the ancestry path from 'master' to 'B' have a different base name from the original 'tip_name' of the very first name_rev() invocation.
Currently, while name_rev() is recursive, it doesn't matter, but it will be necessary to properly cover all three branches after the recursion is eliminated later in this series.

Following 'M2's second parent makes sure that branch #2 (i.e. when 'generation = 0') affects 'B's name.

Following the only parent of the non-merge commit 'C' ensures that branch #3 affects 'B's name, and that it increments 'generation'.

Coming from 'C' 'generation' is 1, thus following 'M1's second parent makes sure that branch #1 affects 'B's name.

With Git 2.25 (Q1 2020), the goal for "git name-rev" is to avoid recursive calls.

name-rev: eliminate recursion in name_rev()

^{Signed-off-by: SZEDER Gábor}

The name_rev() function calls itself recursively for each interesting parent of the commit it got as parameter, and, consequently, it can segfault when processing a deep history if it exhausts the available stack space.

E.g. running 'git name-rev --all' and 'git name-rev HEAD~100000' in the gcc, gecko-dev, llvm, and WebKit repositories results in segfaults on my machine ('ulimit -s' reports 8192kB of stack size limit), and nowadays the former segfaults in the Linux repo as well (it reached the necessary depth sometime between v5.3-rc4 and -rc5).

Eliminate the recursion by inserting the interesting parents into a LIFO 'prio_queue' 1 and iterating until the queue becomes empty.

Note that the parent commits must be added in reverse order to the LIFO 'prio_queue', so their relative order is preserved during processing, i.e. the first parent should come out first from the queue, because otherwise performance greatly suffers on mergy histories 2.

The stacksize-limited test 'name-rev works in a deep repo' in 't6120-describe.sh' demonstrated this issue and expected failure.

Now the recursion is gone, so flip it to expect success.

Also gone are the dmesg entries logging the segfault of that segfaulting 'git name-rev' process on every execution of the test suite.

Note that this slightly changes the order of lines in the output of 'git name-rev --all', usually swapping two lines every 35 lines in git.git or every 150 lines in linux.git.

This shouldn't matter in practice, because the output has always been unordered anyway.

This patch is best viewed with '--ignore-all-space'.

Early versions of this patch used a 'commit_list', resulting in ~15% performance penalty for 'git name-rev --all' in 'linux.git', presumably because of the memory allocation and release for each insertion and removal.
Using a LIFO 'prio_queue' has basically no effect on performance.

We prefer shorter names, i.e. 'v0.1~234' is preferred over 'v0.1^2~5', meaning that usually following the first parent of a merge results in the best name for its ancestors.
So when later we follow the remaining parent(s) of a merge, and reach an already named commit, then we usually find that we can't give that commit a better name, and thus we don't have to visit any of its ancestors again.

OTOH, if we were to follow the Nth parent of the merge first, then the name of all its ancestors would include a corresponding '^N'.
Those are not the best names for those commits, so when later we reach an already named commit following the first parent of that merge, then we would have to update the name of that commit and the names of all of its ancestors as well.
Consequently, we would have to visit many commits several times, resulting in a significant slowdown.

With Git 2.26 (Q1 2020), the memory footprint and performance of "git name-rev" has been improved.
That provides an additional insight of what git name-rev does.

See commit 079f970 (05 Feb 2020), and commit 2d53975, commit 977dc19, commit 1c56fc2, commit ddc42ec, commit f13ca7c, commit d689d6d, commit 15a4205, commit 36d2419, commit 71620ca (04 Feb 2020) by René Scharfe (rscharfe).
See commit 3e2feb0 (05 Feb 2020) by Martin Ågren (``).
^{(Merged by Junio C Hamano -- gitster -- in commit 0460c10, 17 Feb 2020)}

name-rev: sort tip names before applying

^{Signed-off-by: René Scharfe}

name_ref() is called for each ref and checks if its a better name for the referenced commit.

If that's the case it remembers it and checks if a name based on it is better for its ancestors as well.

This in done in the the order for_each_ref() imposes on us.

That might not be optimal.

If bad names happen to be encountered first (as defined by is_better_name()), names derived from them may spread to a lot of commits, only to be replaced by better names later.

Setting better names first can avoid that.

is_better_name() prefers tags, short distances and old references.

The distance is a measure that we need to calculate for each candidate commit, but the other two properties are not dependent on the relationships of commits.

Sorting the refs by them should yield better performance than the essentially random order we currently use.

And applying older references first should also help to reduce rework due to the fact that older commits have less ancestors than newer ones.

So add all details of names to the tip table first, then sort them to prefer tags and older references and then apply them in this order. Here's the performance as measures by hyperfine for the Linux repo before:
Benchmark #1: ./git -C ../linux/ [`git name-rev --all`](https://git-scm.com/docs/git-name-rev#Documentation/git-name-rev.txt---all)
Time (mean ± σ):     851.1 ms ±   4.5 ms    [User: 806.7 ms, System: 44.4 ms]
Range (min … max):   845.9 ms … 859.5 ms    10 runs
... and with this patch:
Benchmark #1: ./git -C ../linux/ [`git name-rev --all`](https://git-scm.com/docs/git-name-rev#Documentation/git-name-rev.txt---all)
Time (mean ± σ):     736.2 ms ±   8.7 ms    [User: 688.4 ms, System: 47.5 ms]
Range (min … max):   726.0 ms … 755.2 ms    10 runs

With Git 2.35 (Q1 2022), "git name-rev"^(man) has been tweaked to give output that is shorter and easier to understand.

See commit 3656f84 (04 Dec 2021) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 3f9d505, 21 Dec 2021)}

name-rev: prefer shorter names over following merges

^{Signed-off-by: Elijah Newren}
^{Acked-by: Ævar Arnfjörð Bjarmason}
^{Acked-by: Johannes Schindelin}

name-rev has a MERGE_TRAVERSAL_WEIGHT to say that traversing a second or later parent of a merge should be 65535 times more expensive than a first-parent traversal, as per ac076c2 ("name-rev: Fix non-shortest description", 2007-08-27, Git v1.5.3-rc7 -- merge).
The point of this weight is to prefer names like
v2.32.0~1471^2
over names like
v2.32.0~43^2~15^2~11^2~20^2~31^2
which are two equally valid names in git.git for the same commit.
Note that the first follows 1472 parent traversals compared to a mere 125 for the second.
Weighting all traversals equally would clearly prefer the second name since it has fewer parent traversals, but humans aren't going to be traversing commits and they tend to have an easier time digesting names with fewer segments.
The fact that the former only has two segments (~1471, ^2) makes it much simpler than the latter which has six segments (~43, ^2, ~15, etc.).

Since name-rev is meant to "find symbolic names suitable for human digestion", we prefer fewer segments.

However, the particular rule implemented in name-rev would actually prefer
v2.33.0-rc0~11^2~1
over
v2.33.0-rc0~20^2
because both have precisely one second parent traversal, and it gives the tie breaker to shortest number of total parent traversals.
Fewer segments is more important for human consumption than number of hops, so we'd rather see the latter which has one fewer segment.

Include the generation in is_better_name() and use a new effective_distance() calculation so that we prefer fewer segments in the printed name over fewer total parent traversals performed to get the answer.

Warning: with Git 2.40 (Q1 2023), "git name-rev"^(man) has an heuristics update.

See commit b2182a8 (09 Feb 2023) by Elijah Newren (newren).
^{(Merged by Junio C Hamano -- gitster -- in commit 5fc6d00, 22 Feb 2023)}

name-rev: fix names by dropping taggerdate workaround

^{Signed-off-by: Elijah Newren}

Commit 7550424 ("name-rev: include taggerdate in considering the best name", 2016-04-22, Git v2.9.0-rc0 -- merge listed in batch #9) introduced the idea of using taggerdate in the criteria for selecting the best name.
At the time, a certain commit in linux.git -- namely, aed06b9cfcab -- was being named by name-rev as
v4.6-rc1~9^2~792
which, while correct, was very suboptimal.

Some investigation found that tweaking the MERGE_TRAVERSAL_WEIGHT to lower it could give alternate answers such as
v3.13-rc7~9^2~14^2~42
or
v3.13~5^2~4^2~2^2~1^2~42
A manual solution involving looking at tagger dates came up with
v3.13-rc1~65^2^2~42
which is much nicer.
That workaround was then implemented in name-rev.

Unfortunately, the taggerdate heuristic is causing bugs.

I was pointed to a case in a private repository where name-rev reports a name of the form
v2022.10.02~86
when users expected to see one of the form
v2022.10.01~2
(I've modified the names and numbers a bit from the real testcase.)

As you can probably guess, v2022.10.01 was created after v2022.10.02 (by a few hours), even though it pointed to an older commit.

While the condition is unusual even in the repository in question, it is not the only problematic set of tags in that repository.

The taggerdate logic is causing problems.

Further, it turns out that this taggerdate heuristic isn't even helping anymore.
Due to the fix to naming logic in 3656f84 ("name-rev: prefer shorter names over following merges", 2021-12-04, Git v2.35.0-rc0 -- merge listed in batch #4), we get improved names without the taggerdate heuristic.

For the original commit of interest in linux.git, a modern Git without the taggerdate heuristic still provides the same optimal answer of interest, namely:
v3.13-rc1~65^2^2~42
So, the taggerdate is no longer providing benefit, and it is causing problems.
Simply get rid of it.

However, note that "taggerdate" as a variable is used to store things besides a taggerdate these days.
Ever since commit ef1e740 ("name-rev: favor describing with tags and use committer date to tiebreak", 2017-03-29, Git v2.14.0-rc0 -- merge listed in batch #4), this has been used to store committer dates and there it is used as a fallback tiebreaker (as opposed to a primary criteria overriding effective distance calculations).
We do not want to remove that fallback tiebreaker, so not all instances of "taggerdate" are removed in this change.

With Git 2.45 (Q2 2024), batch 4, many small allocations "git name-rev"^(man) makes have been updated to allocate from a mem-pool.

See commit f39addd, commit 8d25663 (25 Feb 2024) by René Scharfe (rscharfe).
^{(Merged by Junio C Hamano -- gitster -- in commit b511164, 05 Mar 2024)}

name-rev: use mem_pool_strfmt()

^{Signed-off-by: René Scharfe}

1c56fc2 ("name-rev: pre-size buffer in get_parent_name()", 2020-02-04, Git v2.26.0-rc0 -- merge listed in batch #6) got a big performance boost in an unusual repository by calculating the name length in advance.
This is a bit awkward, as it references the name components twice.

Use a memory pool to store the strings for the struct rev_name member tip_name.
Using mem_pool_strfmt() allows efficient allocation without explicit size calculation.
This simplifies the formatting part of the code without giving up performance:
Benchmark 1: ./git_2.44.0 -C ../chromium/src name-rev `--all`
    Time (mean ± σ):      1.231 s ±  0.013 s    [User: 1.082 s, System: 0.136 s]
    Range (min … max):    1.214 s …  1.252 s    10 runs

Benchmark 2: ./[`git -C`](https://github.com/git/git/blob/f39addd0d9d75a073847ed4311079a499dd33f35/Documentation/git.txt#L61)<sup>([man](https://git-scm.com/docs/git#Documentation/git.txt--Cltpathgt))</sup> ../chromium/src name-rev `--all`
    Time (mean ± σ):      1.220 s ±  0.020 s    [User: 1.083 s, System: 0.130 s]
    Range (min … max):    1.197 s …  1.254 s    10 runs
Don't bother discarding the memory pool just before exiting.
The effort for that would be very low, but actually measurable in the above example, with no benefit to users.
At least UNLEAK it to calm down leak checkers.
This addresses the leaks that 45a14f5 (Revert "name-rev: release unused name strings", 2022-04-22, Git v2.37.0-rc0 -- merge) brought back.

Wyandotte answered 27/12, 2019 at 21:18 Comment(0)

Documentation is quite clear.

It finds/generates expression which will refer to given commit using only human readable symbols like branch names and tag names.

For example on my repository:

$ git name-rev 91faf1b82d2dcedf8098a6e571ef379b29a44f51
91faf1b82d2dcedf8098a6e571ef379b29a44f51 develop^2~2

I've provide commit which is not tagged or pointed directly by branch. As you can see command found that, this commit is contained by branch develop. To reach this commit from develop you have to use second parent and two commit back.

I recommend: just try to use this command on different commits and see the outcome.

Squatter answered 5/10, 2018 at 13:49 Comment(3)

Thnx for answer. I had understood this much. What I dnt understand is why would git have git describe and then git name-rev which both works similarly ? Please note that git describe is not limited to tags. – Jobi 5/10, 2018 at 13:56

git describe works on tags. It also finds nearest tag in the past without printing how deep it is. This command uses tags and branches, but also adds relation information. In my example you have ^2~2. I don't see many practical usages of this command. – Squatter 5/10, 2018 at 14:2

note also that git desribe output doesn't let you reproduce commit id back - outcome is not reversible. This command outcome is reversible, from human readable value identifies exactly same commit. – Squatter 5/10, 2018 at 14:6

You have another illustration of git name-rev with Git 2.36 (Q2 2022), in the examples section of this fix:

"git name-rev --stdin"^(man) does not behave like usual --stdin at all.
Start the process of renaming it to --annotate-stdin.

See commit a258571, commit 34ae3b7 (05 Jan 2022) by John Cai (john-cai).
^{(Merged by Junio C Hamano -- gitster -- in commit d9976b1, 09 Feb 2022)}

name-rev: deprecate --stdin in favor of --annotate-stdin

^{Signed-off-by: "John Cai"}

Introduce a --annotate-stdin that is functionally equivalent of --stdin.
--stdin does not behave as --stdin in other subcommands, such as pack-objects whereby it takes one argument per line.
Since --stdin can be a confusing and misleading name, rename it to --annotate-stdin.

This change adds a warning to --stdin warning that it will be removed in the future.

git name-rev now includes in its man page:

--annotate-stdin

git name-rev now includes in its man page:

altogether.

For example:

$ cat sample.txt

An abbreviated revision 2ae0a9cb82 will not be substituted.
The full name after substitution is 2ae0a9cb8298185a94e5998086f380a355dd8907,
while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad

$ git name-rev --annotate-stdin <sample.txt

An abbreviated revision 2ae0a9cb82 will not be substituted.
The full name after substitution is 2ae0a9cb8298185a94e5998086f380a355dd8907 (master),
while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad

$ git name-rev --name-only --annotate-stdin <sample.txt

An abbreviated revision 2ae0a9cb82 will not be substituted.
The full name after substitution is master,
while its tree object is 70d105cc79e63b81cfdcb08a15297c23e60b07ad

`--stdin`

This option is deprecated in favor of 'git name-rev --annotate-stdin'.
They are functionally equivalent.

Git 2.36 (Q2 2022) also adds finishing touches to the "name-rev --annotate-stdin".

See commit d271892 (15 Feb 2022) by John Cai (john-cai).
^{(Merged by Junio C Hamano -- gitster -- in commit 294f296, 25 Feb 2022)}

name-rev: replace --stdin with --annotate-stdin in synopsis

^{Signed-off-by: John Cai}

34ae3b7 ("name-rev: deprecate --stdin in favor of --annotate-stdin", 2022-01-05, Git v2.36.0 -- merge listed in batch #2) added --annotate-stdin to replace --stdin as a clearer flag name.

Since --stdin is to be deprecated, we should replace --stdin in the output from git name-rev -h"^(man)".

And still with Git 2.36 (Q2 2022), "git name-rev"^(man) learned to use the generation numbers when setting the lower bound of searching commits used to explain the revision, when available, instead of committer time.

See commit 2e8ea40 (11 Mar 2022) by Jacob Keller (jacob-keller).
^{(Merged by Junio C Hamano -- gitster -- in commit 94cb657, 23 Mar 2022)}

name-rev: use generation numbers if available

^{Signed-off-by: Jacob Keller}

If a commit in a sequence of linear history has a non-monotonically increasing commit timestamp, git name-rev^(man) might not properly name the commit.

This occurs because name-rev uses a heuristic of the commit date to avoid searching down tags which lead to commits that are older than the named commit.
This is intended to avoid work on larger repositories.

This heuristic impacts git name-rev, and by extension git describe --contains^(man) which is built on top of name-rev.

Further more, if --all or --annotate-stdin is used, the heuristic is not enabled because the full history has to be analyzed anyways.
This results in some confusion if a user sees that --annotate-stdin works but a normal name-rev does not.

If the repository has a commit graph, we can use the generation numbers instead of using the commit dates.
This is essentially the same check except that generation numbers make it exact, where the commit date heuristic could be incorrect due to clock errors.

Note: Git 2.41 (Q2 2023) now stops advertising it in thegit name-rev -h" output: the "--stdin" option of "git name-rev"^(man) has been replaced with the --annotate-stdin option more than a year ago. We

See commit 9019d7d (06 May 2023) by John Cai (john-cai).
^{(Merged by Junio C Hamano -- gitster -- in commit be2fd0e, 15 May 2023)}

name-rev: make --stdin hidden

^{Signed-off-by: "John Cai"}

In 34ae3b7 (name-rev: deprecate --stdin in favor of --annotate-stdin, 2022-01-05, Git v2.36.0-rc0 -- merge listed in batch #2) (name-rev: deprecate --stdin in favor of --annotate-stdin), we renamed --stdin to --annotate-stdin for the sake of a clearer name for the option, and added text that indicates --stdin is deprecated.
The next step is to hide --stdin completely.

Make the option hidden.
Also, update documentation to remove all mentions of --stdin.

git name-rev now includes in its man page:

( --all | --annotate-stdin | <commit-ish>... )

git name-rev now includes in its man page:

altogether. This option was called --stdin in older versions of Git.

git name-rev now includes in its man page:

% git log | git name-rev --annotate-stdin

Wyandotte answered 13/2, 2022 at 12:27 Comment(0)

you can also use it to obtain a nicer graph, that might indicate which commit belongs to which branch (attention, this is not watertight) for example

git log --graph --color=always --decorate --pretty | git name-rev --annotate-stdin | less -R

git log --graph --color=always --branches --decorate --pretty | git name-rev --annotate-stdin | less -R

Whensoever answered 1/8 at 12:18 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

The purposes are different

`t6120`: add a test to cover inner conditions in 'git name-rev's `name_rev()`

`name-rev`: eliminate recursion in `name_rev()`

`name-rev`: sort tip names before applying

`name-rev`: prefer shorter names over following merges

`name-rev`: fix names by dropping taggerdate workaround

`name-rev`: use `mem_pool_strfmt()`

`name-rev`: deprecate --stdin in favor of --annotate-stdin

`--annotate-stdin`

`--stdin`

`name-rev`: replace `--stdin` with `--annotate-stdin` in synopsis

`name-rev`: use generation numbers if available

`name-rev`: make --stdin hidden

Recommended topics

Hot tags

The purposes are different

t6120: add a test to cover inner conditions in 'git name-rev's name_rev()

name-rev: eliminate recursion in name_rev()

name-rev: sort tip names before applying

name-rev: prefer shorter names over following merges

name-rev: fix names by dropping taggerdate workaround

name-rev: use mem_pool_strfmt()

name-rev: deprecate --stdin in favor of --annotate-stdin

--annotate-stdin

--stdin

name-rev: replace --stdin with --annotate-stdin in synopsis

name-rev: use generation numbers if available

name-rev: make --stdin hidden

Recommended topics

Hot tags

`t6120`: add a test to cover inner conditions in 'git name-rev's `name_rev()`

`name-rev`: eliminate recursion in `name_rev()`

`name-rev`: sort tip names before applying

`name-rev`: prefer shorter names over following merges

`name-rev`: fix names by dropping taggerdate workaround

`name-rev`: use `mem_pool_strfmt()`

`name-rev`: deprecate --stdin in favor of --annotate-stdin

`--annotate-stdin`

`--stdin`

`name-rev`: replace `--stdin` with `--annotate-stdin` in synopsis

`name-rev`: use generation numbers if available

`name-rev`: make --stdin hidden