Hacker News Reader

Comment by perlgeek | Hacker News Reader

Another "fun" one: typo in git tag names.

The rakudo project has monthly releases with tags like 2019.07. Once I mixed up the year and month in e release, so I created a tag 2018.06 instead of 2016.08 (don't remember the exact numbers), and pushed it.

I deleted the wrong tag as soon as I noticed, and pushed the correct one, but of course when the date of the typo'ed release month came around some years later, things blew up for everybody who still had the wrong tag in their local repo (which turned out to be quite some developers).

View on HN

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.

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

I miss knowing what I'm doing :)

Git has so many footguns it's unreal.

If you only do the things you can also do with svn, the footguns disappear.

The reason why I prefer Mercurial to Git, whenever I can.

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

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.

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

> 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.

How do you use git without push and pull?

Have you replied to the right comment? I didn't say I use git without push and pull.

Don't push things. When you push messed-up history to a public target, you now have messed up history forever. Whoops. You will never publish the correct history now.

Pushing messed-up tags can lead to really annoying consequences because tags are a global namespace (except when they aren't), but this comes up much less frequently, especially since tagging a release is a bit ceremonial.

Don't pull things. This is not "ironic" (what is that supposed to mean?) and it will avoid the other side of git footguns. Pulling is a maintainer's shortcut operation (i.e., Linus Torvalds or one of the subsystem vice-Linuxes) and messes up history forever if used on public targets.

I go back and forth depending on mood on what the right thing to do about git's footguns is, but you were right that there's no way to permanently screw up a git repository - if you don't push things and don't pull things. (Seriously, don't! When you publish things, publish them.)

> When you publish things, publish them.

What does that mean operationally?

> This is not "ironic" (what is that supposed to mean?)

I thought you were being ironic, in the sense of "if you only use git locally you don't mess stuff up". You definitely pull the shared branches; you just don't force-push to them, and that makes it ok.

> Seriously, don't! When you publish things, publish them.

By "publish" I suppose you mean "push, when there is no upstream branch"? Well, yes, but I also force-push a lot and it's quite ok to do so when you work alone on a branch (e.g. to keep it constantly rebased on top of master). I wouldn't say "don't push, ever" - that's an overkill. I'd just say "protect you master branch so that people can't force-push on it".

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/

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.

I clone the project into a temp directory, then inject the version number into the source.

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.

Typos are the worst when it comes to things like that.

Especially when you're the type of person who always seems to have typos after you proof read something a few times. But then when you proof it again AFTER you post it, suddenly they all jump out. I can't count the number of times I've gone and edited a HN comment even after proof reading it a few times.

Needless to say dealing with tags or writing a tweet often includes a silly amount of triple checking.

Also typos in container names.

Reply on news.ycombinator.com