issue #790: git bundle create does not close handle to *.lock file
This problem happens when an user tries to create an empty bundle, using the
following command: `git bundle create <bundle> <revlist>` and when <revlist>
resolve to an empty list (for example, like `master..master`), `git bundle` fails
and warn the user about how it don't want to create empty bundle.
In that case, git tries to delete the `<bundle>.lock` file, and since there's still
an open file handle, fails to do so and ask the user if it should retry (which will
fail again).
The lock can still be deleted manually by the user (and it is required if the user
want to create a bundle after revising his rev-list).
Signed-off-by: Gaël Lhez <gael.lhez@gmail.com>
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>
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>
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>
When user is asked for credentials there is no need to mask username,
so PROMPT_ASKPASS flag on calling credential_ask_one for login is
unnecessary.
credential_ask_one internally uses git_prompt which in case of given
flag PROMPT_ASKPASS uses masked input method instead of
git_terminal_prompt, which does not mask user input.
This fixes#675
Signed-off-by: yaras <yaras6@gmail.com>
This fix refers https://github.com/git-for-windows/git/issues/664
After `git merge --squash` git creates .git/SQUASH_MSG (UTF-8 encoded)
which contains squashed commits. When run `git gui` it copies SQUASH_MSG
to PREPARE_COMMIT_MSG, but without honoring UTF-8. This leads to encoding
problems on `git gui` commit prompt.
The same applies on git cherry-pick conflict, where MERGE_MSG is created
and then is copied to PREPARE_COMMIT_MSG.
In both cases PREPARE_COMMIT_MSG must be configured to store data in UTF-8.
Signed-off-by: yaras <yaras6@gmail.com>
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>
When using remotes (with git-flow especially), the remote reference names
are almost always wordwrapped in the "list references" window because it's
somewhat narrow by default. It's possible to resize it with a mouse,
but it's annoying to have to do this every time, especially on Windows 10,
where the window border seems to be only one (1) pixel wide, thus making
the grabbing of the window border tricky.
Signed-off-by: James J. Raden <james.raden@gmail.com>
Tcl/Tk 8.6 introduced new events for the cursor left/right keys and
apparently changed the behavior of the previous event.
Let's work around that by using the new events when we are running with
Tcl/Tk 8.6 or later.
This fixes https://github.com/git-for-windows/git/issues/495
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In particular on Windows, where the default maximum path length is quite
small, but there are ways to circumvent that limit in many cases, it is
very important that users be given an indication why their command
failed because of too long paths when it did.
This test case makes sure that a warning is issued that would have
helped the user who reported Git for Windows' issue 521:
https://github.com/git-for-windows/git/issues/521
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Enable DEP (Data Execution Prevention) and ASLR (Address Space Layout
Randomization) support. This applies to both 32bit and 64bit builds
and makes it substantially harder to exploit security holes in Git by
offering a much more unpredictable attack surface.
ASLR interferes with GDB's ability to set breakpoints. A similar issue
holds true when compiling with -O2 (in which case single-stepping is
messed up because GDB cannot map the code back to the original source
code properly). Therefore we simply enable ASLR only when an
optimization flag is present in the CFLAGS, using it as an indicator
that the developer does not want to debug in GDB anyway.
Signed-off-by: İsmail Dönmez <ismail@i10z.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is the first step for enabling ASLR (Address Space Layout
Randomization) support. We want to enable ASLR for better protection
against exploiting security holes in Git.
The problem fixed by this commit is that `ld.exe` seems to be stripping
relocations which in turn will break ASLR support. We just make sure
it's not stripping the main executable entry.
Signed-off-by: İsmail Dönmez <ismail@i10z.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
