ssh debug3: Incorrect RSA1 identifier debug3: Could not load ".ssh/id_rsa" as a RSA1 public key

When testing ssh with -vvv, you see this in the log:

    debug3: Incorrect RSA1 identifier
    debug3: Could not load ".ssh/id_rsa" as a RSA1 public key

This is not an error.
This is not the problem you're looking for.
Your problem is something else.

(source)

See also another ssh non-error.

How to test CGI::Prototype

Why, use CGI::Prototype::Mecha of course.

debug2: key_type_from_name: unknown key type '-----BEGIN'

SSH debug output can be quite misleading.
When you see the following output, it does NOT indicate a problem.

debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: missing keytype
debug3: key_read: missing whitespace
...
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: missing keytype
debug1: identity file /home/foo/.ssh/id_rsa type 1

The final line tells you that the key was read successfully.

(source)

See also another ssh non-error.

Whitespace woes

One very annoying aspect of software development in a team is whitespace. Many people use it differently. In a way it's unimportant, not least because it's literally invisible and so often overlooked. Yet it continues to cause problems which repeatedly waste time, and is especially distracting and troublesome for the many detail-oriented developers among us.

Clearly the only sane way to use whitespace in Perl is:

• 4 character indent
• only use spaces, never use tabs
• never allow any trailing whitespace

One of the worst violations of these rules is an indent composed of mixed tabs and spaces. This is a list of reasons why that's very wrong:

• When someone gets fed up and changes that whitespace to make it conform, it introduces noise into the code diff (they don't create a separate branch due to the overhead costs in a bureaucratic, audited environment).
• Different text editors and web interfaces all display the indent differently, making the code hard to follow.

So, you're thinking of switching to git...

I've written a few things I learnt about using git:

• Git workflow best practice
• Git hooks, config and prompt

I've also gathered a few links over the years, many relating to the philosophy and strategy of git. Some highlights are:

• A successful Git branching model
• A pretty intense dynamic git cheatsheet
• Git from the bottom up (PDF)
• The git parable
• Complete "Pro Git" book

The git features I like best are:

• git stash
• Quickly store a copy of all your unsaved changes, so you can work on them later
• You can use it like: git stash save "halfway through debugging issue foo"
• git branch
• Unlike other version control systems, git makes it incredibly easy, fast and fun to create a new branch for some changes you've made
• Everything is stored locally until you decide to "push" it to the main repo
• To get the most out of git, frequently commit all your work to some branch or other (at least once a day)
• git reflog
• See a history of (almost) all the git commands you issued
• In case you badly mess up you can save your life here
• git rebase -i
• Interactively squash together several commits
• Change commit messages
• Even split out a large commit into several different commits
• git log --color --stat=200,200 --decorate --abbrev-commit --relative
• Improved log

I publish my git config.