In chroots and other test environments these variables might be set to values that cause Git to error out, so explicitly set dummy values. Keep the equivalent configuration in .travis because Travis does unset these (or all?) variables.
Where previously the function `buffer-file-name' was called without an argument, instead just use the variable by the same name. Now this is done consistently across the code base.
This reverts commit fd688cb.
The diff header looks like on of these: diff --git a b diff --cc a diff --combined a Change the regexp so that both "a" and "a b" fall into the second submatch. For `--git' that means that the variables `orig' and `file' are set to wrong values, but that does not matter, since in that case they are later set again from other headers. Fixes #2211.
These arguments expect a number as value, but the value can also be omitted in which case git uses some default value. By using `magit-popup-read-number' we forced the user to input a number. Now we use just `read-string', allowing the user to input a number, nothing, or something invalid (which unfortunately won't be noticed until git tries to use it). Fixes #2208.
This fixes #2197. We don't actually want to show the buffer belonging to another client, so we call `server-done' instead of `server-edit'. The latter calls the former and then also tries to select a buffer, using `server-switch-buffer' which favors buffers belonging to another client. This does matter when Emacs was started in daemon mode and the user connects to the instance using the emacsclient and then uses Magit to invoke. When s/he then completes the commit, then their always is another client, the one used to connect to the instance in the first place. Later in `with-editor-return' we restore the window configuration from before `with-editor' was used, so one would think that needlessly showing another buffer before restoring the window configuration would not matter. However the previous window configuration has to be explicitly stored by the caller of `with-editor', so we cannot rely on a configuration being stored and have to fix the above issue anyway. In the case of committing using Magit this should not have made a difference because that does save the previous window configuration, but unfortunately it does it to late, when the configuration has already been modified somewhat. I am not sure if that can be fixed, but in any case that's a different issue.
Also add a test for this function. Fixes #2135.
Travis only has Git v1.8.5 but using Magit interactively requires v1.9.4. However compiling Magit doesn't require Git at all and the current tests also work with v1.8.5. So do not check the Git version when compiling or loading `magit.el' on Travis. Eventually, when we add new tests, that will start failing, but we can deal with that then (by figuring out how to install a more recent Git version on Travis).
Make sure that default-directory stays set at the top-level directory. When magit-blame is called from an indirect buffer, the find-file call sets default-directory to the file's directory, so the downstream git call (now from the file's directory) fails when given a path relative to the top-level directory. This isn't an issue when magit-blame is called from a buffer visiting a file. The call to find-file does not override the default-directory let-bound by magit-with-toplevel because the file is already being visited by the current buffer. Fix this by let-binding the find-file call separately. While this makes it possible call magit-blame from an indirect buffer, point is not placed appropriately in the base buffer. This probably isn't worth taking the time to fix given that calling magit-blame from indirect buffer isn't very common (since the above error has yet to be reported).