If the stdout of the command is connected to a terminal but the stderr
has been redirected, the odds are good that the user can't see any
question we print out to stderr. This will result in a "mysterious
hang" while the app is waiting for user input.
It seems better to be conservative, and avoid asking for input
whenever the stderr is not a terminal, just like we do for stdin.
Signed-off-by: bert Dvornik <dvornik+git@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix the problem where the cmd->err passed into start_command wasn't
being properly closed when certain types of errors occurr. (Compare
the affected code with the clean shutdown code later in the function.)
On Windows, this problem would be triggered if mingw_spawnvpe()
failed, which would happen if the command to be executed was malformed
(e.g. a text file that didn't start with a #! line). If cmd->err was
a pipe, the failure to close it could result in a hang while the other
side was waiting (forever) for either input or pipe close, e.g. while
trying to shove the output into the side band. On msysGit, this
problem was causing a hang in t5516-fetch-push.
I'm not sure why (or if) this problem hasn't cropped up under Linux.
The non-Windows code *does* try to check for execve() failures in the
child, in addition to the fork() failures.
Signed-off-by: bert Dvornik <dvornik+git@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The git_mmap implementation was broken for file sizes that
wouldn't fit into a size_t (32 bits). Changed 'len' to be stored
in an off_t (64 bit) variable, and moved the xsize_t cast to only
occur when an attempt is made to map past the end-of-file.
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>
Suppose you want to edit all files that contain a specific search term.
Of course, you can do something totally trivial such as
git grep -z -e <term> | xargs -0r vi +/<term>
but maybe you are happy that the same will be achieved by
git grep -Ovi <term>
now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This adds an option to open the matching files in the pager, and if the
pager happens to be "less" (or "vi") and there is only one grep pattern,
it also jumps to the first match right away.
The short option was chose as '-O' to avoid clashes with GNU grep's
options (as suggested by Junio).
So, 'git grep -O abc' is a short form for 'less +/abc $(grep -l abc)'
except that it works also with spaces in file names, and it does not
start the pager if there was no matching file.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There were two awfully similar code paths ending the threaded grep. It
is better to avoid duplicated code, though.
This change might very well prevent a race, where the grep patterns were
free()d before waiting that all threads finished.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is really a problem with shell scripts being called on msysGit,
but there are more important bugs to fix for the moment.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When encountering symlinks, do_lstat() currently overwrites
buf->st_mode with S_IFREG if follow is true. This is incorrect
when the symlink points to a directory.
get_file_attr calls GetFileAttributesExA, which follows symlinks
already. So our st_mode should already be correct at this point.
Tested-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
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>
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>
The mingw function to launch the system html browser is silent if the
target file does not exist leaving the user confused. Make it display
something.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Reviewed-by: Erik Faye-Lund <kusmabite@gmail.com>
In msysGit the stat() function has been implemented using mingw_lstat
which sets the st_mode member to S_IFLNK when a symbolic links is found.
This causes the is_executable function to return when git attempts to
build a list of available commands in the help code and we end up missing
most git commands. (msysGit issue #445)
This patch modifies the implementation so that lstat() will return the link
flag but if we are called as stat() we read the size of the target and set
the mode to that of a regular file.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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>
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).
This fixes msysGit issue 387.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows the Control-C binding is used to copy and is mapped to the Tk
virtual event <<Copy>>. In the initial git-gui dialog this is also bound
as an accelerator for the Clone menu item. The effect is that both bindings
run, copying the text but resetting the clone page or switching to the clone
page when the user tries to copy text from one of the entry fields.
This patch avoids this by using Control-L instead for Windows only.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
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>
The same logic as for unlink and rename also applies to rmdir. For
example in case you have a shell open in a git controlled folder. This
will easily fail. So lets be nice for such cases as well.
Signed-off-by: Heiko Voigt <heiko.voigt@mahr.de>
On Windows in case a program is accessing a file unlink or
move operations may fail. To give the user a chance to correct
this we simply wait until the user asks us to retry or fail.
This is useful because of the following use case which seem
to happen rarely but when it does it is a mess:
After making some changes the user realizes that he was on the
incorrect branch. When trying to change the branch some file
is still in use by some other process and git stops in the
middle of changing branches. Now the user has lots of files
with changes mixed with his own. This is especially confusing
on repositories that contain lots of files.
Although the recent implementation of automatic retry makes
this scenario much more unlikely lets provide a fallback as
a last resort.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
When the user tried to create a desktop icon with git gui on cygwin
wscript was complaining about an unknown option and displaying the
non-native path as such.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When creating a desktop shortcut from the gui the shortcut directly
starts wish with the git-gui script. In the msysgit development
environment some dll's reside in the mingw/bin directory which causes
that git can not start because libiconv2.dll is not found.
When using such a link the error is even more cryptic stating:
"child killed: unknown signal"
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
It has already been fixed in commit 454efb47 (git-gui (Win): make
"Explore Working Copy" more robust, 2009-04-01), but has been broken in
commit 21985a11 (git-gui: handle non-standard worktree locations,
2010-01-23) by accidentally replacing too much with a new variable.
The problem can be reproduced when starting git-gui from within a
subdirectory. The solution is to convert the path name, explorer.exe is
invoked with, to a platform native name.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
This fixes issue 394 from msysgit. It seems that the Gnuwin32 project
provides a nice command but it returns a "not implemented" error. To
help users we now try to execute once and disable it in case it fails.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commit 21985a11 'git-gui: handle non-standard worktree locations' attempts
to use either GIT_WORK_TREE or core.worktree to set the _gitworktree
variable but these may not be set which leads to a failure to launch
gitk to review history. Use _gitdir to set the location for a standard
git layout where the parent of the .git directory is the working tree.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
If a file is opened by another process (e.g. indexing of an IDE) for
reading it is not allowed to be deleted. So in case unlink fails retry
after waiting for some time. This extends the workaround from 6ac6f878.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
These two tests fail on msysGit because /dev/null is an alias for nul on
Windows and when reading the value back from git config the alias does
not match the real filename. Also the HOME environment variable has a
unix-style path but git returns a native equivalent path for '~'. As
these are platform-dependent equivalent results it seems simplest to
skip the test entirely.
Signed-off-by: Pat Thoyts <patthoyts <at> 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 the stdout of the command is connected to a terminal but the stderr
has been redirected, the odds are good that the user can't see any
question we print out to stderr. This will result in a "mysterious
hang" while the app is waiting for user input.
It seems better to be conservative, and avoid asking for input
whenever the stderr is not a terminal, just like we do for stdin.
Signed-off-by: bert Dvornik <dvornik+git@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Fix the problem where the cmd->err passed into start_command wasn't
being properly closed when certain types of errors occurr. (Compare
the affected code with the clean shutdown code later in the function.)
On Windows, this problem would be triggered if mingw_spawnvpe()
failed, which would happen if the command to be executed was malformed
(e.g. a text file that didn't start with a #! line). If cmd->err was
a pipe, the failure to close it could result in a hang while the other
side was waiting (forever) for either input or pipe close, e.g. while
trying to shove the output into the side band. On msysGit, this
problem was causing a hang in t5516-fetch-push.
I'm not sure why (or if) this problem hasn't cropped up under Linux.
The non-Windows code *does* try to check for execve() failures in the
child, in addition to the fork() failures.
Signed-off-by: bert Dvornik <dvornik+git@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
