This reverts commit 19a6e24a.

This was a local experiment that I pushed to Github accidentally.

This makes it easy to download the submodule from behind a corporate
firewall.

Thanks Alexander Groß.

This has been requested by at least 10 people now, so it might be time
for one.

I thought Markdown did support URL recognition automatically.

Conflicts:
	git-flow-version

This already was the default behaviour of git-flow-feature, but now it
is the default for the other scripts, too.

RATIONALE: Due to limitations on some platforms (and some
implementations of getopt), it's impossible to turn off the -f (fetch)
option.  Therefore, it must now be set explicitly.

Also, this makes git-flow work in stand-alone repositories (i.e. repos
that do not have an origin remote at all).

Also, invite users to help out on the git-flow completion for zsh.
Personal itch that needs some serious scratching :)

It disturbs the layout of the README file and nobody uses 0.1 anymore
anyway.  At least I hope (for them).

Finishing features now only update / and / if they exists, this allows you to work on a unpushed repo, or a git svn repo

Should have done this way earlier on the develop branch.

See the README file for instructions on how to use it.

This new subcommand lets you easily work together with peers on features. It's
intended to be extremely simple to pull changes from your co-developers.

This implementation may also be ported to release and/or hotfix branches in the
near future, if we agree on the final implementation details.

Example use
===========
Sharing development of feature branches goes as follows:

Suppose Alice and Bob are both developers on project Foo.  They have local
repos that are up-to-date with `origin`.  Then, Alice starts working on some
feature:

   alice$ git flow feature start newprotocol
   Switched to a new branch 'feature/newprotocol'
   ...

Then, she hacks on the new feature, commits as desired, until the feature's
finished.  She then likes Bob to code-review the feature, so she asks Bob to
pull from her.  (Assuming Bob has a Git remote defined, pointing to Alice's
repo.)

    bob$ git remote
    alice

    bob$ git branch
    * develop
      feature/reader
      master

    bob$ git flow feature pull alice newprotocol
    Created local branch feature/newprotocol based on alice's feature/newprotocol.

    bob$ git branch
      develop
    * feature/newprotocol
      feature/reader
      master

Since the new feature branch is already checked out, Bob can immediately start
peer reviewing the code.  He changes the code as desired and commits each
comment individually, so Alice can later read the Git commit log as the peer
review log.

    bob$ git commit
    [feature/newprotocol 1f6fa95] Forgot return statement.
     1 files changed, 1 insertions(+), 1 deletions(-)
    ...

When he's finished, he tells Alice he's done.  Alice then, in turn pulls in the
peer review commits from Bob, using the same command Bob used to fetch the
changes initially.  (Because feature/newprotocol is still her current branch,
she may omit the explicit 'newprotocols' argument.)

    alice$ git flow feature pull bob
    Pulled bob's changes into feature/newprotocol.

If she disagrees with Bob's comments, she may again commit changes and ask Bob
to do the same again.  This leads to a continuous pull cycle until both parties
agree on the final implementation.  Then, Alice (as the feature owner) finished
the feature.  Bob may discard his feature branch.