We read loose references in two steps. The code is roughly:
lstat()
if error ENOENT:
loose ref is missing; look for corresponding packed ref
else if S_ISLNK:
readlink()
if error:
report failure
else if S_ISDIR:
report failure
else
open()
if error:
report failure
read()
The problem is that the first filesystem call, to lstat(), is not
atomic with the second filesystem call, to readlink() or open().
Therefore it is possible for another process to change the file
between our two calls, for example:
* If the other process deletes the file, our second call will fail
with ENOENT, which we *should* interpret as "loose ref is missing;
look for corresponding packed ref". This can arise if the other
process is pack-refs; it might have just written a new packed-refs
file containing the old contents of the reference then deleted the
loose ref.
* If the other process changes a symlink into a plain file, our call
to readlink() will fail with EINVAL, which we *should* respond to by
trying to open() and read() the file.
The old code treats the reference as missing in both of these cases,
which is incorrect.
So instead, handle errors more selectively: if the result of
readline()/open() is a failure that is inconsistent with the result of
the previous lstat(), then something is fishy. In this case jump back
and start over again with a fresh call to lstat().
One race is still possible and undetected: another process could
change the file from a regular file into a symlink between the call to
lstat and the call to open(). The open() call would silently follow
the symlink and not know that something is wrong. This situation
could be detected in two ways:
* On systems that support O_NOFOLLOW, pass that option to the open().
* On other systems, call fstat() on the fd returned by open() and make
sure that it agrees with the stat info from the original lstat().
However, we don't use symlinks anymore, so this situation is unlikely.
Moreover, it doesn't appear that treating a symlink as a regular file
would have grave consequences; after all, this is exactly how the code
handles non-relative symlinks. So this commit leaves that race
unaddressed.
Note that this solves only the part of the race within
resolve_ref_unsafe. In the situation described above, we may still be
depending on a cached view of the packed-refs file; that race will be
dealt with in a future patch.
This problem was reported and diagnosed by Jeff King <peff@peff.net>,
and this solution is derived from his patch.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is only one "break" statement within the loop, which jumps to
the code after the loop that handles the case of a file that holds a
SHA-1. So move that code from below the loop into the if statement
where the break was previously located. This makes the logic flow
more local.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The nesting was getting a bit out of hand, and it's about to get
worse.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the SANITY prerequisite when testing if a temp file can
be created in a read only directory.
Skip the test under CYGWIN, or skip it under Unix/Linux when
it is run as root.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"gitweb" forgot to clear a global variable $search_regexp upon each
request, mistakenly carrying over the previous search to a new one
when used as a persistent CGI.
* cm/gitweb-project-list-persistent-cgi-fix:
gitweb: fix problem causing erroneous project list
* rr/rebase-autostash:
rebase: implement --[no-]autostash and rebase.autostash
rebase --merge: return control to caller, for housekeeping
rebase -i: return control to caller, for housekeeping
am: return control to caller, for housekeeping
rebase: prepare to do generic housekeeping
rebase -i: don't error out if $state_dir already exists
am: tighten a conditional that checks for $dotest
"git cmd <name>", when <name> happens to be a 40-hex string,
directly uses the 40-hex string as an object name, even if a ref
"refs/<some hierarchy>/<name>" exists. This disambiguation order
is unlikely to change, but we should warn about the ambiguity just
like we warn when more than one refs/ hierachies share the same
name.
* nd/warn-ambiguous-object-name:
get_sha1: warn about full or short object names that look like refs
Update the low-level diffcore documentation on -S/-G and --pickaxe-all.
* rr/diffcore-pickaxe-doc:
diffcore-pickaxe doc: document -S and -G properly
diffcore-pickaxe: make error messages more consistent
These days, "git --work-tree=there cmd" without specifying an
explicit --git-dir=here will do the usual discovery, but we had a
description of older behaviour in the documentation.
* cr/git-work-tree-sans-git-dir:
git.txt: remove stale comment regarding GIT_WORK_TREE
Hint users when https:// connection failed to check the certificate.
* mm/mediawiki-https-fail-message:
git-remote-mediawiki: better error message when HTTP(S) access fails
* fc/remote-bzr:
remote-bzr: add fallback check for a partial clone
remote-bzr: reorganize the way 'wanted' works
remote-bzr: trivial cleanups
remote-bzr: change global repo
remote-bzr: delay cloning/pulling
remote-bzr: simplify get_remote_branch()
remote-bzr: fix for files with spaces
remote-bzr: recover from failed clones
Update build for Cygwin 1.[57]. Torsten Bögershausen reports that
this is fine with Cygwin 1.7 ($gmane/225824) so let's try moving it
ahead.
* rj/mingw-cygwin:
cygwin: Remove the CYGWIN_V15_WIN32API build variable
mingw: rename WIN32 cpp macro to GIT_WINDOWS_NATIVE
* rs/unpack-trees-plug-leak:
unpack-trees: free cache_entry array members for merges
diff-lib, read-tree, unpack-trees: mark cache_entry array paramters const
diff-lib, read-tree, unpack-trees: mark cache_entry pointers const
unpack-trees: create working copy of merge entry in merged_entry
unpack-trees: factor out dup_entry
read-cache: mark cache_entry pointers const
cache: mark cache_entry pointers const
When a reflog notation is used for implicit "current branch", we
did not say which branch and worse said "branch ''".
* rr/die-on-missing-upstream:
sha1_name: fix error message for @{<N>}, @{<date>}
sha1_name: fix error message for @{u}
githooks(5) says that "[...]the .sample files are executable by default"
which was not true.
Signed-off-by: Wieland Hoffmann <themineo@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Primarily to push out two regression issues that seem to affect many
people, namely, the ".gitignore !directory" bug and "daemon cannot
read from $HOME owned by root" bug.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Returning the SIGALRM handler for SIGINT is not very useful.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A git daemon that starts as "root" and then drops privilege often
leaves $HOME set to that of the root user, which is unreadable by
the daemon process, which was diagnosed as a configuration error.
Make per-user configuration files that are inaccessible due to
EACCES as though these files do not exist to avoid this issue, as
the tightening which was originally meant as an additional security
has annoyed enough sysadmins.
* jn/config-ignore-inaccessible:
config: allow inaccessible configuration under $HOME
Fix recent regression of .gitignore files that list !directory to
mark it not-ignored.
* kb/status-ignored-optim-2:
dir.c: fix ignore processing within not-ignored directories
read_cache already performs the same check and returns immediately if
the cache has already been loaded.
Signed-off-by: René Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A note in the beginning of this document describes the behavior already.
This patch just adds where to find the repositories.
Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The bug is manifest when running gitweb in a persistent process (e.g.
FastCGI, PSGI), and it's easy to reproduce. If a gitweb request
includes the searchtext parameter (i.e. s), subsequent requests using
the project_list action--which is the default action--and without
a searchtext parameter will be filtered by the searchtext value of the
first request. This is because the value of the $search_regexp global
(the value of which is based on the searchtext parameter) is currently
being persisted between requests.
Instead, clear $search_regexp before dispatching each request.
Signed-off-by: Charles McGarvey <chazmcgarvey@brokenzipper.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When explaining the "--tags" option as an equivalent to giving an
explicit "refs/tags/*:refs/tags/*" refspec, the two asterisks were
misinterpreted by AsciiDoc as a request to typeset the string
segment between them in bold.
We could fix it in two ways. We can replace them with {asterisk}s
while keeping the string as body text, or we can mark it as a
literal string with backquotes around it.
Let's do the latter, as it is teaching the user an "exactly as
typed" alternative.
Noticed-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This set of patches collects a number of build fixes that have been
used on the msysgit port for a while and merging upstream should
simplify future maintenance.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQCVAwUAUbEmnGB90JXwhOSJAQKRJgP/TdWucLnedP4tRKhRrwy3AnZ2Her4Mn5n
isrNQu3eixT3PsGzdyYUvTYLP8OPNfgYYVEzqyrRtNHKKSD2qLGXt8oyOw63z10n
tiDcHHCfI1U/W7GHK1Q9abaQz/PF6yWnYenRt9lnckyqtxNoa8o+eOCfuY9lBfNJ
ccTP/dRgoL0=
=uWg2
-----END PGP SIGNATURE-----
Merge tag 'post183-for-junio' of http://github.com/msysgit/git
Collected msysgit build patches for upstream
This set of patches collects a number of build fixes that have been
used on the msysgit port for a while and merging upstream should
simplify future maintenance.
* tag 'post183-for-junio' of http://github.com/msysgit/git:
Set the default help format to html for msys builds.
Ensure the resource file is rebuilt when the version changes.
Windows resource: handle dashes in the Git version gracefully
Provide a Windows version resource for the git executables.
msysgit: Add the --large-address-aware linker directive to the makefile.
Define NO_GETTEXT for Git for Windows
Makefile: Do not use OLD_ICONV on MINGW anymore
"git push $there HEAD:branch" did not resolve HEAD early enough, so
it was easy to flip it around while push is still going on and push
out a branch that the user did not originally intended when the
command was started.
* rr/push-head:
push: make push.default = current use resolved HEAD
push: fail early with detached HEAD and current
push: factor out the detached HEAD error message
"difftool --dir-diff" did not copy back changes made by the
end-user in the diff tool backend to the working tree in some
cases.
* ks/difftool-dir-diff-copy-fix:
difftool --dir-diff: allow changing any clean working tree file
The bash prompt code (in contrib/) displayed the name of the branch
being rebased when "rebase -i/-m/-p" modes are in use, but not the
plain vanilla "rebase".
* fc/show-branch-in-rebase-am:
prompt: fix for simple rebase
Special case "git clone" and use lighter-weight implementation to
check the completeness of the history behind refs.
* nd/clone-connectivity-shortcut:
clone: open a shortcut for connectivity check
index-pack: remove dead code (it should never happen)
fetch-pack: prepare updated shallow file before fetching the pack
clone: let the user know when check_everything_connected is run
With "export" remote-helper protocol,
(1) a push that tries to update a remote ref whose name is
different from the pushing side does not work yet, and
(2) the helper may not know how to do --dry-run
Detect such problematic cases and disable them for now.
* fc/transport-helper-no-refspec:
transport-helper: check if the dry-run is supported
transport-helper: barf when user tries old:new
The test case depends on that test-sigchain can commit suicide by a
call to raise(SIGTERM) in a way that run-command.c::wait_or_whine()
can detect as death through a signal. There are no POSIX signals on
Windows, and a sufficiently close emulation is not available in the
Microsoft C runtime (and probably not even possible).
The particular deficiency is that when a signal is raise()d whose
SIG_DFL action will cause process death (SIGTERM in this case), the
implementation of raise() in msvcrt just calls exit(3).
We could check for exit code 3 in addition to 143, but that would
miss the point of the test entirely. Hence, just skip it on Windows.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
