git log --graph with a sort of local revision number

git log --graph with a sort of local revision number

[Uwe Brauer]

Hi

I am an occasionally git user and am very used to local revision numbers
mercurial provides in its log command. I don't want to start the
discussion whether  local revision numbers are useful or not, nor
whether mercurial is better or not.

I only want to know whether there is any possibility to have this number
in the log.

I have seen 

https://stackoverflow.com/questions/4120001/what-is-the-git-equivalent-for-revision-number

That 
git rev-list --count HEAD

But I would like to have it in the 

 git log --graph --decorate

So something like this 

o  changeset:   5:d3ae13222c31
|  tag:         tip
|  user:        Uwe Brauer <oub@mat.ucm.es>
|  date:        Wed Aug 14 14:23:29 2019 +0200
|  summary:     Six
|
o  changeset:   4:64a3eee07e93
|  user:        Uwe Brauer <oub@mat.ucm.es>
|  date:        Wed Aug 14 14:23:28 2019 +0200
|  summary:     Fifth


Anybody know who to achieve it?

I presume 

 git checkout revnumber

Would not work?

I know that 

 git checkout HEAD~somenumber

Works

Uwe Brauer 

Re: git log --graph with a sort of local revision number

[Rafael Ascensão]

You can achieve something close (on small repos, more on that later) with:

$ git log --graph --color \
  --format='%C(auto)changeset: %h:%H%nuser:      %an%ndate:      %ad%nsummary:   %s%n' \
  | git name-rev --refs=$(git rev-parse --abbrev-ref HEAD) --name-only --stdin


    * changeset: 5fa0f52:master
    | user:      Junio C Hamano
    | date:      Fri Aug 16 10:28:23 2019 -0700
    | summary:   Git 2.23
    |
    *   changeset: 8e0fa0e:master~1
    |\  user:      Junio C Hamano
    | | date:      Fri Aug 16 10:22:51 2019 -0700
    | | summary:   Merge tag 'l10n-2.23.0-rnd2' of git://github.com/git-l10n/git-po
    | | 
    | * changeset: a6cd2cc:master~1^2
    | | user:      Jiang Xin
    | | date:      Tue Jul 30 10:02:22 2019 +0800
    | | summary:   l10n: zh_CN: for git v2.23.0 l10n round 1~2

And in this case, since we are using HEAD to describe the commits by
using --refs=$(git rev-parse --abbrev-ref HEAD), you can refer to
a6cd2cc either as master~1^2 or HEAD~1^2.

Now, git-name-rev has some memory/performance problems in repos with a
high number of references. Alban Gruin was working on this issue[1], but
I don't know what's the status of it.

[1]:https://github.com/agrn/git/tree/ag/fix-name-rev-leak

Re: git log --graph with a sort of local revision number

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 918 bytes --]

>>> "RA" == Rafael Ascensão <rafa.almas@gmail.com> writes:

   > You can achieve something close (on small repos, more on that later) with:
   > $ git log --graph --color \
   >   --format='%C(auto)changeset: %h:%H%nuser:      %an%ndate:      %ad%nsummary:   %s%n' \
   >   | git name-rev --refs=$(git rev-parse --abbrev-ref HEAD) --name-only --stdin

Hi thanks, this was precisely what I was looking for. However 

I run 

 git log --graph --color --format='%C(auto)changeset: %h:%H%nuser:      %an%ndate:      %ad%nsummary:   %s%n'   | git name-rev --refs=$(git rev-parse --abbrev-ref HEAD) --name-only --stdin

And it does not work

 git log --graph --color --format='%C(auto)changeset: %h:%H%nuser:      %an%ndate:      %ad%nsummary:   %s%n'   

Works but what comes after the pipe is not recognized
I obtain


Illegal variable name.


I am running 


git --version
git version 2.7.4

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

Re: git log --graph with a sort of local revision number

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 3482 bytes --]

>>> "RA" == Rafael Ascensão <rafa.almas@gmail.com> writes:

   > You can achieve something close (on small repos, more on that later) with:
   > $ git log --graph --color \
   >   --format='%C(auto)changeset: %h:%H%nuser:      %an%ndate:      %ad%nsummary:   %s%n' \
   >   | git name-rev --refs=$(git rev-parse --abbrev-ref HEAD) --name-only --stdin

Ok I see this is bash syntaxes.

In that case it works, but I see

* changeset: f40c01e:f40c01e41afbb87c7321147242354d46ddaee231
| user:      Uwe Brauer
| date:      Thu Aug 15 15:13:00 2019 +0200
| summary:   This is a test.
|
* changeset: 4dcf721:4dcf721042cd8f73d78876caf8f4796153c07023
| user:      Uwe Brauer
| date:      Wed Aug 14 14:33:29 2019 +0200
| summary:   Third
|
* changeset: 93083c8:93083c8b65141047c8346765fb663d5962076246
| user:      Uwe Brauer
| date:      Wed Aug 14 14:33:29 2019 +0200
| summary:   Second
|
* changeset: f59470f:f59470feb19d325accaad634025c229d6977df65
  user:      Uwe Brauer
  date:      Wed Aug 14 14:33:29 2019 +0200
  summary:   First commit

But on the GNU emacs repository which is reasonable old (has about 130
000 commits) and is around 700 MB, your command gives:


* changeset: ee1c638:master
| user:      Lars Ingebrigtsen
| date:      Sat Aug 17 17:30:42 2019 -0700
| summary:   Make `browse-url-of-buffer' work from zip files
|
* changeset: 3d1c9a7:master~1
| user:      Paul Eggert
| date:      Sat Aug 17 17:19:13 2019 -0700
| summary:   Fix org-timer-show-remaining-time > 1 hour
|
* changeset: f38a16e:master~2
| user:      Lars Ingebrigtsen
| date:      Sat Aug 17 16:56:13 2019 -0700
| summary:   Make `describe-function' say that disabled functions are disabled
|
* changeset: 3efe59a:master~3
| user:      Lars Ingebrigtsen
| date:      Sat Aug 17 16:47:16 2019 -0700
| summary:   Make newline-and-indent take a numeric prefix

Which is precisely what you said.


What did I do wrong in my test repo?

Which I generated via the following script


git init
echo "First" > test.org
git add test.org
git add create.sh
git commit -a -m "First commit"
echo "Second" >> test.org
git commit -a -m "Second"
echo "Third" >> test.org
git commit -a -m "Third"
echo "Forth" >> test.org
git commit  -a -m "Fourth"
echo "Fifth" >> test.org
git commit  -a -m "Fifth"
echo "Six" >> test.org
git commit  -a -m "Six"


   >     * changeset: 5fa0f52:master
   >     | user:      Junio C Hamano
   >     | date:      Fri Aug 16 10:28:23 2019 -0700
   >     | summary:   Git 2.23
   >     |
   >     *   changeset: 8e0fa0e:master~1
   >     |\  user:      Junio C Hamano
   >     | | date:      Fri Aug 16 10:22:51 2019 -0700
   >     | | summary:   Merge tag 'l10n-2.23.0-rnd2' of git://github.com/git-l10n/git-po
   >     | | 
   >     | * changeset: a6cd2cc:master~1^2
   >     | | user:      Jiang Xin
   >     | | date:      Tue Jul 30 10:02:22 2019 +0800
   >     | | summary:   l10n: zh_CN: for git v2.23.0 l10n round 1~2

   > And in this case, since we are using HEAD to describe the commits by
   > using --refs=$(git rev-parse --abbrev-ref HEAD), you can refer to
   > a6cd2cc either as master~1^2 or HEAD~1^2.

   > Now, git-name-rev has some memory/performance problems in repos with a
   > high number of references. Alban Gruin was working on this issue[1], but
   > I don't know what's the status of it.

   > [1]:https://github.com/agrn/git/tree/ag/fix-name-rev-leak

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

[SOLVED] (was: git log --graph with a sort of local revision number)

[Uwe Brauer]

>>> "UB" == Uwe Brauer <oub@mat.ucm.es> writes:

>>> "RA" == Rafael Ascensão <rafa.almas@gmail.com> writes:
   >> You can achieve something close (on small repos, more on that later) with:
   >> $ git log --graph --color \
   >> --format='%C(auto)changeset: %h:%H%nuser:      %an%ndate:      %ad%nsummary:   %s%n' \
   >> | git name-rev --refs=$(git rev-parse --abbrev-ref HEAD) --name-only --stdin

The script to generate a test repo is
git init
echo "First" > test.org
git add test.org
git add create.sh
git commit -a -m "First commit"
git checkout master   
echo "Second" >> test.org
git commit -a -m "Second"
echo "Third" >> test.org
git commit -a -m "Third"
echo "Forth" >> test.org
git commit  -a -m "Fourth"
echo "Fifth" >> test.org
git commit  -a -m "Fifth"
echo "Six" >> test.org
git commit  -a -m "Six"

Then your command even in a short shell script
#!/bin/bash
 git log --graph --color --format='%C(auto)changeset: %h:%H%nuser:      %an%ndate:      %ad%nsummary:   %s%n'   | git name-rev --refs=$(git rev-parse --abbrev-ref HEAD) --name-only --stdin | more


Works as you described.

Thanks

Uwe Brauer 

[problem with name-rev] (was: git log --graph with a sort of local revision number)

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

>>> "RA" == Rafael Ascensão <rafa.almas@gmail.com> writes:

   > You can achieve something close (on small repos, more on that later) with:
   > $ git log --graph --color \
   >   --format='%C(auto)changeset: %h:%H%nuser:      %an%ndate:      %ad%nsummary:   %s%n' \
   >   | git name-rev --refs=$(git rev-parse --abbrev-ref HEAD) --name-only --stdin


It seems that there is problem with name-rev.

Here's what I get when I start committing on master, then switch to a
branch foo and finally merge foo into master:

git init 
echo 1 > 1
git add 1
git commit -m 1
echo 1.1 > 1
git add .
git commit -m 1.1
git checkout -b foo master~1
echo 1.2 > 1
git add .
git commit -m 1.2
echo 1.2.1 > 1
git add .
git commit -m 1.2.1
git checkout master
git merge foo
echo 1.2.1/1.1 > 1
git add .
git commit -m "1.2.1/1.1"

Then 
 git log --graph --color --format='%C(auto)changeset: %h:%H%nuser:      %an%ndate:      %ad%nsummary:   %s%n'   | git name-rev --refs=$(git rev-parse --abbrev-ref HEAD) --name-only --stdin | more

Gives
*   changeset: ae68dbe:master
|\  user:      Uwe Brauer
| | date:      Tue Aug 20 16:25:53 2019 +0200
| | summary:   1.2.1/1.1
| |
| * changeset: c00bb5d:master^2
| | user:      Uwe Brauer
| | date:      Tue Aug 20 16:25:53 2019 +0200
| | summary:   1.2.1
| |
| * changeset: 54c9230:master^2~1
| | user:      Uwe Brauer
| | date:      Tue Aug 20 16:25:53 2019 +0200
| | summary:   1.2
| |
* | changeset: da0712f:master~1
|/  user:      Uwe Brauer
|   date:      Tue Aug 20 16:25:53 2019 +0200
|   summary:   1.1
|
* changeset: 8eb999d:master~2
  user:      Uwe Brauer
  date:      Tue Aug 20 16:25:53 2019 +0200
  summary:   1

That looks odd.

Any comments?

Uwe Brauer

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

Re: [problem with name-rev] (was: git log --graph with a sort of local revision number)

[SZEDER Gábor]

On Tue, Aug 20, 2019 at 04:32:12PM +0200, Uwe Brauer wrote:
> Here's what I get when I start committing on master, then switch to a
> branch foo and finally merge foo into master:

> *   changeset: ae68dbe:master
> |\  user:      Uwe Brauer
> | | date:      Tue Aug 20 16:25:53 2019 +0200
> | | summary:   1.2.1/1.1
> | |
> | * changeset: c00bb5d:master^2
> | | user:      Uwe Brauer
> | | date:      Tue Aug 20 16:25:53 2019 +0200
> | | summary:   1.2.1
> | |
> | * changeset: 54c9230:master^2~1
> | | user:      Uwe Brauer
> | | date:      Tue Aug 20 16:25:53 2019 +0200
> | | summary:   1.2
> | |
> * | changeset: da0712f:master~1
> |/  user:      Uwe Brauer
> |   date:      Tue Aug 20 16:25:53 2019 +0200
> |   summary:   1.1
> |
> * changeset: 8eb999d:master~2
>   user:      Uwe Brauer
>   date:      Tue Aug 20 16:25:53 2019 +0200
>   summary:   1
> 
> That looks odd.

What exactly do you think looks odd?  That "master^2~1", perhaps?
That's how commits on different branches are named, see 'man
gitrevisions', and 'git name-rev' works as designed.

Re: [problem with name-rev] (was: git log --graph with a sort of local revision number)

[Rafael Ascensão]

On Tue, Aug 20, 2019 at 04:32:12PM +0200, Uwe Brauer wrote:
> 
> It seems that there is problem with name-rev.
> 

In git, branches are just pointers to a commits. Commits do not store
any information about branches. They're similar to mercurial bookmarks.

Thus, git is not able to answer "Was commit X was made in branch Y?".

What that command does is describe each entry in the log in function of
your active branch. Keep in mind that these descriptions are relative,
and they'll change as you make more commits.

It is basically asking git the following:

    "Is commit X (each log entry) an ancestor of the commit pointed by
    branch Y? (HEAD, meaning your active branch) If yes, describe the
    relationship between them"

Considering your example,

*   changeset: ae68dbe:master
    |\  user:      Uwe Brauer
    | | date:      Tue Aug 20 16:25:53 2019 +0200
    | | summary:   1.2.1/1.1
    | |
    | * changeset: c00bb5d:master^2
    | | user:      Uwe Brauer
    | | date:      Tue Aug 20 16:25:53 2019 +0200
    | | summary:   1.2.1
    | |
    | * changeset: 54c9230:master^2~1
    | |

54c9230 is the parent (~1) of master's second parent (master^2).

If you make an additional commit on master, the same 54c9230 will be
described as master~1^2~1

Check the documentation to learn the syntax: git help revisions

If want a permanent reference for a commit, you'll need to:
    1) Use an unambiguous prefix of the commit ID.
    2) Make a tag to the commit you want to reference.

Cheers,
Rafael Ascensão

Re: [problem with name-rev]

[Junio C Hamano]

Uwe Brauer <oub@mat.ucm.es> writes:

> Gives
> *   changeset: ae68dbe:master
> |\  user:      Uwe Brauer
> | | date:      Tue Aug 20 16:25:53 2019 +0200
> | | summary:   1.2.1/1.1
> | |
> | * changeset: c00bb5d:master^2
> | | user:      Uwe Brauer
> | | date:      Tue Aug 20 16:25:53 2019 +0200
> | | summary:   1.2.1
> | |
> | * changeset: 54c9230:master^2~1
> | | user:      Uwe Brauer
> | | date:      Tue Aug 20 16:25:53 2019 +0200
> | | summary:   1.2
> | |
> * | changeset: da0712f:master~1
> |/  user:      Uwe Brauer
> |   date:      Tue Aug 20 16:25:53 2019 +0200
> |   summary:   1.1
> |
> * changeset: 8eb999d:master~2
>   user:      Uwe Brauer
>   date:      Tue Aug 20 16:25:53 2019 +0200
>   summary:   1
>
> That looks odd.
>
> Any comments?

When you make a merge like the ae68dbe, merging a topic with two
commits 54c9230 and c00bb5d into the then-current tip of the master
branch da0712f, _all_ direct parents are recorded in the resulting
merge commit, so the first parent of it is denoted as ae68dbe~1
(which is da0712f) and the second parent of it ae68dbe^2 (which is
c00bb5d).

There is no linear ordering between these two commits, so c00bb5d
will *never* be named as master~<some-number>.  As a commit on a
side branch, its description from the tip of 'master' will always
involve some ^2 (the second parent of some merge commit) somewhere
in its name-rev result.

If you are saying that the $commit^$nth_parent notation "looks odd",
then you are shooting the messenger with your title.  The problem is
not with name-rev; the problem is with the way the world works.

Re: [problem with name-rev]

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 4658 bytes --]

>>> "JCH" == Junio C Hamano <gitster@pobox.com> writes:

   > Uwe Brauer <oub@mat.ucm.es> writes:
   >> Gives
   >> *   changeset: ae68dbe:master
   >> |\  user:      Uwe Brauer
   >> | | date:      Tue Aug 20 16:25:53 2019 +0200
   >> | | summary:   1.2.1/1.1
   >> | |
   >> | * changeset: c00bb5d:master^2
   >> | | user:      Uwe Brauer
   >> | | date:      Tue Aug 20 16:25:53 2019 +0200
   >> | | summary:   1.2.1
   >> | |
   >> | * changeset: 54c9230:master^2~1
   >> | | user:      Uwe Brauer
   >> | | date:      Tue Aug 20 16:25:53 2019 +0200
   >> | | summary:   1.2
   >> | |
   >> * | changeset: da0712f:master~1
   >> |/  user:      Uwe Brauer
   >> |   date:      Tue Aug 20 16:25:53 2019 +0200
   >> |   summary:   1.1
   >> |
   >> * changeset: 8eb999d:master~2
   >> user:      Uwe Brauer
   >> date:      Tue Aug 20 16:25:53 2019 +0200
   >> summary:   1
   >> 
   >> That looks odd.
   >> 
   >> Any comments?

   > When you make a merge like the ae68dbe, merging a topic with two
   > commits 54c9230 and c00bb5d into the then-current tip of the master
   > branch da0712f, _all_ direct parents are recorded in the resulting
   > merge commit, so the first parent of it is denoted as ae68dbe~1
   > (which is da0712f) and the second parent of it ae68dbe^2 (which is
   > c00bb5d).




   > There is no linear ordering between these two commits, so c00bb5d
   > will *never* be named as master~<some-number>.  As a commit on a
   > side branch, its description from the tip of 'master' will always
   > involve some ^2 (the second parent of some merge commit) somewhere
   > in its name-rev result.

Hm I realize that I understand git much less than I thought (I thought
it is like mercurial, where git branches are mercurial bookmarks more or
less). It turns out that this is not the case.

Take the following part of what I did

git init 
echo 1 > 1
git add 1
git commit -m 1
echo 1.1 > 1
git add .
git commit -m 1.1
git checkout -b foo master~1
echo 1.2 > 1
git add .
git commit -m 1.2
echo 1.2.1 > 1
git add .
git commit -m 1.2.1
git checkout master

There are 4  commits.

But 

Git --log --graph --decorate 

Returns
* commit 98922f82932cd1bef58bebf0229367922bca45fc (HEAD -> master)
| Author: Uwe Brauer <oub@mat.ucm.es>
| Date:   Tue Aug 20 21:19:59 2019 +0200
|
|     1.1
|
* commit 8f565d59c356a6038e3d8a7f5dcd2e4a39ae1bb4
  Author: Uwe Brauer <oub@mat.ucm.es>
  Date:   Tue Aug 20 21:19:59 2019 +0200


If I would do the same with mercurial (either with bookmarks or with
named branches) I receive 

hg init 
echo 1 > 1
hg add 1
hg commit -m 1
hg branch foo
echo 1.1 > 1
hg add .
hg commit -m 1.1
hg branch master 
echo 1.2 > 1
hg add .
hg commit -m 1.2
echo 1.2.1 > 1
hg add .
hg commit -m 1.2.1
hg checkout master




@  changeset:   3:9ebcc17a6389
|  branch:      master
|  tag:         tip
|  user:        Uwe Brauer <oub@mat.ucm.es>
|  date:        Tue Aug 20 21:27:05 2019 +0200
|  summary:     1.2.1
|
o  changeset:   2:e02d297e2f75
|  branch:      master
|  user:        Uwe Brauer <oub@mat.ucm.es>
|  date:        Tue Aug 20 21:27:04 2019 +0200
|  summary:     1.2
|
o  changeset:   1:7ddaef206d57
|  branch:      foo
|  user:        Uwe Brauer <oub@mat.ucm.es>
|  date:        Tue Aug 20 21:27:04 2019 +0200
|  summary:     1.1
|
o  changeset:   0:dbf3c9975cf3
   user:        Uwe Brauer <oub@mat.ucm.es>
   date:        Tue Aug 20 21:27:03 2019 +0200
   summary:     1



Funny enough if I convert the git repo, to a hg repo either with hg
convert or with hg clone (and the hg-git plugin)

I receive a different graph

o  changeset:   3:e7b2696c94fb
|  bookmark:    master
|  tag:         tip
|  parent:      0:5dfd9027787a
|  user:        Uwe Brauer <oub@mat.ucm.es>
|  date:        Tue Aug 20 21:19:59 2019 +0200
|  summary:     1.1
|
| o  changeset:   2:277f6423b9c8
| |  bookmark:    foo
| |  user:        Uwe Brauer <oub@mat.ucm.es>
| |  date:        Tue Aug 20 21:19:59 2019 +0200
| |  summary:     1.2.1
| |
| o  changeset:   1:3529c82f37ae
|/   user:        Uwe Brauer <oub@mat.ucm.es>
|    date:        Tue Aug 20 21:19:59 2019 +0200
|    summary:     1.2
|
o  changeset:   0:5dfd9027787a
   user:        Uwe Brauer <oub@mat.ucm.es>
   date:        Tue Aug 20 21:19:59 2019 +0200
   summary:     1


Anyhow, I don't want this message to be interpreted as a flamewar of
sorts.

I don't really know how the import functions work, but I see that git
and mercurial treat commits which look simple to me very differently. 

Uwe Brauer 

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

Re: [problem with name-rev]

[Phil Hord]

On Tue, Aug 20, 2019 at 12:35 PM Uwe Brauer <oub@mat.ucm.es> wrote:
>
> Take the following part of what I did
>
> git init
> echo 1 > 1
> git add 1
> git commit -m 1
> echo 1.1 > 1
> git add .
> git commit -m 1.1
> git checkout -b foo master~1
> echo 1.2 > 1
> git add .
> git commit -m 1.2
> echo 1.2.1 > 1
> git add .
> git commit -m 1.2.1
> git checkout master
>
> There are 4  commits.
>
> But
>
> Git --log --graph --decorate
>
> Returns
> * commit 98922f82932cd1bef58bebf0229367922bca45fc (HEAD -> master)
> | Author: Uwe Brauer <oub@mat.ucm.es>
> | Date:   Tue Aug 20 21:19:59 2019 +0200
> |
> |     1.1
> |
> * commit 8f565d59c356a6038e3d8a7f5dcd2e4a39ae1bb4
>   Author: Uwe Brauer <oub@mat.ucm.es>
>   Date:   Tue Aug 20 21:19:59 2019 +0200

Try adding '--all' to include all refs, not just the current HEAD, to
begin logging from. Here is what I see after running your setup
script.

$  git log --graph --decorate --all
* commit 3262040f2d8d5f31b4918bda9987e6b5f788531f (foo)
| Author: Phil Hord <phord@purestorage.com>
| Date:   Tue Aug 20 12:44:32 2019
|
|     1.2.1
|
* commit fc66c4311bf954d455f468581f2913dffa0f9c2b
| Author: Phil Hord <phord@purestorage.com>
| Date:   Tue Aug 20 12:44:32 2019
|
|     1.2
|
| * commit 109e5d4baef4e99cf636189ba1499af817ab0bb1 (HEAD -> master)
|/  Author: Phil Hord <phord@purestorage.com>
|   Date:   Tue Aug 20 12:44:32 2019
|
|       1.1
|
* commit 5c1e93ed7c5b3b241d5adfadb365a6bca5d60d3a
  Author: Phil Hord <phord@purestorage.com>
  Date:   Tue Aug 20 12:44:32 2019

      1


You could also mention only the refs you are interested in instead of
including all of them.
$  git log --graph --decorate foo master

Re: [problem with name-rev]

[Uwe Brauer]

[-- Attachment #1: Type: text/plain, Size: 1491 bytes --]


   > On Tue, Aug 20, 2019 at 12:35 PM Uwe Brauer <oub@mat.ucm.es> wrote:

   > Try adding '--all' to include all refs, not just the current HEAD, to
   > begin logging from. Here is what I see after running your setup
   > script.

   > $  git log --graph --decorate --all
   > * commit 3262040f2d8d5f31b4918bda9987e6b5f788531f (foo)
   > | Author: Phil Hord <phord@purestorage.com>
   > | Date:   Tue Aug 20 12:44:32 2019
   > |
   > |     1.2.1
   > |
   > * commit fc66c4311bf954d455f468581f2913dffa0f9c2b
   > | Author: Phil Hord <phord@purestorage.com>
   > | Date:   Tue Aug 20 12:44:32 2019
   > |
   > |     1.2
   > |
   > | * commit 109e5d4baef4e99cf636189ba1499af817ab0bb1 (HEAD -> master)
   > |/  Author: Phil Hord <phord@purestorage.com>
   > |   Date:   Tue Aug 20 12:44:32 2019
   > |
   > |       1.1
   > |
   > * commit 5c1e93ed7c5b3b241d5adfadb365a6bca5d60d3a
   >   Author: Phil Hord <phord@purestorage.com>
   >   Date:   Tue Aug 20 12:44:32 2019

   >       1

That's it, thanks. Interestingly enough the 

 git graph looks differently from the mercurial one.

The mercurial one looks purely linear (with two branches) while the git one is not,
but maybe it is not clear to me who to translate the git command 

git checkout -b foo master~1

To mercurial?

Anyhow the original question was about having a sort of local revision
number and I see that this is somehow possible, which was not clear to
me before. 

Thanks

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5025 bytes --]

Re: [problem with name-rev]

[Uwe Brauer]

   > That's it, thanks. Interestingly enough the 

   >  git graph looks differently from the mercurial one.

It does not. I just did not understand the git commands at first sight
well enough. Both graphs look the same. Sorry for the noise.