Git Punish – The Missing Git Command
git-punish.io
git-punish.io
In our office, I always take the blame jokingly to lighten the mood. It's a running gag, we have three people who are more senior than the others, and we always say "it's his fault, and if not, it's the other one and if not, then it's Leo's fault" (I am the most senior). When a problem arises, it doesn't matter who inserted the bug, but how to fix it the quickest.
These days I mostly use IDEA's annotate feature and don't even know what's the command used in the backend.
[1] http://svnbook.red-bean.com/en/1.6/svn.ref.svn.c.blame.html
But shaped like this, with the name, the graphics, the "whyyyyy" and the overall implication that the commit author had screwed up, it's indeed hostile and counterproductive.
It lets you find the reason why and context in which certain code was added.
[alias] praise = blame
git praise ./path/to/file
git who file
:)
There's a difference between "curl ... | sh -" and this.
He's even separated it nicely into steps, so you can view that (very short) file in between.
What worries me more is that he doesn't properly quote $@, so this script will break when there are spaces in the filename. One of the reasons I hate bash.
"Don't worry, you don't even need to 'sudo' this so it can't do any harm!" See, it's not running as root while it wipes clean your home folder.
It's not curl thats the problem, it's combination of download and execution in the "curl | sh -" pattern, which is not used in the article.
So everyone needs to check the script before running it anyway. Which is easy, because it's a very short script.
(Of course, it's so short that it might as well have been an alias or, even better, just a copy-pasteable git command, but I guess the author really wanted to call it 'git punish'.)
Am I missing something?
Deleted comment
It is still significantly safer than unencrypted HTTP.
Why do programmers hate other programmers so much? Why do they have so little empathy and care?
Too much staying in one own's head? Lack of exposure to diverse opinions and emotions?
What do you mean?
I think this emerge of a certain way that programmers think of other programers.
There are of course exceptions, but often tools made by other programmers don't seem to respect us as users and have bad user experience: - Few thoughts given to make common operations good, - Lots of clunky menus, - Poor performance,
Basically going out of their ways to make us do something else than programming by killing the feedback loop. (Think libraries that are slow to compile, tools that run slowly or require assistance or are otherwise too granular)
The absolute worst example I can give is something like Hudson or Jenkins.
Though I agree with you to some extent, IMO you chose a bad example. Jenkins has one of the most shallow learning curve of any the tools I use, and doesn't require a lot of fussiness. If I can it to build from a terminal window, I can get it working on Jenkins in 30 minutes.
Might I suggest Appium for your example? The one where, in the official docs, it says "If install fails, keep trying to install a few times." Rest assured that you'll need those instructions. Gawd, I hate Appium.
Problems navigating between pages and knowing what one is looking at abound. Organizing jobs in various tabs works but isn't extremely easy. The UI doesn't handle well dealing with large lists of nodes/labels.
The plugin based architecture might be to blame for it, however I think it's a conscious choice from the original designers and they should be hold responsible for it.
> cd comment-parser/
> git punish -L1,24 index.js
code and committers you see on the page are parsed out from `git blame`
Of course, banter between long-time colleagues is usually harmless. But it's often difficult knowing where to draw the line.
I do agree that a copious amount of praise goes a long way toward developing a healthy environment.
As a tool this would be pointless and unhelpful. A graphic splash that does not explain why the code is bad and how it could be improved. Junior coders would be just shamed while seasoned professionals would be just irritated. Shame and irritation are usually unhelpful emotions.
Otherwise selecting text sometimes results in grabbing the image instead.
It should be a service that mails all other contributors in the commit log something like this: "Mr. <insert name> introduced a CATASTROPHIC security bug right here! Look at that! <insert code> <insert insults> Are all his contributions hidden landmines that might jeopardize the project at any time? Clearly they need to be checked! <insert list of all his other commits>"
Maybe "git shame" would be more appropriate too.
And yeah, you should probably not do that if it's a company project or a noncritical open source project.
But it's fair to say that he created git for a exiting hostile development environment.