Tools interacting with Git repositories may need to know the complete
state of the working directory. For efficiency, it would be good to have
a single command to obtain this information.
We already have a `--porcelain` mode intended for tools' consumption,
and it only makes sense to enhance this mode to offer more information.
Just like we do elsewhere in Git's source code, we now interpret
multiple `--verbose` flags accumulatively, and show substantially more
information in porcelain mode at verbosity level 2.
Signed-off-by: Jeff Hostetler <jeffhost@microsoft.com>
On Windows, we have to juggle two different schemes of representing
paths: the native, Windows paths (the only ones known to the main
Git executable) on the one hand, and POSIX-ish ones used by the Bash
through MSYS2's POSIX emulation layer on the other hand.
A Windows path looks like this: C:\git-sdk-64\usr\src\git. In modern
Windows, it is almost always legal to use forward slashes as directory
separators, which is the reason why the Git executable itself would use
the path C:/git-sdk-64/usr/src/git instead. The equivalent POSIX-ish
path would be: /c/git-sdk-64/usr/src/git.
This patch works around the assumption of t2300-cd-to-toplevel.sh that
`git --exec-path` spits out a POSIX-ish path, by converting the output
accordingly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, files cannot be removed nor renamed if there are still
handles held by a process. To remedy that, we introduced the
close_all_packs() function.
Earlier, we made sure that the packs are released just before `git gc`
is spawned, in case that gc wants to remove no-longer needed packs.
But this developer forgot that gc itself also needs to let go of packs,
e.g. when consolidating all packs via the --aggressive option.
Likewise, `git repack -d` wants to delete obsolete packs and therefore
needs to close all pack handles, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When testing a merge driver which spawns a merge server (for future merges)
I got the following error:
Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed. Should I try again? (y/n)
Only after I stop the merge server the lock is released.
This is caused by windows handle inheritance.
Starting childs with bInheritHandles==FALSE does not work,
because no file handles would be inherited,
not even the hStdXxx handles in STARTUPINFO.
Opening every file with O_NOINHERIT does not work,
Since it is used by git-upload-pack for example,
which expects inherited handles.
This leaves us with only creating temp files with the O_NOINHERIT flag.
Which (currently) only used by lock_file which is exactly what we want.
Signed-off-by: Ben Wijen <ben@wijen.net>
This test was added to verify the behaviour of merge
when a merge server is spawned.
Because file handles are inherited by child processes,
the index.lock is also inherited and - on win32 - can't
be released until the child has stopped.
Signed-off-by: Ben Wijen <ben@wijen.net>
Update tests for "http.extraHeaders=<header>" to be portable back
to Apache 2.2 (the original depended on <RequireAll/> which is a
more recent feature).
* js/http-custom-headers:
submodule: ensure that -c http.extraheader is heeded
t5551: make the test for extra HTTP headers more robust
tests: adjust the configuration for Apache 2.2
Rebased-and-signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch increases the precision of the version recorded in
the resources of the .exe files from major/minor to include also the
micro version and the patch level.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The git submodule--helper clone command will fail with a segmentation
fault when given a null url or null path variable. Since these are
required for proper functioning of the submodule--helper clone
subcommand, add checks to prevent running and fail gracefully when
missing.
Update the usage string to reflect the requirement that the --url and
--path "options" are required.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Extra unused arguments to git submodule--helper clone subcommand were
being silently ignored. Add a check to the argc count after options
handling to ensure that no extra arguments were left on the argv array.
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Reviewed-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git commit --amend preserves the author details unless --reset-author is
given.
git-gui discards the author details on amend.
Fix by reading the author details along with the commit message, and
setting the appropriate environment variables required for preserving
them.
Reported long ago in the mailing list[1].
[1] http://article.gmane.org/gmane.comp.version-control.git/243921
Signed-off-by: Orgad Shaneh <orgad.shaneh@audiocodes.com>
The CreateProcessW() function does not really support spaces in its
first argument, lpApplicationName. But it supports passing NULL as
lpApplicationName, which makes it figure out the application from the
(possibly quoted) first argument of lpCommandLine.
Let's use that trick (if we are certain that the first argument matches
the executable's path) to support launching programs whose path contains
spaces.
This fixes https://github.com/git-for-windows/git/issue/692
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When a 1-line file is augmented by a second line, and the user tries to
stage that single line via the "Stage Line" context menu item, we do not
want to see "apply: corrupt patch at line 5".
The reason for this error was that the hunk header looks like this:
@@ -1 +1,2 @@
but the existing code expects the original range always to contain a
comma. This problem is easily fixed by cutting the string "1 +1,2"
(that Git GUI formerly mistook for the starting line) at the space.
This fixes https://github.com/git-for-windows/git/issues/515
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This fixes an issue where the Git wrapper would terminate upon Ctrl+C,
even in the case when its child process would *not* terminate.
Note: while the original intention was to fix running Git Bash in
ConsoleZ, the bug fix applies also to running
C:\Program Files\Git\bin\bash -l -i
in a cmd window.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There was a bug in the wrapper where it would interpolate incorrectly if
the name of the environment variable to expand was longer than the value.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch adds the --command=<command> option that allows
starting the Git Bash (or Git CMD) with different terminal emulators
than the one encoded via embedded string resources.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Use msysGit's `git-wrapper` instead of the builtins. This works around
two issues:
- when the file system does not allow hard links, we would waste over
800 megabyte by having 109 copies of a multi-megabyte executable
- even when the file system allows hard links, the Windows Explorer
counts the disk usage as if it did not. Many users complained about
Git for Windows using too much space (when it actually did not). We
can easily avoid those user complaints by merging this branch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This topic branch addresses the bug where Git for Windows 2.x' Git GUI
failed to generate a working shortcut via Repository>Create Desktop
Shortcut.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This branch introduces support for reading the "Windows-wide" Git
configuration from `%PROGRAMDATA%\Git\config`. As these settings are
intended to be shared between *all* Git-related software, that config
file takes an even lower precedence than `$(prefix)/etc/gitconfig`.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
These fixes were necessary for Sverre Rabbelier's remote-hg to work,
but for some magic reason they are not necessary for the current
remote-hg. Makes you wonder how that one gets away with it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
