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.
I Botched a Perl 6 Release
11–20 of 59 posts
Re: I Botched a Perl 6 Release
#12Always 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.
Re: I Botched a Perl 6 Release
#13Maybe 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 inven…
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.
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.
Re: I Botched a Perl 6 Release
#14> 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 b…
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.
Re: I Botched a Perl 6 Release
#15Maybe 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 inven…
"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.
Re: I Botched a Perl 6 Release
#16Why 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.
Re: I Botched a Perl 6 Release
#17Please just use Jenkins or TeamCity.
Re: I Botched a Perl 6 Release
#18That'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.
Re: I Botched a Perl 6 Release
#19Releases 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...
Re: I Botched a Perl 6 Release
#20Earlier quoted context omitted.
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.
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.