27

Is it possible (somehow) to have in Git (local) relative revision (commit) numbers, like in Mercurial 0, 1, 2, 3, ... instead of short hashes?

Or anything more user friendly?

Rook
  • 60,248
  • 49
  • 165
  • 242
  • 3
    If you want it user-friendly, why not use a Git GUI client where you can *select* the commit instead of having to enter an ID for it? – Mot Feb 26 '11 at 18:38
  • 2
    @mklhmnn - Because I don't :) (working often on a laptop, no mouse in sight - I prefer the cl interface as often as I can; besides, yet to see a git gui that I would consider using on an ibm compatible; mac versions are a different story) – Rook Feb 26 '11 at 19:27
  • There is a way to do the opposite -- given a hash, assign an integer to it in a logical way, similar to what hg does. I wish I could find the post that describes it; I'll keep looking. You could probably hack something together that does that automatically every time you create a new commit, and then create a command that goes from the "hg-style" number to the SHA. Edit: Looks like `git describe` is what I was thinking of. http://ufoai.ninex.info/forum/index.php?topic=5538.0 – Tyler Feb 26 '11 at 22:05
  • I have argued many times that mercurial's revision numbers are not user friendly, but quite misleading. I've worked in groups using mercurial and when someone mentions `rev 1342` there's really no way to know what version they're actually talking about unless I look at their working directory. – Dustin Feb 27 '11 at 20:25
  • 1
    @Dustin - They're not misleading, but practical. One should always keep in mind they're local (rev 1342 is pretty far down, though) – Rook Feb 27 '11 at 22:21
  • "local" in practice translates to "don't say them out loud." In a team environment, we too often had people talking about version numbers and having them not line up between two peer developers, even when they were recent. Not being canonical and implying bidirectionality without actually delivering it (e.g. what change comes after `213`?), I've not missed it. hg would be better off if they just never showed them. I like hg, but this is one part that I think hurts it. – Dustin Feb 28 '11 at 02:08
  • 2
    @Dustin - I don't see the problem with them, except that you don't have to constantly type hashes, but the convenience when working on own, to have nice numbers. When talking to other devs you are, of course, gonna use hashes. Saves a lot of typing, and they're much more friendly than remembering the difference between (9b2466 and 4332b3) (in contrast to rev 3 and 5). When working alone that is, and that is a lot of time. – Rook Feb 28 '11 at 10:26
  • 1
    I just about never type hashes. I might ask what the difference is between `1.2.3` and `1.2.4` or since `origin/master~5`. I'll paste a hash if I want to be specific. Practice is different from what you might think you'll be doing. This reminds me a lot of how resistant people are to take up python due to whitespace significance, but once you do, you rarely think about it. – Dustin Feb 28 '11 at 20:53

4 Answers4

44

Just use:

  • master~10 to get the 10th last commit on branch master.
  • master^ to get the second last commit on branch master.
  • master^^ to get the third last commit on branch master.

They can even be combined: master^^~5^.

master can be any branch name (local or remote) or HEAD to reference the current commit.

You can use master^2 to get the second merge parent.

spongebob
  • 8,370
  • 15
  • 50
  • 83
knittl
  • 246,190
  • 53
  • 318
  • 364
  • 3
    Would it not be better to use `HEAD` instead of `master`? That way you don't have to think about which branch you'r on. – Martin Olsen Feb 26 '11 at 18:43
  • 3
    @martin: well, HEAD always counts back from the currently checked out commit (can be a branch, a tag or a commit in detached head state). it depends on the use case, substitute the actual branch name – knittl Feb 26 '11 at 18:45
  • Thanks knittl; I've read about those in O'reilly's book, but somehow I don't see it as a big improvement. Expecially since that I don't have neither the tilde nor the ^ on my languages's keyboard layout (Croatian), so I have to switch to En every time for that. – Rook Feb 26 '11 at 18:59
  • Would it be possible somehow to create a series of aliases that would take 1, 2, 3 ... and convert them to ? What do you think; is it feasible? – Rook Feb 26 '11 at 19:00
  • @rook: oh, i did not know about the keyboard layout. a quick wikipedia search tells me that there are dead version of tilde and circumflex on 1 and 3. does pressing those keys twice give the expected results? i don't think it's possible to create aliases to do what you are asking for – knittl Feb 26 '11 at 19:06
  • @knittl - Only the tilde is there (additionally, it is a laptop keyboard :/ ), but that is besides the point. I was hoping to evade it completely. – Rook Feb 26 '11 at 19:24
  • 1
    Is there a way to refer to the newer versions the same way? – haridsv Oct 27 '11 at 05:04
2

You can always refer to a commit by using a prefix of its SHA-1 hash, as long as it is unique. E.g., if you want to checkout 980e3ccdaac54a0d4de358f3fe5d718027d96aae, you can use git checkout 980e as long as no other commits start with 980e.

Aasmund Eldhuset
  • 37,289
  • 4
  • 68
  • 81
  • On the other hand, if your objective is to more easily be able to see which commits precede which, you should probably use `gitk`, Git Extensions or some other tool to visualize the commit graph. – Aasmund Eldhuset Feb 26 '11 at 18:37
  • 1
    I'm trying to evade those prefixes (good grief; it never even occured to me that I would go writing a full hash) - those six or eight (usually), since coming from Hg that is one thing that is bugging me to no end (no, I couldn't choose my vcs this time). – Rook Feb 26 '11 at 18:57
  • @Rook: Of course, I didn't think you were typing the hashes; I just figured you felt that they weren't particularily aesthetically pleasing. :-) I was also annoyed about the hashes when I switched from Hg to git, but my personal experience is that you get used to them, and with branch management being so easy and flexible in git, there is not that much of a need to deal directly with the hashes (particularily not if you use visualization tools). – Aasmund Eldhuset Feb 26 '11 at 19:07
  • yeah, I guess there is some truth in what you're sayin'. I gather I will get used to it (in a time) but for now they're bugging me to no end :) – Rook Feb 26 '11 at 19:18
2

I just made something doing exactly this: dash-r. It's still rough, but you might find it useful.

Basically, it's a shim that can produce a modified version of the basic git log with commit lines like so:

commit 4  id: a4d0892d38f4d72902e35a5b1ca11e602fffcef6

and then reference these numbers by surrounding the -r invocation with backticks:

git diff `-r 2`

(Assuming you install it in your path with the name "-r". I do that since it looks like a regular option if I ignore the backticks.)

It can even handle ranges and negative numbers:

git diff `-r 2..-2`

Git's lack of revision numbers has been a major hurdle for me in warming to Git. Seeing SHA hashes in git log breaks my flow. So I hope it will help both of us.

James Jensen
  • 363
  • 3
  • 8
0

Short answer: No. Yes.

However, you could use git-tag. For example, to tag your latest commit as version 1.2 do something like:

git tag -a v1.2 HEAD

This page explains how to use it for versioning: http://grinninggecko.com/commit-version-numbers-with-git/

Community
  • 1
  • 1
Martin Olsen
  • 1,895
  • 1
  • 17
  • 20