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>
This test assumed that there are no two equivalent directory separators.
However, on Windows, the back slash and the forward slash *are*
equivalent. Let's paper over this issue by converting the backward
slashes to forward ones in the test that fails with MSys2 otherwise.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There is a really useful debugging technique developed by Sverre
Rabbelier that inserts "bash &&" somewhere in the test scripts, letting
the developer interact at given points with the current state.
Another debugging technique, used a lot by this here coder, is to run
certain executables via gdb by guarding a "gdb -args" call in
bin-wrappers/git.
Both techniques were disabled by 781f76b1(test-lib: redirect stdin of
tests).
Let's reinstate the ability to run an interactive shell by making the
redirection optional: setting the TEST_NO_REDIRECT environment variable
will skip the redirection.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This test is susceptible to MSys2's posix-to-windows path mangling; Let's
just use POSIX paths throughout and let the tests pass.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With MSys2, there is actually an implementation of mkfifo available. The
only problem is that it is only emulating named pipes through the MSys2
runtime; The Win32 API has no idea about named pipes, hence the Git
executable cannot access those pipes either.
The symptom is that Git fails with a '<name>: No such file or directory'
because MSys2 emulates named pipes through special-crafted '.lnk' files.
The solution is to tell the test suite explicitly that we cannot use
named pipes when we want to test a MinGW Git.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
MSys2 actually allows to create files or directories whose names contain
tabs, newlines or colors, even if plain Win32 API cannot access them.
As we are using an MSys2 bash to run the tests, such files or
directories are created successfully, but Git has no chance to work with
them because it is a regular Windows program, hence limited by the Win32
API.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The CVS tests expect `pwd` to return a POSIX-style directory. Let's skip
our MinGW-specific override to let `pwd` output a Windows-style directory
for that reason.
Helped-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: 마누엘 <nalla@hamal.uberspace.de>
There are some issues with the git-svn test cases when they are
being run on windows under a MINGW build. Some things are not
available like the changing of the execute flag of shell scripts
via the chmod command. Also there were problems with folder names
that end with a dot on windows.
Signed-off-by: 마누엘 <nalla@users.noreply.github.com>
As per https://msdn.microsoft.com/en-us/library/x99tb11d.aspx:
The set of available locale names, languages, country/region
codes, and code pages includes all those supported by the Windows
NLS API except code pages that require more than two bytes per
character, such as UTF-7 and UTF-8.
Therefore, MinGW gettext cannot cope with UTF-8 at all, because it uses
the Win32 API internally.
However, when the test asks `locale -a` it reports that is_US.utf8 is
available, because that `locale` is actually an *MSys2* program (and MSys2
can cope with UTF-8 alright).
Let's just skip this test for MinGW Git altogether.
Helped-by: 마누엘 <nalla@users.noreply.github.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
There is a MinGW gettext.exe, but still no MinGW locale.exe. Instead the
MSys2 locale.exe kicks in, which corresponds to the MSys2 gettext.exe,
however. Therefore some assumptions of t0200 cannot be fulfilled when
running inside MSys2.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
t0027 is marked expensive, but really, for MinGW we want to run these
tests always.
Suggested by Thomas Braun.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
A string of the form "@/abcd" is considered a file path
by the msys layer and therefore translated to a windows path.
Here the trick is to double the slashes.
The msys patch translation can be studied with the following
test program:
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char** argv)
{
unsigned int i;
for(i=1; i < argc; i++)
printf("argv[%d]=%s\n",i, argv[i]);
exit(0);
}
Signed-off-by: Thomas Braun <thomas.braun@byte-physics.de>
MSys works very hard to convert Unix-style paths into DOS-style ones.
*Very* hard.
So hard, indeed, that
git blame -L/hello/,/green/
is translated into something like
git blame -LC:/msysgit/hello/,C:/msysgit/green/
As seen in msys_p2w in src\msys\msys\rt\src\winsup\cygwin\path.cc, line
3204ff:
case '-':
//
// here we check for POSIX paths as attributes to a POSIX switch.
//
...
seemingly absolute POSIX paths in single-letter options get expanded by
msys.dll unless they contain '=' or ';'.
So a quick and very dirty fix is to use '-L/;*evil/'. (Using an equal sign
works only when it is before a comma, so in the above example, /=*green/
would still be converted to a DOS-style path.)
Commit-message-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The test separator char is a colon which means any absolute paths on windows
confuse the tests that use global_excludes.
Suggested-by: Karsten Blees <karsten.blees@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Apparently the signal handling is not quite correct in the fsckobject
handling (most likely we rely on a side effect that lets us still output
some message after receiving a signal 13 but in the BuildHive setup this
fails intermittently).
As a consequence, the push in t5504 does fail as expected, but fails to
output anything (unexpected). Since this is good enough for now, let's
handle an empty output as success, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This happens only when the corresponding commits are not exported in
the current fast-export run. This can happen either when the relevant
commit is already marked, or when the commit is explicitly marked
as UNINTERESTING with a negative ref by another argument.
This breaks fast-export basec remote helpers.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Windows paths are typically limited to MAX_PATH = 260 characters, even
though the underlying NTFS file system supports paths up to 32,767 chars.
This limitation is also evident in Windows Explorer, cmd.exe and many
other applications (including IDEs).
Particularly annoying is that most Windows APIs return bogus error codes
if a relative path only barely exceeds MAX_PATH in conjunction with the
current directory, e.g. ERROR_PATH_NOT_FOUND / ENOENT instead of the
infinitely more helpful ERROR_FILENAME_EXCED_RANGE / ENAMETOOLONG.
Many Windows wide char APIs support longer than MAX_PATH paths through the
file namespace prefix ('\\?\' or '\\?\UNC\') followed by an absolute path.
Notable exceptions include functions dealing with executables and the
current directory (CreateProcess, LoadLibrary, Get/SetCurrentDirectory) as
well as the entire shell API (ShellExecute, SHGetSpecialFolderPath...).
Introduce a handle_long_path function to check the length of a specified
path properly (and fail with ENAMETOOLONG), and to optionally expand long
paths using the '\\?\' file namespace prefix. Short paths will not be
modified, so we don't need to worry about device names (NUL, CON, AUX).
Contrary to MSDN docs, the GetFullPathNameW function doesn't seem to be
limited to MAX_PATH (at least not on Win7), so we can use it to do the
heavy lifting of the conversion (translate '/' to '\', eliminate '.' and
'..', and make an absolute path).
Add long path error checking to xutftowcs_path for APIs with hard MAX_PATH
limit.
Add a new MAX_LONG_PATH constant and xutftowcs_long_path function for APIs
that support long paths.
While improved error checking is always active, long paths support must be
explicitly enabled via 'core.longpaths' option. This is to prevent end
users to shoot themselves in the foot by checking out files that Windows
Explorer, cmd/bash or their favorite IDE cannot handle.
Test suite:
Test the case is when the full pathname length of a dir is close
to 260 (MAX_PATH).
Bug report and an original reproducer by Andrey Rogozhnikov:
https://github.com/msysgit/git/pull/122#issuecomment-43604199
[jes: adjusted test number to avoid conflicts, reinstated && chain]
Thanks-to: Martin W. Kirst <maki@bitkings.de>
Thanks-to: Doug Kelly <dougk.ff7@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Original-test-by: Andrey Rogozhnikov <rogozhnikov.andrey@gmail.com>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Windows paths are typically limited to MAX_PATH = 260 characters, even
though the underlying NTFS file system supports paths up to 32,767 chars.
This limitation is also evident in Windows Explorer, cmd.exe and many
other applications (including IDEs).
Particularly annoying is that most Windows APIs return bogus error codes
if a relative path only barely exceeds MAX_PATH in conjunction with the
current directory, e.g. ERROR_PATH_NOT_FOUND / ENOENT instead of the
infinitely more helpful ERROR_FILENAME_EXCED_RANGE / ENAMETOOLONG.
Many Windows wide char APIs support longer than MAX_PATH paths through the
file namespace prefix ('\\?\' or '\\?\UNC\') followed by an absolute path.
Notable exceptions include functions dealing with executables and the
current directory (CreateProcess, LoadLibrary, Get/SetCurrentDirectory) as
well as the entire shell API (ShellExecute, SHGetSpecialFolderPath...).
Introduce a handle_long_path function to check the length of a specified
path properly (and fail with ENAMETOOLONG), and to optionally expand long
paths using the '\\?\' file namespace prefix. Short paths will not be
modified, so we don't need to worry about device names (NUL, CON, AUX).
Contrary to MSDN docs, the GetFullPathNameW function doesn't seem to be
limited to MAX_PATH (at least not on Win7), so we can use it to do the
heavy lifting of the conversion (translate '/' to '\', eliminate '.' and
'..', and make an absolute path).
Add long path error checking to xutftowcs_path for APIs with hard MAX_PATH
limit.
Add a new MAX_LONG_PATH constant and xutftowcs_long_path function for APIs
that support long paths.
While improved error checking is always active, long paths support must be
explicitly enabled via 'core.longpaths' option. This is to prevent end
users to shoot themselves in the foot by checking out files that Windows
Explorer, cmd/bash or their favorite IDE cannot handle.
Test suite:
Test the case is when the full pathname length of a dir is close
to 260 (MAX_PATH).
Bug report and an original reproducer by Andrey Rogozhnikov:
https://github.com/msysgit/git/pull/122#issuecomment-43604199
[jes: adjusted test number to avoid conflicts]
Thanks-to: Martin W. Kirst <maki@bitkings.de>
Thanks-to: Doug Kelly <dougk.ff7@gmail.com>
Signed-off-by: Karsten Blees <blees@dcon.de>
Original-test-by: Andrey Rogozhnikov <rogozhnikov.andrey@gmail.com>
Signed-off-by: Stepan Kasal <kasal@ucw.cz>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
[jes: adusted test number to avoid conflicts, fixed non-portable use of
the 'export' statement]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
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>
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>
Produce correct "dirty" marker for shell prompts, even when we
are on an orphan or an unborn branch.
* sg/bash-prompt-dirty-orphan:
bash prompt: indicate dirty index even on orphan branches
bash prompt: remove a redundant 'git diff' option
bash prompt: test dirty index and worktree while on an orphan branch
There was no way to defeat a configured rebase.autostash variable
from the command line, as "git rebase --no-autostash" was missing.
* jk/rebase-no-autostash:
Documentation/git-rebase: fix --no-autostash formatting
rebase: support --no-autostash
The code to prepare the working tree side of temporary directory
for the "dir-diff" feature forgot that symbolic links need not be
copied (or symlinked) to the temporary area, as the code already
special cases and overwrites them. Besides, it was wrong to try
computing the object name of the target of symbolic link, which may
not even exist or may be a directory.
* da/difftool:
difftool: ignore symbolic links in use_wt_file
Having a leftover .idx file without corresponding .pack file in
the repository hurts performance; "git gc" learned to prune them.
We may want to do the same for .bitmap (and notice but not prune
.keep) without corresponding .pack, but that can be a separate
topic.
* dk/gc-idx-wo-pack:
gc: remove garbage .idx files from pack dir
t5304: test cleaning pack garbage
prepare_packed_git(): refactor garbage reporting in pack directory
Just like the working tree is cleaned up when the user cancelled
submission in P4Submit.applyCommit(), clean up the mess if "p4
submit" fails.
* eg/p4-submit-catch-failure:
git-p4: clean up after p4 submit failure
Make git-p4 work on a detached head.
* ld/p4-detached-head:
git-p4: work with a detached head
git-p4: add option to system() to return subshell status
git-p4: add failing test for submit from detached head
'git filter-branch' fails complaining about an ambiguous argument, if
a tree-filter renames a path and the new pathname happens to match an
existing object name.
After the tree-filter has been applied, 'git filter-branch' looks for
changed paths by running:
git diff-index -r --name-only --ignore-submodules $commit
which then, because of the lack of disambiguating double-dash, can't
decide whether to treat '$commit' as revision or path and errors out.
Add that disambiguating double-dash after 'git diff-index's revision
argument to make sure that '$commit' is interpreted as a revision.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Jeff King <peff@peff.net>
When "p4 submit" command fails in P4Submit.applyCommit, the
workspace is left with the changes. We already have code to revert
the changes to the workspace when the user decides to cancel
submission by aborting the editor that edits the change description,
and we should treat the "p4 submit" failure the same way.
Clean the workspace if p4_write_pipe raised SystemExit, so that the
user don't have to do it themselves.
Signed-off-by: GIRARD Etienne <egirard@murex.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Jeff King <peff@peff.net>
__git_ps1() doesn't indicate dirty index while on an orphan branch.
To check the dirtiness of the index, __git_ps1() runs 'git diff-index
--cached ... HEAD', which doesn't work on an orphan branch,
because HEAD doesn't point to a valid commit.
Run 'git diff ... --cached' instead, as it does the right thing both
on valid and invalid HEAD, i.e. compares the index to the existing
HEAD in the former case and to the empty tree in the latter. This
fixes the two failing tests added in the first commit of this series.
The dirtiness of the worktree is already checked with 'git diff' and
is displayed correctly even on an orphan branch.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Jeff King <peff@peff.net>
There is only a single test exercising the dirty state indicator on an
orphan branch, and in that test neither the index nor the worktree are
dirty.
Add two failing tests to check the dirty state indicator while either
the index is dirty or while both the index and the worktree are dirty
on an orphan branch, and to show that the dirtiness of the index is
not displayed in these cases (the fourth combination, i.e. clean index
and dirty worktree are impossible on an orphan branch). Update the
existing dirty state indicator on clean orphan branch test to match
the style of the two new tests, most importantly to use 'git checkout
--orphan' instead of cd-ing into a repository that just happens to be
empty and clean.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Jeff King <peff@peff.net>
When submitting, git-p4 finds the current branch in
order to know if it is allowed to submit (configuration
"git-p4.allowSubmit").
On a detached head, detecting the branch would fail, and
git-p4 would report a cryptic error.
This change teaches git-p4 to recognise a detached head and
submit successfully.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Jeff King <peff@peff.net>
git-p4 can't submit from a detached head. This test case
demonstrates the problem.
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Jeff King <peff@peff.net>
When passed an ssh:// url, git strips ssh://host from the url but does
not remove leading slashes from the path. So when this test used
ssh://remote//path/to/pwd, the path accessed by our fake SSH is
//path/to/pwd, which cygwin interprets as a UNC path, causing the test
to fail.
We may want to actually fix this in git itself, making it remove extra
slashes from urls before feeding them to transports or helpers, but
that's for another topic as it could cause regressions.
Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net>
Signed-off-by: Jeff King <peff@peff.net>
Since ec7dbd145 (receive-pack: allow hooks to ignore its
standard input stream) the pre-receive and post-receive
hooks ignore SIGPIPE. Do the same for the remaining hooks
pre-push and post-rewrite, which read from standard input.
The same arguments for ignoring SIGPIPE apply.
Include test by Jeff King which checks that SIGPIPE does not
cause pre-push hook failure. With the use of git update-ref
--stdin it is fast enough to be enabled by default.
Signed-off-by: Clemens Buchacher <clemens.buchacher@intel.com>
Signed-off-by: Jeff King <peff@peff.net>
"git status --branch --short" accessed beyond the constant string
"HEAD", which has been corrected.
* rs/wt-status-detached-branch-fix:
wt-status: use skip_prefix() to get rid of magic string length constants
wt-status: don't skip a magical number of characters blindly
wt-status: avoid building bogus branch name with detached HEAD
wt-status: exit early using goto in wt_shortstatus_print_tracking()
t7060: add test for status --branch on a detached HEAD
