Empty (length 0) usernames and/or passwords, when saved in the Windows
Credential Manager, come back as null when reading the credential.
One use case for such empty credentials is with NTLM authentication, where
empty username and password instruct libcurl to authenticate using the
credentials of the currently logged-on user (single sign-on).
When locating the relevant credentials, make empty username match null.
When outputting the credentials, handle nulls correctly.
Signed-off-by: Jakub Bereżański <kuba@berezanscy.pl>
Make sure the helper does not crash when blank username and password is
provided. If the helper can save such credentials, it should be able to
read them back.
Signed-off-by: Jakub Bereżański <kuba@berezanscy.pl>
Git for Windows now ships with the new Git icon from git-scm.com. Use that
icon file if it exists instead of the old procedurally drawn one.
This patch was sent upstream but so far no decision on its inclusion was
made, so commit it to our fork.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
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>
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>
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>
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>
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>
If we use 'eval exec $opt $cmdp $args' to execute git command,
tcl engine will convert the output of the git comand with the rule
system default code page to unicode.
But cp936 -> unicode conversion implicitly done by exec is not reversible.
So we have to use git_read instead.
Bug report and an original reproducer by Cloud Chou:
https://github.com/msysgit/git/issues/302
Karsten Blees writes this code patch.
Cloud Chou find the reason of the bug.
Thanks-to: dscho
Thanks-to: patthoyts
Signed-off-by: Karsten Blees <blees@dcon.de>
Original-test-by: Cloud Chou <515312382@qq.com>
Signed-off-by: Cloud Chou <515312382@qq.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Assumes file names in git tree objects are UTF-8 encoded.
On most unix systems, the system encoding (and thus the TCL system
encoding) will be UTF-8, so file names will be displayed correctly.
On Windows, it is impossible to set the system encoding to UTF-8. Changing
the TCL system encoding (via 'encoding system ...', e.g. in the startup
code) is explicitly discouraged by the TCL docs.
Change gitk and git-gui functions dealing with file names to always convert
from and to UTF-8.
Signed-off-by: Karsten Blees <blees@dcon.de>
When calculating hashes from pointers, it actually makes sense to cut
off the most significant bits. In that case, said warning does not make
a whole lot of sense.
So let's just work around it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
HANDLE is defined internally as a void *, but in many cases it is
actually guaranteed to be a 32-bit integer. In these cases, GCC should
not warn about a cast of a pointer to an integer of a different type
because we know exactly what we are doing.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When the result of a (a, 0) expression is not used, GCC now finds it
necessary to complain with a warning:
right-hand operand of comma expression has no effect
Let's just pretend to use the 0 value and have a peaceful and quiet life
again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With __USE_MINGW_ANSI_STDIO defined to 0, the printf/scanf formats
magically stop throwing warnings!
Assisted-by: Waldek Maleska <weakcamel@users.github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Rename to
config.mak.uname: support MSys2
to make it easier to find the latest merging rebase via
git rev-parse ':/Start'
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Ignoring a merge can be read as ignoring the changes a merge commit
introduces altogether, as if the entire side branch the merge commit
merged was removed from the history. But that is not what happens
if "-p" is not specified. What happens is that the individual
commits a merge commit introduces are replayed in order, and only
any possible merge conflict resolutions or manual amendments to the
merge commit are ignored.
Get this straight in the docs.
Also, do not say that merge commits are *tried* to be recreated. As that is
true almost everywhere it is better left unsaid.
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When *Git for Windows* is installed into a directory that has spaces in
it, e.g. `C:\Program Files\Git`, the `git-wrapper` appends this directory
unquoted when fixing up the command line. To resolve this, just quote the
provided `execpath`.
Signed-off-by: nalla <nalla@hamal.uberspace.de>
This undoes the contentious Git wrapper changes I made earlier, and
retains just the bare minimum to equip the Portable Application with a
Git Bash and a Git CMD.
The resource editing has been taken out, i.e. there is no longer a way
to reconfigure on the command-line which terminal emulator is used by
the Git Bash.
While at it, also fix the problems with the Git wrapper when serving as
replacement for the hardlinked builtins which were pointed out by Philip
Oakley in Git for Windows issue 52.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The idea of having the Git wrapper in the /cmd/ directory is to allow
adding only a *tiny* set of executables to the search path, to allow
minimal interference with other software applications. It is quite
likely, for example, that other software applications require their own
version of zlib1.dll and would not be overly happy to find the version
Git for Windows ships.
The /cmd/ directory also gives us the opportunity to let the Git wrapper
handle the `gitk` script. It is a Tcl/Tk script that is not recognized
by Windows, therefore calling `gitk` in `cmd.exe` would not work, even
if we add all of Git for Windows' bin/ directories.
So let's use the /cmd/ directory instead of adding /mingw??/bin/ and
/usr/bin/ to the PATH when launching Git CMD.
The way we implemented Git CMD is to embed the appropriate command line
as string resource into a copy of the Git wrapper. Therefore we extended
that syntax to allow for configuring a minimal search path.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We recently added the ability to configure copies of the Git wrapper to
launch custom command-lines, configured via plain old Windows resources.
The main user is Git for Windows' `git-bash.exe`, of course. When the
user double-clicks the `git bash` icon, it makes sense to start the Bash
in the user's home directory.
Third-party software, such as TortoiseGit or GitHub for Windows, may
want to start the Git Bash in another directory, though.
Now, when third-party software wants to call Git, they already have to
construct a command-line, and can easily pass a command-line option
`--no-cd` (which this commit introduces), and since that option is not
available when the user double-clicks an icon on the Desktop or in the
Explorer, let's keep the default to switch to the home directory if the
`--no-cd` flag was not passed along.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When we rewrite the command-line to call the *real* Git, we want to skip
the first command-line parameter. The previous code worked in most
circumstances, but was a bit fragile because it assumed that no fancy
quoting would take place.
In the next commit, we will want to have the option to skip more than
just one command-line parameter, so we have to be much more careful with
the command-line handling.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In the meantime, Git for Windows learned to handle those subcommands
quite well itself; There is no longer a need to special-case them in the
wrapper.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In a push to polish Git for Windows more, we are moving away from
scripts toward proper binaries.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The Git wrapper does one thing, and does it well: setting up the
environment required to run Git and its scripts, and then hand off to
another program.
We already do this for the Git executable itself; in Git for Windows'
context, we have exactly the same need also when calling the Git Bash or
Git CMD. However, both are tied to what particular shell environment you
use, though: MSys or MSys2 (or whatever else cunning developers make
work for them). This means that the Git Bash and Git CMD need to be
compiled in the respective context (e.g. when compiling the
mingw-w64-git package in the MSys2 context).
Happily, Windows offers a way to configure compiled executables:
resources. So let's just look whether the current executable has a
string resource and use it as the command-line to execute after the
environment is set up. To support MSys2's Git Bash better (where
`mintty` should, but might not, be available), we verify whether the
specified executable exists, and keep looking for string resources if it
does not.
For even more flexibility, we expand environment variables specified as
`@@<VARIABLE-NAME>@@`, and for convenience `@@EXEPATH@@` expands into
the directory in which the executable resides.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The intention of this change was to make it easier for the Git for
Windows installer, or for power Git users, to change the command-line
launched when executing Git Bash. The idea was to allow reconfiguring
the Git Bash to run different terminals than MSys2's default, mintty.
However, the comments this commit got let no room for misunderstanding:
at least three developers who gained trust by being active in the Git
for Windows offered their vetoes.
RIP, resource editor.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Instead of making it possible to change the .exe icon of git-bash.exe or
git-cmd.exe, this change was compared to adding the option to format USB
drives.
Let's get rid of this change, therefore, before real people are harmed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Otherwise the output of Git commands cannot be caught by, say, Git GUI
(because it is running detached from any console, which would make
`git.exe` inherit the standard handles implicitly).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
