31–40 of 59 posts
Earlier quoted context omitted.
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.
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 " the tag is for a commit which is not a parent of nqp master" right?
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.
Earlier quoted context omitted.
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 somethi…
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.
Earlier quoted context omitted.
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 somethi…
"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?)" :)
> 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…
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.