GitPython/git/test, branch 1.0.1

fix(config): selective cfg write;fix cfg parser

2015-04-22T06:56:18+00:00

* config parser now handles quoted values correctly. This doesn't hamper
  multi-line support.
* added regression test to travis to assure we will be warned if we
  rewrite and break the user's .gitconfig file
* only rewrite configuration files if we actually called a mutating
  method on the writer. Previously it would always rewrite it.

Fixes #285

test: make git-daemon port configurable via env

2015-04-21T12:44:16+00:00

add a GIT_PYTHON_TEST_GIT_DAEMON_PORT to set a port other than 9418,
for example for when you already have a daemon running on that port.

test: Make git-daemon only listen on localhost

2015-04-21T11:28:13+00:00

No reason to expose a daemon to all interfaces when it is only used for
tests, which connect to localhost anyway.
I'd love to use localhost here instead, but the git-daemon man page points out:

    If IPv6 is not supported, then --listen=hostname is also not
    supported and --listen must be given an IPv4 address.

I don't know of a way to check if git has ipv6 support, but 127.0.0.1
should be around for the foreseeable future

fix(test_docs): we are at major version 1 now

2015-04-16T07:12:13+00:00

It expected to see major version 0 though.

Merge branch 'teeberg-master'

2015-04-08T12:58:53+00:00

fix(test_cmd): handle GitCommandNotFound in test

2015-04-08T10:08:54+00:00

Related to #248

fix(remote): allow to raise during push/fetch

2015-04-08T09:00:32+00:00

Do not swallow non-zero exit status during push and fetch unless
we managed to parse head information.

This behaviour will effetively handle cases were no work was done
due to invalid refspecs or insufficient permissions.

Fixes #271

fix(docs): be clear about exit code handling

2015-04-08T08:41:18+00:00

When pushing/pulling, we ignore errors unless it's exit code 128.
The reason for this is now made explicit to make clear that issues
are handled by PushInfo flags accordingly.

Related #271

fix(index): don't write extension data by default

2015-04-08T07:50:26+00:00

It turned out that the index is not actually corrupted, which is good
news. What happens is that `git` writes `TREE` extension data into the
index, which causes it to write out the given tree *as is* next time
a `git commit` is executed. When using `git add`, this extension data
is maintained automatically. However, GitPython doesn't do that ... .
Usually this is no problem at all, as you are supposed to use
`IndexFile.commit(...)` along with `IndexFile.add(...)`.

Thanks to a shortcoming in the GitPython API, the index was
automatically written out whenever files have been added, without
providing control over whether or not *extension data* will be
written along with it.

My fix consists of an additional flag in `IndexFile.add(...)`, which
causes extension data not to be written by default, so commits can be
safely done via `git commit` or `IndexFile.commit(...)`.

However, this might introduce new subtle bugs in case someone is
relying on extension data to be written. As this can be controlled
through the said flag though, a fix is easily done in that case.

Fixes #265

test(index): test for #265

2015-04-07T16:27:16+00:00

However, it doesn't reproduce on the latest version of GitPython.
Maybe it's on an older one.