git rm -r --cached . | |
git add . | |
git commit -m 'git cache cleared' | |
git push |
The standard way of understanding the HTTP protocol is via the request reply pattern. Each HTTP transaction consists of a finitely bounded HTTP request and a finitely bounded HTTP response.
However it's also possible for both parts of an HTTP 1.1 transaction to stream their possibly infinitely bounded data. The advantages is that the sender can send data that is beyond the sender's memory limit, and the receiver can act on
Doing a pip install reportlab
on a relatively new/clean linux setup will probably result in something similar to this:
--------------------------------------------------------------------
PIL SETUP SUMMARY
--------------------------------------------------------------------
version Pillow x.y.z
platform linux2 2.x.y (default, MM dd YYYY, 01:01:01)
git fetch --all | |
git reset --hard origin/master | |
git pull origin master |
Suppose you have, by mistake, added your IDE's project folder (you know, these .idea
folders with all kinds of local paths and configuration data and settings in it) to the Git repository of your project. (We're talking about a whole folder here, but the same rules apply to individual files as well.)
Of course, you only realize that two days after the fact and have already pushed it, and your colleagues have already pulled it. They use the same IDE as you do, so whenever they change a setting or fix paths, they can either
- commit that, causing nasty merge conflicts for you and others or
- ignore the changes and carry around a modified file until the end of time without ever committing it.
git clone -b {branch} [email protected]:{repo_name}.git |
[ | |
{name: 'Afghanistan', code: 'AF'}, | |
{name: 'Åland Islands', code: 'AX'}, | |
{name: 'Albania', code: 'AL'}, | |
{name: 'Algeria', code: 'DZ'}, | |
{name: 'American Samoa', code: 'AS'}, | |
{name: 'AndorrA', code: 'AD'}, | |
{name: 'Angola', code: 'AO'}, | |
{name: 'Anguilla', code: 'AI'}, | |
{name: 'Antarctica', code: 'AQ'}, |
At the top of the file there should be a short introduction and/ or overview that explains what the project is. This description should match descriptions added for package managers (Gemspec, package.json, etc.)
Show what the library does as concisely as possible, developers should be able to figure out how your project solves their problem by looking at the code example. Make sure the API you are showing off is obvious, and that your code is short and concise.