3 ms·

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

by sytse 10y ago

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

jordigh 10y ago
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.
marcinkuzminski 10y ago
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
- sytse 10y ago
  Cool! How do you deal with the issues raised in https://news.ycombinator.com/item?id=13310271 https://news.ycombinator.com/item?id=13310271 ?
pmontra 10y ago
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?
- sytse 10y ago
  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 https://gitlab.com/gitlab-com/marketing/issues/747

by sytse 10y ago

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

jordigh 10y ago

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.

marcinkuzminski 10y ago

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

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

pmontra 10y ago

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?

sytse 10y ago
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 https://gitlab.com/gitlab-com/marketing/issues/747