Start the merging-rebase to v1.8.3

This commit starts the rebase of 694fb72 to 8af0605
using 191fb70eb608aba49712e14e29a42db6d964d255 as base.
Make CFLAGS more strict

This is a gcc-ism, but as we use gcc exclusively, we can use them.

Taken from one of Junio's mails. (Reminded to cherry-pick this patch
by one of Karsten Blees' mails.)

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Do not compile compat/**/*.c with -Wold-style-definition

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Makefile: Do not use OLD_ICONV on MINGW anymore

We are building libiconv now the same way as upstream MinGW does, so we do
not need OLD_ICONV anymore when compiling Git either in msysGit or
mingwGitDevEnv.

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Define NO_GETTEXT for Git for Windows

The dreaded "your vnsprintf is broken (returned -1)" error is back. At
least with the libintl version we have. So for the moment, just work
around the issue by _not_ using gettext.

Ah, I wish that my attempt at implementing a custom strbuf_vaddf() would
not have been brushed aside so rashly. Oh well. Time saved on maintaining
that thing, I guess (although more time went into working around coping
with existing implementations).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
msysgit: Add the --large-address-aware linker directive to the makefile.

This has the effect of increasing the address space from 2GB to 4GB under
64-bit Windows, reducing the likelihood of an "out of memory" error when
e.g.  repacking a large repository.  The test suite passes with this
patch, with and without the MEM_TOP_DOWN flag added to all VirtualAlloc
calls.  While this is no guarantee that there are no issues with large
memory support (it could break Git on other setups than mine, for
example), it at least increases the chance that nothing obvious goes wrong
(such as errors introduced by faulty sign extension, say, with ssize_t).

[PT: Resolves github issue #12]

Signed-off-by: Pierre le Riche <github@pleasedontspam.me>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
core.hidedotfiles: hide '.git' dir by default

At least for cross-platform projects, it makes sense to hide the
files starting with a dot, as this is the behavior on Unix/MacOSX.

However, at least Eclipse has problems interpreting the hidden flag
correctly, so the default is to hide only the .git/ directory.

The config setting core.hideDotFiles therefore supports not only
'true' and 'false', but also 'dotGitOnly'.

[jes: clarified the commit message, made git init respect the setting
by marking the .git/ directory only after reading the config, and added
documentation, and rebased on top of current junio/next]

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When initializing .git/, record the current setting of core.hideDotFiles

This is on Windows only, of course.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
mingw: do not hide bare repositories

As reported in msysGit issue 450 the recent change to set the windows
hidden attribute on the .git directory is being applied to bare git
directories. This patch excludes bare repositories.

Tested-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
mingw: add tests for the hidden attribute on the git directory

With msysGit the .git directory is supposed to be hidden, unless it is
a bare git repository. Test this.

Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
criss cross rename failure workaround

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Revert "git-gui: set GIT_DIR and GIT_WORK_TREE after setup"

This reverts commit a9fa11fe5bd5978bb175b3b5663f6477a345d428.
git am: ignore dirty submodules

This fixes a rebase in the presence of dirty submodules. This is
orthogonal to the application of patches changing submodules.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-gui: provide question helper for retry fallback on Windows

Make use of the new environment variable GIT_ASK_YESNO to support the
recently implemented fallback in case unlink, rename or rmdir fail for
files in use on Windows. The added dialog will present a yes/no question
to the the user which will currently be used by the windows compat layer
to let the user retry a failed file operation.

Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
git gui: set GIT_ASKPASS=git-gui--askpass if not set yet

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-gui: fix encoding in git-gui file browser

Assume git tree objects (i.e. output of git-ls-tree) are encoded in system
encoding, for display in the git-gui file browser.

Signed-off-by: Karsten Blees <blees@dcon.de>
gitk: fix file name encoding in diff hunk headers

Decode file names from system encoding in all diff hunk header lines, not
just the first (i.e. print nice file names in 'rename from' / 'rename to' /
'Binary files' lines, too).

Signed-off-by: Karsten Blees <blees@dcon.de>
Work around the command line limit on Windows

On Windows, there are dramatic problems when a command line grows
beyond PATH_MAX, which is restricted to 8191 characters on XP and
later (according to http://support.microsoft.com/kb/830473).

Work around this by just cutting off the command line at that length
(actually, at a space boundary) in the hope that only negative
refs are chucked: gitk will then do unnecessary work, but that is
still better than flashing the gitk window and exiting with exit
status 5 (which no Windows user is able to make sense of).

The first fix caused Tcl to fail to compile the regexp, see msysGit issue
427. Here is another fix without using regexp, and using a more relaxed
command line length limit to fix the original issue 387.

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix another invocation of git from gitk with an overly long command-line

Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Add a few more values for receive.denyCurrentBranch

For a long time, this developer thought that Git's insistence that
pushing into the current branch is evil was completely merited.

Just for fun, the original patch tried to show people that Git is right
there, and that it causes more trouble than it does good when Git allows
you to try to update the working tree for fast-forwards, or to detach the
HEAD, depending on some config settings.

Surprisingly, the opposite was shown.

So here is the support for two new options you can give the config
variable receive.denyCurrentBranch:

'updateInstead':
	Try to merge the working tree with the new tip of the branch
	(which can lead to really horrible merge conflicts).

'detachInstead':
	Detach the HEAD, thereby avoiding a disagreement between the
	HEAD and the index (as well as the working tree), possibly
	leaving the local user wondering how on earth her HEAD became
	so detached.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>