git: ‘pull’ is not a git-command fix – CentOS 5

This had been bugging me for a while:

# git pull origin mastergit: 'pull' is not a git command. See 'git --help'.Did you mean this?    shell

I’d done my googly thang several times, and tried the few solutions suggested, to no avail.

One I’d probably seen mentioned before is setting the *nix environment variable.
Now, I’m not a full on sys-admin, and some bits I’ve just not really picked up, but this time I decided to do a little research into setting environment variables and give it a whack:

UNIX: Set Environment Variable [new window]

Yeah, ok, that’s actually piss-easy.

So, first find out your git exec path. This is the location of your git-core directory.

Directory find is a bit tedious, so I just did:

# locate git-core

Which gave a massive list of results, but in there I found my path – in my case /usr/local/libexec/git-core

So following the instructions for bash:

# export GIT_EXEC_PATH=/usr/local/libexec/git-core

I than ran set to check the change had taken, and tried to pull again.


At last.

Okay kiddies, that’s the end of another adorable bedtime story, off to sleep now. 

If only… Wishing on a macrocosm

Would that my 2012 blog stats reflected the rest of the world.

IE < 9%

What bliss that would be…


Browser contribution to total:
1.   Firefox 43.15%
2.   Chrome 37.39%
3.   Internet Explorer 8.66%
4.   Safari 7.70%
5.   Opera 2.11%
6.   Android Browser 0.43%
7.   Mozilla Compatible Agent 0.09%
8.   Opera Mini 0.09%
9. 0.09%
10.   RockMelt 0.09%

Cleaning up PHP – Terminal conditions with continue;/return;

PHP (or any language where code blocks are indented) can get a bit messy sometimes

OK, that’s not a literal example, but it does happen. If your condition is terminal, that is: if it is not met, no further action is taken; then there is no need to wrap a massive chunk of code in curly braces and indent it yet further. Break out of the cycle! If you are in a loop, you can just continue; – for example instead of:

you can do this:

In this ridiculously abbreviated example, it does look longer, and yes it will always result in more code, but where you have several terminal conditions in a section of logic which are separated by a number of lines, this technique can save you one hell of a lot of indenting, making your code that much more readable. Our original example, while longer, would be a lot simpler to follow:

In a similar way to loops, if you are in a function, you can simply return; (or return true/false; as appropriate) earlier rather than doing it in an else statement; Shocking? No. A revelation? Hardly, these are not new constructs. But common? Not from the code I see. Give it a go. I will…

jQuery .width() may not return pixels if element is hidden

jQuery 1.7.1

This got me for a while – while there is some discussion of .width() not behaving properly, only this stackOverflow [new window] hinted at the fact I wasn’t mad – all the others being sparse on examples, or poorly worded, leaving me wondering.

But, hell, I’ll give it a go, I thought, and it turned out that I was suffering exactly this:

The jQuery documentation clearly states:

The difference between .css(width) and .width() is that the latter returns a unit-less pixel value (for example, 400) while the former returns a value with units intact (for example,400px). The .width() method is recommended when an element’s width needs to be used in a mathematical calculation.

Ok, fair enough.

But I had {n} columns in a graph, containing a bar in each. The columns are set to (100 / {n})% width while the graph is being populated – and most importantly here, hidden.

I wanted to give my bars a little padding in pixels, so I needed to get the column size in pixels. In my example I had 4 columns, width 25% each, which worked out as 88px. Calling $(‘.column).width() -6 I expected to get 82, but got 19 instead.

One stackOverflow suggested that you should use an id instead – not ideal, as I don’t always know what the ids will be and don’t want to bother storing one just for the sake of the calculation. But I tried it with this case as I did know the ids – and it still didn’t work.

So I moved the column .width() call to after my .show() call – and magically, it returned 82.

Call it an ‘undocumented feature’, call it a bug, but watch out for it!

I ought to report this, but as of writing the jQuery trac is down. MySQL has gone away apparently :'(