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

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 

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

   > 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

   > 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

   >> 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 

   > 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

On Tue, Aug 20, 2019 at 04:32:12PM +0200, Uwe Brauer wrote:

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.

On Tue, Aug 20, 2019 at 04:32:12PM +0200, Uwe Brauer wrote:

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

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

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.

   > 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 

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

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

   > 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

   > 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.