Things github allows that you should never do

git push --force

You have messed up your clone of the repository if github rejects "git push". The best you can do is to clone a fresh copy of the repository to resolve your problem. If you don't it becomes our problem and we dislike this kind of problem.

See gihub help and perils of rebasing.

Note this quote from the second link in particular:

Do not rebase commits that you have pushed to a public repository.

If you follow that guideline, you’ll be fine. If you don’t, people will hate you, and you’ll be scorned by friends and family.

Use non-portable constructs

The short definition of non-portable is, if it is not documented in a man page, it is not portable; if you have to hunt around for a manifest constant, it is not portable.

The long answer is that POSIX.1 is great and common unix (once called spec 1170) is fine.

As an example, the second parameter of setsockopt() (the level of the option to be set) can only be specified portably as SOL_SOCKET; all other values should be obtained from getprotobyname(); there are no other portable manifest constants. (Sure, Linux has SOL_TCP, but others do not.)

So where do you find out what is portable and what is not?

The standard that Hercules developers are encouraged to adhere to is the Single UNIX Specification published by the Open Group. A personal use copy can be downloaded from: http://pubs.opengroup.org/onlinepubs/9699919799/download/.

The FreeBSD and Linux man pages are also good at showing standards compliance, with Linux often being more informative.

Contrast these sections of setsockopt from FreeBSD 9.1:

HISTORY
     The getsockopt() and setsockopt() system calls appeared in 4.2BSD.

And Linux (Fedora 13):

CONFORMING TO
       SVr4, 4.4BSD (these system calls first appeared in 4.2BSD), POSIX.1-2001.

However, if you want the formal standard, you will have to stump up money as far as POSIX is concerned (IEEE or ISO). X/Open are more lenient. See the Single UNIX Specification.