_ikke_

Why not just keep environment dependent settings in a separate file that is not tracked? Then you have no problem with files that are 'half-tracked'.

What happens if someone accidentaly committed the Addhandler cgi-script .fcgi change?

Note that --assume-unchanged means you are promissing to git that the file hasn't changed, so it doesn't have to lookt at it every time you invoke git status (for performance reasons).

When you break that promise, git will complain, just like you said.

How do you prevent discrapencies between those? You already see it with comments on source code, which eventually get outdated.

If the jquery version changed, their site could break anyway due to changes in how the library worked.

If you check the cryptographic explanation, you see the first step is sending p and g to the other party. This is the 'common color' you talk about. These aren't predefined in the protocol.

And leave security holes open for people with less good intent and actually harm users?

> "The counterbalancing force here is the constant flow of new features added. This is the normal state for most successful software - we want it to do more things. So while we gain quality from the bugs fixed, we lose quality when adding all the new features"

The next sentences mention that.

No, your git repository is not a backup. It's a record of the history of your project, but it's not sufficient as a backup.

You could see pushing as making a backup, but even that wouldn't backup the exact state of your repository (private branches, configuration, reflog, rerere, etc..).

If an object gets corrupt, it's almost impossible to fix it, unless you have a copy of that object somewhere.

That's why it's still important to make backups of your repository.

Without customers asking for content, L3 wouldn't provide anything to Comcast. It's at the specific request of the customers that L3 relays the replies. The customers initiate the request, and L3 provides the response.

Without the service L3 provides, Comcast wouldn't be able to (as efficiently) provide the service to their customers. In a sense, Comcast should pay L3 for their access to the content.

It's not that anything changes in the mirror to make it transparent.

Such mirrors are half transparent, half reflective. If the other side is dark, the reflective effect is much larger then the transparent effect, making it look like a normal mirror.

When there is a light source behind, the light goes through, which means you can see it. The brighter the light, the more you can see what is behind.

He is talking about TDD / unittests in this case. He is not saying anything about automated testing in general.

From the first chapter of this book, it is described that each layer adds more abstraction. The first layer (input) works on individual pixels, the next layer on a part of the image. Each deeper layer can make more high-level decissions.

Here all is just fine. It shows as verified and encrypted. I have enabled checking the verification list in Chrome.

Fingerprint is:

    C1 4C 4A 4D 63 63 E4 B4 CD 23 02 1A 2F 0A 0E 9A
    AB FB BE D7 0E 59 10 A3 20 01 EB CC 8D 08 DC E2

You can't, and this isn't about freezing bitcoins. They try to prevent people from freezing their non-bitcoin assets.

Wouldn't Same-Origin-Policy prevent this?

A project document with e-mail addresses was retrieved through the account of a dropbox employee[1].

Some people noticed they got e-mail through unique non-disclosed e-mail addresses.

[1]: http://lifehacker.com/5930706/dropbox-confirms-user-email-le...

It's more like `git commit -p`. If you abort `hg record`, the selection you've made is lost.

index and staging area refer to the same thing. The staging area is a high-level concept, while index is more of an implementation detail (exists in .git/index).

Git is quite safe, and most operations that involve doing things to history can be undone. Unsafe operations happen when the working tree and uncomitted changes are involved.

Also, sometimes it's easier for a user to roll back to an older back up than to untangle the mess they have created.

Third, git itself is not a backup. When your repository gets corrupted, you're out-of-luck when you don't have backups for those files. So it's still good to take backups of your repositories.

Because you suggest everyone else should too.

Note that in this case, your remote tracking branches wont be updated, so git status will say you are ahead of the remote, while you are in fact at the same point.

A "git fetch <remote>" would then update the remote tracking branches.

I see the manpages mainly as reference, not as initial introduction.

A faster computer does speed it up. It can go through all the cycles faster.

An even better option is scrypt, which is memory based, which is much harder to scale.

Even if you mark them 'lost', you can't just trivially reassign them. You would need to have the private key to be able to spend them, there is no other way.

The search space grows exponentially with each additional word being added. With enough words, it gets infeasible to bruteforce.

Well, it is a good way to tell computers and humans apart. Computers can read it, while humans can't.

They should reject corectly filled in captchas.

resolving conflicts is not something machines can do. There needs to be a human to decide what is a correct outcome.

Correct url: https://kokonautlabs.wordpress.com/2013/01/20/the-messenger-...

DI is not about glorified globals at all. Nothing forces you to pass in the same object to all things dependend on it.

It just allows you to pass in anything the situation requires.

It allows your code to depend on an interface, instead of an implementation, even if the language doesn't have explicit interfaces.

Sending passwords in plain-text over email is bad enough in itself, and it also tells a lot about how they think about plain-text passwords in general.