
I Botched a Perl 6 Release - zoffix222
http://perl6.party/post/I-Botched-A-Perl-6-Release-And-Now-A-Robot-Is-Taking-My-Job
======
13of40
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.

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

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

~~~
ufo
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/](https://xkcd.com/1597/)

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

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

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

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

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

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

[https://forge.rust-lang.org/release-process.html](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...

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

~~~
abstractbeliefs
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).

~~~
wscott
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. ;-)

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

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

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

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

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

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

~~~
rimantas
Except they are.

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

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

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

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

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

------
jeffehobbs
Great headline, good read.

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

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

[https://www.reddit.com/r/botsrights/](https://www.reddit.com/r/botsrights/)

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

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

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

------
joneholland
Please just use Jenkins or TeamCity.

