5 ms·

This is one thing I really loved about subversion. I just used the VCS revision as the tag and version therefore avoiding this issue. Didn’t even need to create

by m0xte 7y ago

This is one thing I really loved about subversion. I just used the VCS revision as the tag and version therefore avoiding this issue. Didn’t even need to create tags. That was until the version overflowed the 16 bit field it was stored in the assembly manifest. Kaboom. :( People spend way too much time arguing with semantic versioning when 99% of the time the only important thing is the next number is bigger than the previous number.

jakobegger 7y ago
SVN revision numbers are the only thing I miss after switching to git.
- m0xte 7y ago
  I miss knowing what I'm doing :) Git has so many footguns it's unreal.
  - adrianN 7y ago
    If you only do the things you can also do with svn, the footguns disappear.
  - folbec 7y ago
    The reason why I prefer Mercurial to Git, whenever I can.
  - virgilp 7y ago
    Does it, though? It's immutable. As soon I understood that, I no longer felt that git has _any_ footgun. Whatever dumb thing you do - you can just do `git reflog`, find last good known hash, go back to it, and it fixes everything. Just don't push to github (or whatever git server you use) & don't run garbage collection while you're in a middle of a botched rebase :)
    - juped 7y ago
      Pushing messed-up history is the biggest footgun. Pushing a wrong tag is a close second. Two smart git strategies mitigate the problems: don't push things, and don't pull things.
      - virgilp 7y ago
        > Pushing messed-up history is the biggest footgun. But this one is a footgun only in the sense that you may mess up things for others, and embarrass yourself. Not in the sense of "permanent data loss", right? "don't pull things" is definitely bad advice (even if it was ironic) - you don't mess up anything by pulling things; you can easily go back to how things were. Instead of downvotes, maybe clarify how you mess up things with git? Maybe I can help. I really find it very hard to mess things up. Like, how do you mess up pushing the wrong tag? Unless you force-push it, but why would you do that? Or you mean, you've tagged something wrong? Where's the (permanent) harm in that? I mean, I can imagine "harm" in the sense of "inconvenience", but nothing more serious, unless the mistake goes unnoticed for a very long while (and then, how would any other version control system help you?)
        michaelt 7y ago
        > I really find it very hard to mess things up. In my experience the difference between my trouble-free use of git and inexperienced users' troubles with git amount to: I avoid doing the wrong thing in the first place, inexperienced users do the wrong thing, then try to fix it. For example, I just never commit a gigabyte binary file to the repo. But if an inexperienced user does by mistake, and that makes .git/objects/pack big and everyone's checkouts become slow? And then they notice a few days later, after other developers have pulled and pushed other changes? And they try to fix it? Disaster zone.
        abricot 7y ago
        How do you use git without push and pull?
thrower123 7y ago
I agree, it is such a cluster to get human-usable version numbers out of git. I use a convoluted Rube Goldberg contraption based on tags and git-version[1]. It's so much less convenient than old SVN revision numbers. [1] https://gitversion.readthedocs.io/en/latest/ https://gitversion.readthedocs.io/en/latest/
- e12e 7y ago
  My favorite is the complexity of having an in-tree changelog that lists (shortlog) commits under appropriate tag headings - checked in under appropriate tags. It roughly amounts to: 1) commit fix (git commit -m "fixes #foo bug" 2) get hash/shortlog, add to changelog 3) commit changelog referencing commit in 1) 4) tag hash in 3) with new minor version 1.1.2 to 1.1.3 5) realize you forgot that 1) warranted a bump in minor version, edit changelog to reflect new minor version 6) commit new changelog 7) move tag from 4) to 6) - hope you didn't push yet... And people say RCS $Id:$ was a hack... Now,the real issue is actually to find a nice way to tag actual releases, with current tag and hash. I realize this is mostly tricky when a project is "checkout and run" - without a build step (eg ruby on rails project). It's still somewhat painful to make sure there's an up to date global variable that correctly reflects the running version.
  - z3t4 7y ago
    I clone the project into a temp directory, then inject the version number into the source.
- WorldMaker 7y ago
  I find `git describe` pretty human-usable. (I use it in a lot of automated processes.) You still need to tag every now and then, as the format is based on the most recent tag, but it tells you a bunch of useful information fairly compactly and almost semver compliant (in many cases you want to swap the first hyphen with a plus for true semver compliance if your tags are semver releases). It's format: {mostRecentAnnotatedTag}-{numberOfCommitsAfter}-g{headCommitShortHash} Such as: v2.0.3-3-g1cafe9 That has enough information to get you back to exactly which branch was built (3 commits after v2.0.3 with a hash starting 1cafe9). Of course if you git describe when you've checked out the tagged commit itself you just get the tag back v2.0.3. It's not as simple as simple "revision ID", but it is pretty simple. In some of my CI pipelines I've been considering swapping my simple `git describe` tricks for `git-version` to make it easier to get more semver-like build metadata in order to CD them, but I've also considered just regexing that first hyphen to a plus and calling it a day.

by m0xte 7y ago

jakobegger 7y ago

SVN revision numbers are the only thing I miss after switching to git.

m0xte 7y ago
I miss knowing what I'm doing :) Git has so many footguns it's unreal.
- adrianN 7y ago
  If you only do the things you can also do with svn, the footguns disappear.
- folbec 7y ago
  The reason why I prefer Mercurial to Git, whenever I can.
- virgilp 7y ago
  Does it, though? It's immutable. As soon I understood that, I no longer felt that git has _any_ footgun. Whatever dumb thing you do - you can just do `git reflog`, find last good known hash, go back to it, and it fixes everything. Just don't push to github (or whatever git server you use) & don't run garbage collection while you're in a middle of a botched rebase :)
  - juped 7y ago
    Pushing messed-up history is the biggest footgun. Pushing a wrong tag is a close second. Two smart git strategies mitigate the problems: don't push things, and don't pull things.
    - virgilp 7y ago
      > Pushing messed-up history is the biggest footgun. But this one is a footgun only in the sense that you may mess up things for others, and embarrass yourself. Not in the sense of "permanent data loss", right? "don't pull things" is definitely bad advice (even if it was ironic) - you don't mess up anything by pulling things; you can easily go back to how things were. Instead of downvotes, maybe clarify how you mess up things with git? Maybe I can help. I really find it very hard to mess things up. Like, how do you mess up pushing the wrong tag? Unless you force-push it, but why would you do that? Or you mean, you've tagged something wrong? Where's the (permanent) harm in that? I mean, I can imagine "harm" in the sense of "inconvenience", but nothing more serious, unless the mistake goes unnoticed for a very long while (and then, how would any other version control system help you?)
      - michaelt 7y ago
        > I really find it very hard to mess things up. In my experience the difference between my trouble-free use of git and inexperienced users' troubles with git amount to: I avoid doing the wrong thing in the first place, inexperienced users do the wrong thing, then try to fix it. For example, I just never commit a gigabyte binary file to the repo. But if an inexperienced user does by mistake, and that makes .git/objects/pack big and everyone's checkouts become slow? And then they notice a few days later, after other developers have pulled and pushed other changes? And they try to fix it? Disaster zone.
        abricot 7y ago
        How do you use git without push and pull?

thrower123 7y ago

I agree, it is such a cluster to get human-usable version numbers out of git. I use a convoluted Rube Goldberg contraption based on tags and git-version[1]. It's so much less convenient than old SVN revision numbers. [1] https://gitversion.readthedocs.io/en/latest/ https://gitversion.readthedocs.io/en/latest/

e12e 7y ago
My favorite is the complexity of having an in-tree changelog that lists (shortlog) commits under appropriate tag headings - checked in under appropriate tags. It roughly amounts to: 1) commit fix (git commit -m "fixes #foo bug" 2) get hash/shortlog, add to changelog 3) commit changelog referencing commit in 1) 4) tag hash in 3) with new minor version 1.1.2 to 1.1.3 5) realize you forgot that 1) warranted a bump in minor version, edit changelog to reflect new minor version 6) commit new changelog 7) move tag from 4) to 6) - hope you didn't push yet... And people say RCS $Id:$ was a hack... Now,the real issue is actually to find a nice way to tag actual releases, with current tag and hash. I realize this is mostly tricky when a project is "checkout and run" - without a build step (eg ruby on rails project). It's still somewhat painful to make sure there's an up to date global variable that correctly reflects the running version.
- z3t4 7y ago
  I clone the project into a temp directory, then inject the version number into the source.
WorldMaker 7y ago
I find `git describe` pretty human-usable. (I use it in a lot of automated processes.) You still need to tag every now and then, as the format is based on the most recent tag, but it tells you a bunch of useful information fairly compactly and almost semver compliant (in many cases you want to swap the first hyphen with a plus for true semver compliance if your tags are semver releases). It's format: {mostRecentAnnotatedTag}-{numberOfCommitsAfter}-g{headCommitShortHash} Such as: v2.0.3-3-g1cafe9 That has enough information to get you back to exactly which branch was built (3 commits after v2.0.3 with a hash starting 1cafe9). Of course if you git describe when you've checked out the tagged commit itself you just get the tag back v2.0.3. It's not as simple as simple "revision ID", but it is pretty simple. In some of my CI pipelines I've been considering swapping my simple `git describe` tricks for `git-version` to make it easier to get more semver-like build metadata in order to CD them, but I've also considered just regexing that first hyphen to a plus and calling it a day.