5 ms·

The one thing I really miss about svn is the central,authoritative, auto-incrementing revision numbers. Git hashes are less friendly to use - in the svn days it

by thaeli 4y ago

The one thing I really miss about svn is the central,authoritative, auto-incrementing revision numbers. Git hashes are less friendly to use - in the svn days it was easy to tell at a glance if you had an earlier or later version. Yes, I know the many ways that git is better in practice, and would miss some of the workflows git's nature allows if they were gone. But we really did lose something too, especially when running git in "quasi-centralized" mode such as on GitHub.

scottlamb 4y ago
It's not as simple, but you might be able to get what you want with `git describe`. E.g., a working copy of mine now says `v0.7.5-43-g9060dbf`: 43 commits after tag `v0.7.5`, hash `9060dbf...`.
david_allison 4y ago
It can be done, but probably shouldn't: https://github.com/zegl/extremely-linear/commits/main https://github.com/zegl/extremely-linear/commits/main
- rascul 4y ago
  > With the shit ("short git") wrapper, you can use commands like shit show 14, and shit log 100..150 I found this amusing.
avgcorrection 4y ago
Maybe you can count the first parent commits on mainline, and then reverse that list.
- gmueckl 4y ago
  Git doesn't have a good concept of a mainline branch when going back past a merge. It simply records more than one parent for that commit and not which branches they were on before they got merged. Mercurial does somewhat better in that department by storing the branch name in the commit, so you can pick the parent on the same branch reliably.
  - avgcorrection 4y ago
    I don’t understand what you’re saying. If you have a main branch which is always merged into then `--first-parent` will only list merge commits and regular commits on that branch. I have never seen it fail on our main branch. In `git merge feature`, `feature` will become the second parent while the commit that you are on will become the first. The linear mainline history falls out of that.
    - ynik 4y ago
      It fails if someone merges main into their feature branch, and then performs a fast-forward merge of their feature branch to main. Now the two parents are in the opposite of the expected order, and --first-parent will follow along the feature branch. This can cause the new state of main to have a lower number of first-parent-commits than prior to the merge! However, if you have infrastructure that prevents fast-forward merges to main (prevent developers from pushing directly to main, allow only PR merges and disable fast-forward merges for that), then the `--first-parent` approach can work.
      - avgcorrection 4y ago
        > However, if you have infrastructure that prevents fast-forward merges to main I did say merge, did I not? Yes. > > If you have a main branch which is always merged into then If fast-forward is a “merge” too then fuck it, I can’t be bothered to use Git lingo since every idiotic little thing needs to be qualified (see also: Git tag, which is sometimes only an annotated tag but also sometimes also its cousin “lightweight tag”). I guess I should have said “merge merge”. Huh.
        zerocrates 4y ago
        People will tend to think of a fastforward as a "merge" of sorts since it will happen when you run "git merge," when possible.
        mdavidn 4y ago
        > I did say merge, did I not? Yes. You said "git merge feature", which _does_ perform a fast-forward when possible. In my experience, developers on a large enough project will inevitably break Git in a creative way, and this is one of them. This is the default because "git pull" performs a merge by default. You _want_ that to fast-forward when possible or everyone will create a merge commit every time they pull updates.
sedatk 4y ago
Mercurial supports those, but they're only guaranteed to be consistent per clone. So it mostly helps you when working locally. On the downside, inexperienced developers love to refer to commits by their sequential revision numbers, potentially causing confusion.
jacobr1 4y ago
I've seen a number of places use the "Build Number" from their CI tool on the mainline branch to represent a similar notion. Presuming you've "centralized" things, this tends to work well.
sicp-enjoyer 4y ago
There is no immutable and consistent way to do this in a distributed system.
deleted 4y ago
[deleted]
npteljes 4y ago
The one thing that I also miss. It even gamified my development somewhat. It was satisfying to see how much the revision number went up, and I also loved when I hit a special number, like 1024.

by thaeli 4y ago

scottlamb 4y ago

It's not as simple, but you might be able to get what you want with `git describe`. E.g., a working copy of mine now says `v0.7.5-43-g9060dbf`: 43 commits after tag `v0.7.5`, hash `9060dbf...`.

david_allison 4y ago

It can be done, but probably shouldn't: https://github.com/zegl/extremely-linear/commits/main https://github.com/zegl/extremely-linear/commits/main

rascul 4y ago
> With the shit ("short git") wrapper, you can use commands like shit show 14, and shit log 100..150 I found this amusing.

avgcorrection 4y ago

Maybe you can count the first parent commits on mainline, and then reverse that list.

gmueckl 4y ago
Git doesn't have a good concept of a mainline branch when going back past a merge. It simply records more than one parent for that commit and not which branches they were on before they got merged. Mercurial does somewhat better in that department by storing the branch name in the commit, so you can pick the parent on the same branch reliably.
- avgcorrection 4y ago
  I don’t understand what you’re saying. If you have a main branch which is always merged into then `--first-parent` will only list merge commits and regular commits on that branch. I have never seen it fail on our main branch. In `git merge feature`, `feature` will become the second parent while the commit that you are on will become the first. The linear mainline history falls out of that.
  - ynik 4y ago
    It fails if someone merges main into their feature branch, and then performs a fast-forward merge of their feature branch to main. Now the two parents are in the opposite of the expected order, and --first-parent will follow along the feature branch. This can cause the new state of main to have a lower number of first-parent-commits than prior to the merge! However, if you have infrastructure that prevents fast-forward merges to main (prevent developers from pushing directly to main, allow only PR merges and disable fast-forward merges for that), then the `--first-parent` approach can work.
    - avgcorrection 4y ago
      > However, if you have infrastructure that prevents fast-forward merges to main I did say merge, did I not? Yes. > > If you have a main branch which is always merged into then If fast-forward is a “merge” too then fuck it, I can’t be bothered to use Git lingo since every idiotic little thing needs to be qualified (see also: Git tag, which is sometimes only an annotated tag but also sometimes also its cousin “lightweight tag”). I guess I should have said “merge merge”. Huh.
      - zerocrates 4y ago
        People will tend to think of a fastforward as a "merge" of sorts since it will happen when you run "git merge," when possible.
      - mdavidn 4y ago
        > I did say merge, did I not? Yes. You said "git merge feature", which _does_ perform a fast-forward when possible. In my experience, developers on a large enough project will inevitably break Git in a creative way, and this is one of them. This is the default because "git pull" performs a merge by default. You _want_ that to fast-forward when possible or everyone will create a merge commit every time they pull updates.

sedatk 4y ago

Mercurial supports those, but they're only guaranteed to be consistent per clone. So it mostly helps you when working locally. On the downside, inexperienced developers love to refer to commits by their sequential revision numbers, potentially causing confusion.

jacobr1 4y ago

I've seen a number of places use the "Build Number" from their CI tool on the mainline branch to represent a similar notion. Presuming you've "centralized" things, this tends to work well.

sicp-enjoyer 4y ago

There is no immutable and consistent way to do this in a distributed system.

deleted 4y ago

[deleted]

npteljes 4y ago

The one thing that I also miss. It even gamified my development somewhat. It was satisfying to see how much the revision number went up, and I also loved when I hit a special number, like 1024.