Even though multiplication is commutative, the order of arguments
should be xcalloc(nmemb, size). ps_matched is an array of 1-byte
element whose size is the same as the number of pathspec elements.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* es/doc-clean-outdated-tools:
Documentation/git-tools: retire manually-maintained list
Documentation/git-tools: drop references to defunct tools
Documentation/git-tools: fix item text formatting
Documentation/git-tools: improve discoverability of Git wiki
Documentation/git: drop outdated Cogito reference
Running an aliased command from a subdirectory when the .git thing
in the working tree is a gitfile pointing elsewhere did not work.
* nd/export-worktree:
setup: set env $GIT_WORK_TREE when work tree is set, like $GIT_DIR
Often a fast-import stream builds a new commit on top of the
previous commit it built, and it often unconditionally emits a
"from" command to specify the first parent, which can be omitted in
such a case. This caused fast-import to forget the tree of the
previous commit and then re-read it from scratch, which was
inefficient. Optimize for this common case.
* mh/fast-import-optimize-current-from:
fast-import: do less work when given "from" matches current branch head
The "rev-parse --parseopt" mode parsed the option specification
and the argument hint in a strange way to allow '=' and other
special characters in the option name while forbidding them from
the argument hint. This made it impossible to define an option
like "--pair <key>=<value>" with "pair=key=value" specification,
which instead would have defined a "--pair=key <value>" option.
* ib/scripted-parse-opt-better-hint-string:
rev-parse --parseopt: allow [*=?!] in argument hints
A "rebase" replays changes of the local branch on top of something
else, as such they are placed in stage #3 and referred to as
"theirs", while the changes in the new base, typically a foreign
work, are placed in stage #2 and referred to as "ours". Clarify
the "checkout --ours/--theirs".
* se/doc-checkout-ours-theirs:
checkout: document subtlety around --ours/--theirs
An experimental "untracked cache" feature used uname(2) in a
slightly unportable way.
* cb/uname-in-untracked:
untracked: fix detection of uname(2) failure
"sparse checkout" misbehaved for a path that is excluded from the
checkout when switching between branches that differ at the path.
* as/sparse-checkout-removal:
unpack-trees: don't update files with CE_WT_REMOVE set
The low-level "git send-pack" did not honor 'user.signingkey'
configuration variable when sending a signed-push.
* db/send-pack-user-signingkey:
builtin/send-pack.c: respect user.signingkey
An attempt to delete a ref by pushing into a repositorywhose HEAD
symbolic reference points at an unborn branch that cannot be
created due to ref D/F conflict (e.g. refs/heads/a/b exists, HEAD
points at refs/heads/a) failed.
* jx/do-not-crash-receive-pack-wo-head:
receive-pack: crash when checking with non-exist HEAD
"git subtree" (in contrib/) depended on "git log" output to be
stable, which was a no-no. Apply a workaround to force a
particular date format.
* da/subtree-date-confusion:
contrib/subtree: ignore log.date configuration
Some Linux distributions (such as Ubuntu) have their own l10n workflows,
and their translations may be different. Add notes for this case for
l10n translators.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git only colours the output and uses pagination if isatty() returns 1.
MSys and Cygwin emulate pseudo terminals via named pipes, meaning that
isatty() returns 0.
Commit 3adef8de55 fixed this for MSys
terminals, but not Cygwin.
The named pipes that Cygwin and Msys use are very similar. MSys PTY pipes
are called 'msys-*-pty*' and Cygwin uses 'cygwin-*-pty*'. This commit
modifies the existing check to allow both MSys and Cygwin PTY pipes to be
identified as TTYs.
Note that Pagination is still broken on Cygwin. less.exe is spawned (as
seen in Process Explorer and using GIT_TRACE=1), but the output is not
being piped into it.
This partially fixes https://github.com/git-for-windows/git/issues/267
Signed-off-by: Alan Davies <alan.n.davies@gmail.com>
Windows 7 allows users to pin running applications to the task bar. By
setting the application ID, multiple processes can share a single task
bar entry, and this is exactly what we need for `git-bash.exe` which
wants to share the task bar entry with the `mintty.exe` instance it
launches.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
When updating an existing configuration file, we did not always
close the filehandle that is reading from the current configuration
file when we encountered an error (e.g. when unsetting a variable
that does not exist).
Signed-off-by: Sven Strickroth <email@cs-ware.de>
Signed-off-by: Sup Yut Sum <ch3cooli@gmail.com>
Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, a file name containing a colon is illegal. We should
therefore expect the corresponding errno when `fopen()` is called for a
path of the form <commit>:.gitattributes.
This fixes https://github.com/git-for-windows/git/issues/255.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
27e1e22d (prune: factor out loose-object directory traversal, 2014-10-16)
introduced a new function for_each_loose_file_in_objdir() with a helper
for_each_file_in_obj_subdir(). The latter calls callbacks for each file
found during a directory traversal and finally also a callback for the
directory itself.
git-prune uses the function to clean up the object directory. In
particular, in the directory callback it calls rmdir(). On Windows XP,
this rmdir call fails, because the directory is still open while the
callback is called. Close the directory before calling the callback.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In read_sha1_file_extended we die if read_object fails with a fatal
error. We detect a fatal error if errno is non-zero and is not
ENOENT. If the object could not be read because it does not exist,
this is not considered a fatal error and we want to return NULL.
Somewhere down the line, read_object calls git_open_noatime to open
a pack index file, for example. We first try open with O_NOATIME.
If O_NOATIME fails with EPERM, we retry without O_NOATIME. When the
second open succeeds, errno is however still set to EPERM from the
first attempt. When we finally determine that the object does not
exist, read_object returns NULL and read_sha1_file_extended dies
with a fatal error:
fatal: failed to read object <sha1>: Operation not permitted
Fix this by resetting errno to zero before we call open again.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Clemens Buchacher <clemens.buchacher@intel.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also mark the Git executable as compatible with Windows Vista or later
(at the time of writing, the latest version is Windows 10) because
otherwise the manifest would be ignored on Windows 8.1 or later.
This fixes https://github.com/git-for-windows/git/issues/258.
In Git for Windows 2.x' context, we technically do not need to embed the
<compatibility> section ourselves because MSys2's
mingw-w64-<arch>-windows-default-manifest package already contains it,
starting with version 6.4-2 (release on or after July 10th, 2015).
However, not all Git developers use MSys2 on Windows (doubtlessly in an
attempt to make the life of Git for Windows' maintainer harder than
necessary), therefore we still need to add that section explicitly.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
A test case introduced by ae454f61 (Add tests for wildcard "path vs ref"
disambiguation) allocates a file named '*.c'. This does not work on
Windows, because the OS forbids file names containing wildcard
characters. The test case fails where the shell attempts to allocate the
file. Skip the test on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we call "die(fmt, args...)", we end up in vreportf with
two pieces of information:
1. The prefix "fatal: "
2. The original fmt and va_list of args.
We format item (2) into a temporary buffer, and then fprintf
the prefix and the temporary buffer, along with a newline.
This has the unfortunate side effect of truncating any error
messages that are longer than 4096 bytes.
Instead, let's use separate calls for the prefix and
newline, letting us hand the item (2) directly to vfprintf.
This is essentially undoing d048a96 (print
warning/error/fatal messages in one shot, 2007-11-09), which
tried to have the whole output end up in a single `write`
call.
But we can address this instead by explicitly requesting
line-buffering for the output handle, and by making sure
that the buffer is empty before we start (so that outputting
the prefix does not cause a flush due to hitting the buffer
limit).
We may still break the output into two writes if the content
is larger than our buffer, but there's not much we can do
there; depending on the stdio implementation, that might
have happened even with a single fprintf call.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The vreportf function always goes to stderr, but run-command
wants child errors to go to the parent's original stderr. To
solve this, commit a5487dd duplicates the stderr fd and
installs die and error handlers to direct the output
appropriately (which later turned into the vwritef
function). This has two downsides, though:
- we make multiple calls to write(), which contradicts the
"write at once" logic from d048a96 (print
warning/error/fatal messages in one shot, 2007-11-09).
- the custom handlers basically duplicate the normal
handlers. They're only a few lines of code, but we
should not have to repeat the magic "exit(128)", for
example.
We can solve the first by using fdopen() on the duplicated
descriptor. We can't pass this to vreportf, but we could
introduce a new vreportf_to to handle it.
However, to fix the second problem, we instead introduce a
new "set_error_handle" function, which lets the normal
vreportf calls output to a handle besides stderr. Thus we
can get rid of our custom handlers entirely, and just ask
the regular handlers to output to our new descriptor.
And as vwritef has no more callers, it can just go away.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The loop in strbuf_read() uses xread() repeatedly while extending
the strbuf until the call returns zero. If the buffer is
sufficiently large to begin with, this results in xread()
returning the remainder of the file to the end (returning
non-zero), the loop extending the strbuf, and then making another
call to xread() to have it return zero.
By using read_in_full(), we can tell when the read reached the end
of file: when it returns less than was requested, it's eof. This
way we can avoid an extra iteration that allocates an extra 8kB
that is never used.
Signed-off-by: Jim Hill <gjthill@gmail.com>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 7e837c6 (clone: simplify string handling in
guess_dir_name(), 2015-07-09) changed clone to use
strip_suffix instead of hand-rolled pointer manipulation.
However, strip_suffix will strip from the end of a
NUL-terminated string, and we may have already stripped some
characters (like directory separators, or "/.git"). This
leads to commands like:
git clone host:foo.git/
failing to strip the ".git".
We must instead convert our pointer arithmetic into a
computed length and feed that to strip_suffix_mem, which will
then reduce the length further for us.
It would be nicer if we could drop the pointer manipulation
entirely, and just continually strip using strip_suffix. But
that doesn't quite work for two reasons:
1. The early suffixes we're stripping are not constant; we
need to look for is_dir_sep, which could be one of
several characters.
2. Mid-way through the stripping we compute the pointer
"start", which shows us the beginning of the pathname.
Which really give us two lengths to work with: the
offset from the start of the string, and from the start
of the path. By using pointers for the early part, we
can just compute the length from "start" when we need
it.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we run "git clone $url", clone guesses from the $url
what to name the local output directory. We don't have any
test coverage of this, so let's add some basic tests.
This reveals a few problems:
- cloning "foo.git/" does not properly remove the ".git";
this is a recent regression from 7e837c6 (clone:
simplify string handling in guess_dir_name(), 2015-07-09)
- likewise, cloning foo/.git does not seem to handle the
bare case (we should end up in foo.git, but we try to
use foo/.git on the local end), which also comes from
7e837c6.
- cloning the root is not very smart about URL parsing,
and usernames and port numbers may end up in the
directory name
All of these tests are marked as failures.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "-x" test-script option turns on the shell's "-x"
tracing, which can help show why a particular test is
failing. Unfortunately, this can create false negatives in
some tests if they invoke a shell function with its stderr
redirected. t5512.10 is such a test, as it does:
test_must_fail git ls-remote refs*master >actual 2>&1 &&
test_cmp exp actual
The "actual" file gets the "-x" trace for the test_must_fail
function, which prevents it from matching the expected
output.
There's no way to avoid this without managing the
trace flag inside each sub-function, which isn't really a
workable solution. But unless you specifically care about
t5512.10, we can work around it by enabling tracing only for
the specific tests we want.
You can already do:
./t5512-ls-remote.sh -x --verbose-only=16
to see the trace only for a specific test. But that doesn't
_disable_ the tracing in the other tests; it just sends it
to /dev/null. However, there's no point in generating a
trace that the user won't see, so we can simply disable
tracing whenever it doesn't have a matching verbose flag.
The normal case of just "./t5512-ls-remote.sh -x" stays the
same, as "-x" already implies "--verbose" (and
"--verbose-only" overrides "--verbose", which is why this
works at all). And for our test, we need only check
$verbose, as maybe_setup_verbose will have already
set that flag based on the $verbose_only list).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that GIT_TEST_CHAIN_LINT is on by default, running:
./t0000-basic.sh -x --verbose-only=1
starts with:
expecting success:
find .git/objects -type f -print >should-be-empty &&
test_line_count = 0 should-be-empty
+ exit 117
error: last command exited with $?=117
+ find .git/objects -type f -print
+ test_line_count = 0 should-be-empty
+ test 3 != 3
+ wc -l
+ test 0 = 0
ok 1 - .git/objects should be empty after git init in an empty repo
This is confusing, as the "exit 117" line and the error line
(which is printed in red, no less!) are not part of the test
at all, but are rather in the separate chain-lint test_eval.
Let's unset the "trace" variable when eval-ing the chain
lint check, which avoids this.
Note that we cannot just do a one-shot variable like:
trace= test_eval ...
as the behavior of one-shot variables for function calls
is not portable.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
During cleanup we do a simple 'rm /*' to remove leftover files
from previous tests. As 'rm' errors out when there is anything it
cannot delete and there are directories present at '/' it will
throw an error, causing the '&&' chain to fail.
Fix this by explicitly removing the files.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We check the return value of read_ref in 19 out of 21 cases.
This adds checks to the missing cases.
Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Abandoning an already applied change in "git rebase -i" with
"--continue" left CHERRY_PICK_HEAD and confused later steps.
* js/rebase-i-clean-up-upon-continue-to-skip:
rebase -i: do not leave a CHERRY_PICK_HEAD file behind
t3404: demonstrate CHERRY_PICK_HEAD bug
Various fixes around "git am" that applies a patch to a history
that is not there yet.
* pt/am-abort-fix:
am --abort: keep unrelated commits on unborn branch
am --abort: support aborting to unborn branch
am --abort: revert changes introduced by failed 3way merge
am --skip: support skipping while on unborn branch
am -3: support 3way merge on unborn branch
am --skip: revert changes introduced by failed 3way merge
"git for-each-ref" reported "missing object" for 0{40} when it
encounters a broken ref. The lack of object whose name is 0{40} is
not the problem; the ref being broken is.
* mh/reporting-broken-refs-from-for-each-ref:
read_loose_refs(): treat NULL_SHA1 loose references as broken
read_loose_refs(): simplify function logic
for-each-ref: report broken references correctly
t6301: new tests of for-each-ref error handling
"git commit --cleanup=scissors" was not careful enough to protect
against getting fooled by a line that looked like scissors.
* sg/commit-cleanup-scissors:
commit: cope with scissors lines in commit message
