from Hacker News

I Botched a Perl 6 Release

by zoffix222 on 8/21/16, 12:16 AM with 54 comments

• by 13of40 on 8/21/16, 1:40 AM

  Maybe it's just me, but I've worked with a handful of source control systems over the years, and none of them (not even git) has done a terrific job of encapsulating the #1 scenario, which is "I copied some stuff locally and changed it and now I want to put it back on the server so other people can get my stuff (and of course I want undo in case I mess up and merge in case we both change the same file)" without inventing their own special opaque language and concepts for everything. We all intuitively understand file systems somehow but with source control it's way too easy to miss something subtle and end up with a steaming pile of merge conflicts, broken pulls, incomplete fetch requests, unpublished tags, and borked integrations instead of your awesome code ending up on the server so others can share in the awesomeness.

• by cesarb on 8/21/16, 1:57 AM

  > I run my gr alias for git pull --rebase to bring in the new changes

  The mistake was blindly using git rebase. History rewriting (which includes not only rebase but also amend) should be done with care, and never on history which has already been published (with a few special exceptions, but unless you really know what you're doing -- don't).

  The correct thing to do, since the commit was already pushed, would have been "git pull" without the --rebase, and then pushing the resulting merge commit. Getting in the habit of doing "git pull --rebase" every time is not a good idea; better have a "dirtier" history full of merges, than have to untangle messes like this one later.

• by steveklabnik on 8/21/16, 2:34 AM

  Releases are hard. With Rust, our nightly releases are 100% automated, but stable releases are not.

  https://forge.rust-lang.org/release-process.html

  For 1.11, we had two things go wrong:

  1. stable docs got accidentally deleted, so we had a small amount of downtime before the new ones went up.

  2. We recently moved the website to be i18n-able, and there was a subtle bug with Cloudfront invalidation tokens. So the site was updated, but the older version was still being shown for a bit.

  We could and maybe will make this 100% automated in the future. There's always so much work to do...

• by wscott on 8/21/16, 12:46 PM

  This is where I have to point out that this would have been unlikely to happen with BitKeeper. :)

  BitKeeper doesn't provide a 'pull --rebase' and instead puts this in separate commands 'bk pull; bk collapse -e@; bk citool'. By default, collapse will refuse to replace an already released cset. Yeah less powerful, but we believe more predictable.

  Also, tags are fully revisioned controlled and propagate with every pull. You can move a tag to another revision and that operation becomes its own cset that propagates.

  www.bitkeeper.org

• by aftbit on 8/21/16, 1:48 AM

  Why build some new tool to do builds and releases? Why not use something existing like Jenkins or CircleCI? The biggest advantage is that other people will already know how to use it and how it works, unlike anything you build by hand.

• by Zekio on 8/21/16, 1:23 AM

  Always wondered how coding in Perl is, guess I will have some fun with it tomorrow :)

• by pcollinsmokonut on 8/21/16, 8:33 PM

  Git just tries too hard. Worst UI and lexicon.

  There is this charisma around git that I simply don't understand.

  Errors like this are avoidmake. Supporters explain it away as user error.

• by rahkiin on 8/21/16, 8:05 AM

  I mostly use pull, fetch and stash when I can't pull because of local changes. I have a hook on my gitserver to disallow force push: I never rebase. But I can't even rebase the history that is published. Bow I can't screw up too badly :) I really recommend disabling forcepush. Amend can still be used as long as you did not push yet. I don't mind 'oops a typo'-kind of commit messages. It happens.

• by RubyPinch on 8/21/16, 9:35 AM

  Learning question: so the tag was on an orphaned commit? What ways could this be resolved?

  The obvious and chosen one was to tag a new release and explain to people that the old one isn't accessible because of a muck up.

  Would of merging it back in worked? that would of fixed the "<nwc10> the tag is for a commit which is not a parent of nqp master" right?

• by jeffehobbs on 8/21/16, 1:21 AM

  Great headline, good read.

• by rihegher on 8/21/16, 8:12 AM

  "A robot doesn't care if it has to rebuild from scratch a hundred times while you're trying to debug a release-blocker (OK, I think it doesn't care... any robots' rights activists in the audience to tell me I'm wrong?)" :)

• by tux1968 on 8/21/16, 2:01 AM

  That's a very interesting consequence of a git rebase. Would be nice if git warned that a tag would become stale in such a situation. Could even make an argument that it should be automatically updated.

• by johnchristopher on 8/21/16, 7:55 AM

  So, it turns out we need AI to handle GIT.

• by joneholland on 8/21/16, 2:27 AM

  Please just use Jenkins or TeamCity.