Jump to content

GIT Rev number?


Recommended Posts

  • Replies 111
  • Created
  • Last Reply

Top Posters In This Topic

Git is based on a SHA1 hash of commit. That way, it's not based on "rev numbers" but individual changes.

If I pull your change, it won't be different from someone else pulling your change. We will both be getting commit <SHA1 ID> rather than rev 23, 55, 1230.

Hmm... too bad we can't have a SHA1 decrypter built into our heads... would make things much easier.

Link to comment
Share on other sites

I agree for shorter hash , "Revision 9d1ac13" is enough, it would also be more readable if used in commit description, patch submission, bug report etc. github and git command accept short hashs.

09:08:27 MaNGOS/0.12.0-SVN (2008-10-22 23:08:34 Revision 9d1ac13) (Win32,little-endian)

m-daemon)

As you see forum soft stop make from short hash link to commit page. So better use full hash and this let have nice link after paste logs to forum post.

For find commit can be used data+time in 99.999% case infact. Only very small time ranged commits need hash start for find proper.

Also i plan as suggest Wik3d make shift-link in chat ".server info" output from hash. Then it can be shift-copy to open chat line and then selected and copy to clipboard from it.

And used for search commit or paste in forum thread/etc.

Link to comment
Share on other sites

In the end I have resorted to using simple datetime in automated build system/rev matching (hash is not linear and can not be used to match revisions by < or > qualifiers). It does not give much accuracy but it's suitable until two commits with SQL files included arrive in one second. That has extremely low probability but still not zero.

Link to comment
Share on other sites

In the end I have resorted to using simple datetime in automated build system/rev matching (hash is not linear and can not be used to match revisions by < or > qualifiers). It does not give much accuracy but it's suitable until two commits with SQL files included arrive in one second. That has extremely low probability but still not zero.
That is why it's important to have datetime + hash .. you use only datetime in 99.99% of the cases, but when there's a tie you check the hashes.
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use