Human readable/comparable git change IDs

Question

Some version control system, for example, Perforce, keeps CL as simple integer, hence looking into two different CL on same branch, it's easy to understand which CL has been merged first. But, in case of Git, a CL/ short CL is long hex string, which is not even comparable by human eyes easily. Is there any way to get rid of this issue?

This is why every commit in Git has a _message_ associated with it, and possibly a tag as well. — Tim Biegeleisen, Feb 13 '17 at 04:38
I am just guessing, but by "CL" I assume you mean "changelist number". Note that p4 assigns this number from a centralized server, at the time you request it. This serializes access to the repository. — torek, Feb 13 '17 at 14:55

score 2 · Accepted Answer · answered Feb 13 '17 at 05:19

2

I'm afraid not. The distributed nature of the system precludes a nice monotonically increasing "revision number". If you and someone else on the other side of the globe decide to commit (not push) a patch at exactly the same time, who is version n and who is n+1? That kind of synchronisation is possible only when there's a single central server that can assign revision numbers. It's a price to pay for being distributed.

However, while there are no technical solutions, there are social solutions. Good branch names, proper tagging help you understand what's going on with the project. git branch --merged and --no-merged will give you details on what branches are merged and what aren't.

answered Feb 13 '17 at 05:19

Noufal Ibrahim

71,383
13
135
169

1

(This is the right answer and is upvoted.) It's also worth pointing out that when you use tags, you can also use `git describe`. This attempts to compute a somewhat human friendly number, producing output of the form `--g`, which is an approximation to a linear count of commits since ``. Under restrictions that take too much space to describe in a comment, the `` value will be stable. – torek Feb 13 '17 at 14:58
The output of describe, branches, tags and several other things are examples of what are called [treeish](http://stackoverflow.com/questions/4044368/what-does-tree-ish-mean-in-git#18605496)s in git. – Noufal Ibrahim Feb 13 '17 at 17:49
Actually they're "commitish", but of course anything that identifies a commit, wherever a tree is required, will resolve to a tree. A few commands, such as `git show`, will access the commit; in this case you can use the `^{tree}` suffix from gitrevisions to force the commit ID to be converted to the corresponding tree ID. – torek Feb 13 '17 at 17:59

score 1 · Answer 2 · answered Feb 13 '17 at 05:08

No, the SHA-1 hash for git is a 40 characters string. It’s calculated based on contents of files. And git olny stores SHA-1 in database. So it’s not readable for human eyes.

If you want to check the histories of git, git log --oneline --decorate --graph --all is clear to view.

Human readable/comparable git change IDs

2 Answers2