21–30 of 59 posts
Always wondered how coding in Perl is, guess I will have some fun with it tomorrow :)
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”.)
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…
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.
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.
> 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…
Only after people grok that do I mention "git pull", and only in passing while discouraging its use.
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 inven…
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 g…
Earlier quoted context omitted.
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 g…
Would you care to share that story?
Earlier quoted context omitted.
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).
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.