I Botched a Perl 6 Release | Hacker News Reader

I Botched a Perl 6 Release

perl6.party

121 pointszoffix22254 comments

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.

The only time I've wound up with a steaming mess was when I was first learning Git. I've been using it for 5 years now, and have done some pretty crazy things with it, and yet haven't screwed up the master branch since then. However to get to that point I had to read "Version Control with Git: Powerful Tools and Techniques for Collaborative Software Development" (this was after royally fucking up and not wanting to get fired).

Would you care to share that story?

Basically Tuesday was the weekly deploy day. Master got screwed up from both a code perspective (incorrect conflict resolution), and then my fixes to rewrite history messed things up even more, blocking the release. Basically I didn't understand how Git worked (and me nor anyone else at my company apparently knew about reflogs).

And they'd fire you over that? Woa, horrid place.

Well I wasn't scared of being fired for that one mistake. But I didn't want to make it again, because after the second time you've just shown yourself to be an ass. Most places I've worked at are like "we allow you to make mistakes, but not the same mistake twice."

Git has done a terrific job of it. It just doesn't do a great job at communicating what it does, how it does it, why it does it that way and how to achieve those results.

In other word, git's great internally... externally it just has a poor UI. But what's new there.

Every source control system has had a terrible UI. I mean, most of them don't even really make an attempt. (Unless you count things like Time Machine or Microsoft Word's revision tracking, those are both acceptably decent.)

But Git is a whole 'nother layer of awful beyond all of them.

Another one of the "reasons I can't get along with Linux users" is that they see something like Git and just kind of shrug and deal with it instead of getting angry that we have a piece of basically brand new software that was built without even attempting to incorporate any UI concepts we knew about at the time it was written. And since it's a CLI that about a thousand other scripts and tools consume (instead of having proper separation of the human interface from the machine interface), it basically cannot be improved at this point, not without breaking thousands of third-party tools. Sigh.

That's pretty much true of the entire baroque edifice of unix-based CLI tools. They are what they are, and they can't really change much. Its an increasing hill to climb to become proficient, and those already comfortable have no incentive to change it.

Which is awful, because there's nothing stopping usability development in CLI environments (look at Cortana or Siri, for example, or to a lesser extent PowerShell) except that awful stagnation.

People shouldn't have to bend their brain to work with a machine. The machine should be designed to work with human brains.

And to be that snarky person for a second: I've heard a lot of people who actually love Linux CLIs still complaining about Git's weird-ass behaviors. https://stevebennett.me/2012/02/24/10-things-i-hate-about-gi...

I think it's a problem that you don't need to know Git that well to use it productively. Once you get the basic commands you can pretty much put away Git's documentation for a few years until something goes particularly wrong. It's been on my "list" for a long time now to deep dive into it but I've just never had the impetus to do so despite the fact that I use Git every single day.

I think the real problem is that "knowing git that well" is even a thing. If git's interface were more predictable and if its abstractions were less leaky, learning the basic commands would be enough and noone would ever need to do a deep dive into the documentation.

I finally realized this after reading this xkcd comic[1]. Now I'm happily using mercurial (with hg-git) whenever I expect that I will need to do something nontrivial.

https://xkcd.com/1597/

I don't completely agree. While git definitely could still be more polished, the problem it tries to solve is fundamentally complicated.

Git does a good job of cleanly modeling the graph of distributed changes and providing a set of useful operations on that graph. The disagreement is more about whether somebody has learned or should learn that underlying graph.

I.. yup. That comic never ceases to amaze me.

If Git were well-designed, it'd be free of rough edges and "gotchas", and it would teach you how to use it as you used it by making use of discoverability. If Git were a well-engineered piece of software, it wouldn't even have a manual (certainly not a "required reading" manual).

The purpose of software is only partially to solve problems, the rest of the purpose is to serve as a liaison between user space and implementation space. Many tools with bad UI forget about that second part, but human factors are hugely important in the success of software.

"and of course I want undo in case I mess up and merge in case we both change the same file"

That's what git reflog is for; and if you're paranoid you can set it up so it doesn't garbage collect as aggressively or at all.

I'm inclined to agree, but only on the part of resolving coficts when two truths diverge.

Git does this well if everything is checked into one repo. Submodules are kind of a pain. I wish they were represented better via the CLI.

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

I don't even like the habit of using "git pull". When training folks I start by introducing them to "git fetch" and manually merging or rebasing on the remote tracking branch so they're fully in control of the process while understanding what's going on.

Only after people grok that do I mention "git pull", and only in passing while discouraging its use.

I agree with that. I have an alias for "git pull --ff-only", which I use often though.

It's faster than manually doing the fetch and then merge/rebase. If it succeeds you're at the newest version, if not you can still decide whether to merge or rebase. This should be the default behavior for git pull in my opinion.

So basically you want them each time to do the job that git pull does right 99.999% of the time?

I don't know about him, but yes it's what I do too and I recommend it.

The commit wasn't already pushed though. The problem was with the semantics of a 'tag' in git being immutable, and not being rebased along with the commit and the branch, then getting pushed anyway.

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

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

And open source and has submodules that actually work and has a binary manager that works for world wide development (no single server).

Oh, and has bk fast-import so any git project can try it out. And of course has bk fast-export so you can bail out if you don't like it. Incremental fast-import coming.

Maybe so, but have the licensing and philosophical reasons that led Torvalds to move the kernel away from BitKeeper been resolved?

Until that can be said and news of that disseminated widely, I think many open source projects will consider BitKeeper as simply not having enough of a technical edge over Git to discount the cultural penalties (namely, "bad" reputation withing FLOSS and smaller population of users).

I fully understand your concerns, which it why I try to post about bk periodically. Go look at bitkeeper.org, we are now fully open source and published under a plain Apache 2.0 license. No additional license or restrictions. So we can be as evil as we want and you are still safe to use it. ;-)

BitKeeper was open sourced in May (Apache 2.0 licensed).

The news was disseminated quite widely:

* https://lwn.net/Articles/686896/ * https://news.ycombinator.com/item?id=11667494

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.

My experience tells me that since everyone's build and release cycle is such a unique flower of hackiness that building and maintaining your own pipeline is actually easier than trying to fit everything into the community plugins of Jenkins.

Also have you been on Jenkins recently? It looks and feels like butt.

How recently? Nowadays, Jenkins is looking half-decent again imo. Also, I think you can do literally anything in Jenkins that you can do with a custom tool, without really twisting it out of shape.

The uniqueness of flowers seems to be the driver of the Buildbot philosophy.

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

Perl is a great language. I haven't had an op to use 6 yet but 5 is great for small programs.

The big problem with Perl is it requires discipline to prevent creating a mess for your team or eventual successor.

It's not like Python or Ruby are much better in this regard.

Except they are.

This comment sounds like you've never worked on any program larger than few hundreds lines.

All three languages implement the same programming paradigm and neither of them enforce (or even suggests) any structure whatsoever, so you easily end up with the same mess/spaghetti, no matter the language.

Of course Perl adds some idioms of its own on top of it, but (a) not that many as most people like to attribute to Perl, (b) most of the idioms are syntax sugar, and (c) most of the mess comes from program structure, not from superficial things like syntax.

I completely agree with you. Perl is absolutely terrible for basic oo. Basic getters and setters needs the moose module which instantly slows down your code base beyond.

I'm a very competent oo perl developer. I recently wrote a complex large platform in Perl5. It's simply not good enough.

In addition cpan is like walking the dungeons of moria. amazing relics of complexity frozen in time.

> Perl is absolutely terrible for basic oo.

To clarify for readers who might not know...

* Perl 5 (the language this comment appears to focus on) and Perl 6 (the language the OP is about) are different languages in the same family, like Common Lisp and Clojure.

* Perl 6 OO is syntactically and semantically elegant. "In using Perl 6, one of the things that constantly floors me is how elegant objects are..." [1].

* Perl 6, which has this elegant OO built in, outperforms Perl 5 + Moose for some things and trails it for others.

[1] https://www.reddit.com/r/perl6/comments/4ud7vc/a_python_guy_...

Or yourself a few months down the road.

Obligatory to point out that Perl and Perl6 are quite different languages, and the latter is meant to supplement, not replace, the former.

That said, both Perls are nice languages. Personally I prefer Perl 5 slightly, but both are fun to use, if confusing at first. (Perl, especially Perl 5, seems extremely arbitrary and nonsensical until you “get it”.)

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.

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.

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?

The commit is not orphaned, because the tag is still pointing to it, but it's indeed not reachable from a branch anymore.

git does not update local tags when the tag has changed remotely (see "on retagging" in the git tag man-page), so it would have to be a different tag.

Merging it back would be confusing, because you know have the old branch and the new branch in your history. It would cause the tag to be reachable again from master though.

Great headline, good read.

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

Yep, that's a thing, albeit currently an ironic thing:

https://www.reddit.com/r/botsrights/

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.

Definitely arguable, if git can see the tag is not on the remote yet. The problem is git can't tell if the tag is not on any remote, so just not moving them ever is always the safe choice.

This could have been prevented by using "the cactus model" of git branching (sorry no link to source as am on mobile, Google should find it tho) where releases are branches, not tags.

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

Please just use Jenkins or TeamCity.

Reply on news.ycombinator.com