Hacker News Reader

Comment by sytse | Hacker News Reader

The core team indicated they quite like the sequential numbering that SVN gives them. I'm considering building it into GitLab as an option if they would use it to host ruby :)

View on HN

Inspired by Mercurial, we built such functionality for GIT backend in RhodeCode. So the numeric identifiers are used now for all 3 backends we support. Kallithea has it also implemented for GIT.

I personally never like the meaningless hashes. Those numbers act as good identifier of project size and progress. It quickly shows what kind of ranges we're taking when doing a compare, or simply looking at files and seeing those numbers.

It gives a lot of context. Just look how much more useful information a compare shows r1808:39334bf35fdf...r1819:3e8df3a82397 vs 39334bf35fdf...3e8df3a82397

Cool! How do you deal with the issues raised in https://news.ycombinator.com/item?id=13310271 ?

I'd like to understand how it could work. For the simple case with a master branch and one feature branche we could number commits as they are merged into master. What about two branches worked on at the same time, with multiple commits and merged to master? If the numbering has to reflect the timestamps of the commits it should be recomputed at every merge which is probably not desirable. However every branch has its own numbering and I don't know if it's desirable to have two numbers for the same commit.

Would you implement it using tags?

I think we would number only the master branch. Using soft or hard tags is an option. I've created an issue https://gitlab.com/gitlab-com/marketing/issues/747

Mercurial and bzr have those sequential numbers. They really aren't the awful apocalyptic problem that git users seem to think they are. bzr tries harder to make them sequential and meaningful, but even hg's more lax approach to revision numbers is still useful: they are still approximately semantic, much more than node hashes.

Reply on news.ycombinator.com