We currently read the preimage to apply a patch from the index only
when the --cached option is given. Do so also when the command is
running under the --index option. With --index, the index entry and
the working tree file for a path that is involved in a patch must be
identical, so this should not affect the result, but by reading from
the index, we will get the protection to avoid reading an unintended
path beyond a symbolic link automatically.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, a patch that affects outside the working area (either a
Git controlled working tree, or the current working directory when
"git apply" is used as a replacement of GNU patch) is rejected as a
mistake (or a mischief). Git itself does not create such a patch,
unless the user bends over backwards and specifies a non-standard
prefix to "git diff" and friends.
When `git apply` is used as a "better GNU patch", the user can pass
the `--unsafe-paths` option to override this safety check. This
option has no effect when `--index` or `--cached` is in use.
The new test was stolen from Jeff King with slight enhancements.
Note that a few new tests for touching outside the working area by
following a symbolic link are still expected to fail at this step,
but will be fixed in later steps.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an import has finished, we run end_packfile() to
finalize the data and move the packfile into place. If this
process fails, we call die() and end up in our die_nicely()
handler. Which unfortunately includes running end_packfile
to save any progress we made. We enter the function again,
and start operating on the pack_data struct while it is in
an inconsistent state, leading to a segfault.
One way to trigger this is to simply start two identical
fast-imports at the same time. They will both create the
same packfiles, which will then try to create identically
named ".keep" files. One will win the race, and the other
will die(), and end up with the segfault.
Since 3c078b9, we already reset the pack_data pointer to
NULL at the end of end_packfile. That covers the case of us
calling die() right after end_packfile, before we have
reinitialized the pack_data pointer. This new problem is
quite similar, except that we are worried about calling
die() _during_ end_packfile, not right after. Ideally we
would simply set pack_data to NULL as soon as we enter the
function, and operate on a copy of the pointer.
Unfortunately, it is not so easy. pack_data is a global, and
end_packfile calls into other functions which operate on the
global directly. We would have to teach each of these to
take an argument, and there is no guarantee that we would
catch all of the spots.
Instead, we can simply use a static flag to avoid
recursively entering the function. This is a little less
elegant, but it's short and fool-proof.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since ea02ffa3 (mailmap: simplify map_user() interface, 2013-01-05),
find_alignment() has been invoking commit_info_destroy() on an
uninitialized auto 'struct commit_info' (when METAINFO_SHOWN is not
set). commit_info_destroy() calls strbuf_release() for each
'commit_info' strbuf member, which randomly invokes free() on
whatever random stack value happens to reside in strbuf.buf, thus
leading to periodic crashes.
Reported-by: Dilyan Palauzov <dilyan.palauzov@aegee.org>
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The string in 'base' contains a path suffix to a specific object;
when its value is used, the suffix must either be filled (as in
stat_sha1_file, open_sha1_file, check_and_freshen_nonlocal) or
cleared (as in prepare_packed_git) to avoid junk at the end.
660c889e (sha1_file: add for_each iterators for loose and packed
objects, 2014-10-15) introduced loose_from_alt_odb(), but this did
neither and treated 'base' as a complete path to the "base" object
directory, instead of a pointer to the "base" of the full path
string.
The trailing path after 'base' is still initialized to NUL, hiding
the bug in some common cases. Additionally the descendent
for_each_file_in_obj_subdir() function swallows ENOENT, so an error
only shows if the alternate's path was last filled with a valid
object (where statting /path/to/existing/00/0bjectfile/00 fails).
Signed-off-by: Jonathon Mah <me@JonathonMah.com>
Helped-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We feed a root "objdir" path to this iterator function,
which then copies the result into a strbuf, so that it can
repeatedly append the object sub-directories to it. Let's
make it easy for callers to just pass us a strbuf in the
first place.
We leave the original interface as a convenience for callers
who want to just pass a const string like the result of
get_object_directory().
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
MAC_OS_X_VERSION_MIN_REQUIRED may be defined by the builder to a
specific version in order to produce compatible binaries for a
particular system. Blindly defining it to MAC_OS_X_VERSION_10_6
is bad.
Additionally MAC_OS_X_VERSION_10_6 will not be defined on older
systems and should AvailabilityMacros.h be included on such as
system an error will result. However, using the explicit value
of 1060 (which is what MAC_OS_X_VERSION_10_6 is defined to) does
not solve the problem.
The changes that introduced stepping on MAC_OS_X_VERSION_MIN were
made in b195aa00 (git-compat-util: suppress unavoidable
Apple-specific deprecation warnings) to avoid deprecation
warnings.
Instead of blindly setting MAC_OS_X_VERSION_MIN to 1060 change
the definition of DEPRECATED_ATTRIBUTE to empty to avoid the
warnings. This preserves any MAC_OS_X_VERSION_MIN_REQUIRED
setting while avoiding the warnings as intended by b195aa00.
Signed-off-by: Kyle J. McKay <mackyle@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Our config code simulates a stdio stream around a buffer,
but our fake ungetc() does not behave quite like the real
one. In particular, we only rewind the position by one
character, but do _not_ actually put the character from the
caller into position.
It turns out that this does not matter, because we only ever
push back the character we just read. In other words, such
an assignment would be a noop. But because the function is
called ungetc, and because it takes a character parameter,
it is a mistake waiting to happen.
Actually assigning the character into the buffer would be
ideal, but our pointer is actually a "const" copy of the
buffer. We do not know who the real owner of the buffer is
in this code, and would not want to munge their contents.
Instead, we can simply add an assertion that matches what
the current caller does, and will let us know if new callers
are added that violate the contract.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The decimal_width function originally appeared in blame.c as
"lineno_width", and was designed for calculating the
print-width of small-ish integer values (line numbers in
text files). In ec7ff5b, it was made into a reusable
function, and in dc801e7, we started using it to align
diffstats.
Binary files in a diffstat show byte counts rather than line
numbers, meaning they can be quite large (e.g., consider
adding or removing a 2GB file). decimal_width is not up to
the challenge for two reasons:
1. It takes the value as an "int", whereas large files may
easily surpass this. The value may be truncated, in
which case we will produce an incorrect value.
2. It counts "up" by repeatedly multiplying another
integer by 10 until it surpasses the value. This can
cause an infinite loop when the value is close to the
largest representable integer.
For example, consider using a 32-bit signed integer,
and a value of 2,140,000,000 (just shy of 2^31-1).
We will count up and eventually see that 1,000,000,000
is smaller than our value. The next step would be to
multiply by 10 and see that 10,000,000,000 is too
large, ending the loop. But we can't represent that
value, and we have signed overflow.
This is technically undefined behavior, but a common
behavior is to lose the high bits, in which case our
iterator will certainly be less than the number. So
we'll keep multiplying, overflow again, and so on.
This patch changes the argument to a uintmax_t (the same
type we use to store the diffstat information for binary
filese), and counts "down" by repeatedly dividing our value
by 10.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we are parsing a config value, if we see a carriage
return, we fgetc the next character to see if it is a
line feed (in which case we silently drop the CR). If it
isn't, we then ungetc the character, and take the literal
CR.
But we never check whether we in fact got a character at
all. If the config file ends in CR, we will get EOF here,
and try to ungetc EOF. This works OK for a real stdio
stream. The ungetc returns an error, and the next fgetc will
then return EOF again.
However, our custom buffer-based stream is not so fortunate.
It happily rewinds the position of the stream by one
character, ignoring the fact that we fed it EOF. The next
fgetc call returns the final CR again, over and over, and we
end up in an infinite loop.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The __builtin_ctzll function was added in gcc 3.4.0.
This extends the check for gcc so that use of __builtin_ctzll is only
enabled if gcc >= 3.4.0.
Signed-off-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
curl 7.11.0 through 7.12.2 when built from their official release
archives will present a 5 digit version number instead of the documented
6 digits which breaks the version check in the Makefile.
Correct these broken version numbers on the fly when extracting them to
ensure the comparison works correctly.
[jc: shortened the new sed scripts a bit]
Signed-off-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we add a new submodule the path of the submodule is being
normalized. We fail to normalize multiple adjacent '/./', though.
Thus 'path/to/././submodule' will become 'path/to/./submodule' where
it should be 'path/to/submodule' instead.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
Acked-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We may want to say something about command line option names in the
new section as well, but for now, let's make sure everybody is clear
on how to structure and name their configuration variables.
The text for the rules are partly taken from the log message of
Jonathan's 6b3020a2 (add: introduce add.ignoreerrors synonym for
add.ignore-errors, 2010-12-01).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems to be a common mistake to try using a single remote
(e.g. 'origin') to fetch from one place (i.e. upstream) while
pushing to another (i.e. your publishing point).
That will never work satisfactorily, and it is easy to understand
why if you think about what refs/remotes/origin/* would mean in such
a world. It fundamentally cannot reflect the reality. If it
follows the state of your upstream, it cannot match what you have
published, and vice versa.
It may be that misinformation is spread by some people. Let's
counter them by adding a few words to our documentation.
- The description was referring to <oldurl> and <newurl>, but never
mentioned <name> argument you give from the command line. By
mentioning "remote <name>", stress the fact that it is configuring
a single remote.
- Add a reminder that explicitly states that this is about a single
remote, which the triangular workflow is not about.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some older versions of gpg (reportedly v1.2.6 from RHEL4) cannot
import the keyrings found in our test suite, and thus cannot even
make a signature. The previous change works it around, but we
cannot anticipate breakages update to GPG would cause in the future.
Do a test-sign before declaring the GPG prerequisite fulfilled
to future-proof our tests.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 1e3eefb (tests: replace binary GPG keyrings with
ASCII-armored keys, 2014-12-12), we import our test GPG keys
from a single file. Each keypair in the import stream
contains both the secret and public keys. However, older
versions of gpg reportedly fail to import the public half of
the key. We can solve this by including duplicates of the
public keys separately. The duplicates are ignored by modern
gpg, and this makes older versions work.
Reported by Tom G. Christensen <tgc@statsbiblioteket.dk> on
gpg 1.2.6 (from RHEL4).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
b6d8f309 (diff-raw format update take #2., 2005-05-23) started
documenting the diff format, and it said
...
(8) sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree".
(9) status, followed by similarlity index number only for C and R.
(10) a tab or a NUL when '-z' option is used.
...
because C and R _were_ the only ones that came with a number back
then. This was corrected by ddafa7e9 (diff-helper: Fix R/C score
parsing under -z flag., 2005-05-29) and we started saying "score"
instead of "similarlity index" (because we can have other kind of
score there), and stopped saying "only for C and R" (because Git is
an ever evolving system). Later f345b0a0 (Add -B flag to diff-*
brothers., 2005-05-30) introduced a new concept, "dissimilarity"
score; it did not have to fix any documentation.
The current text that says only C and R can have scores came
independently from a5a323f3 (Add reference for status letters in
documentation., 2008-11-02) and it was wrong from the day one.
Noticed-by: Mike Hommey
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As per the code, the --repo <repo> option is equivalent to the
<repo> argument to 'git push', but somehow it was documented as
something that is more than that. [It exists for historical
reasons, back from the time when options had to come before
arguments.]
Say so. [But not that.]
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Helped-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no point in checking "!ref->name" when ref is a
"struct ref". The name field is a flex-array, and there
always has a non-zero address. This is almost certainly not
hurting anything, but it does cause clang-3.6 to complain.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we are chomping newlines from the end of a strbuf, we
must check "sb.len != 0" before accessing "sb.buf[sb.len - 1]".
However, this code mistakenly checks "&sb.len", which is
always true (it is a part of an auto struct, so the address
is always non-zero). This could lead to us accessing memory
outside the strbuf when we read an empty file.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old text gave an impression that even in a new repository using
old form might be safer. Only Git from pre 1.7.0 days choke on the
correctly named variable, which is ancient by today's standard.
We have no intention to remove the support for deprecated ones, but
let's make sure that we do not give room for confused questions such
as "why does core.sparse-checkout not work, when add.ignore-errors
does?"
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once upon a time, dumb http always fetched .idx files
directly into their final location, and then checked their
validity with parse_pack_index. This was refactored in
commit 750ef42 (http-fetch: Use temporary files for
pack-*.idx until verified, 2010-04-19), which uses the
following logic:
1. If we have the idx already in place, see if it's
valid (using parse_pack_index). If so, use it.
2. Otherwise, fetch the .idx to a tempfile, check
that, and if so move it into place.
3. Either way, fetch the pack itself if necessary.
However, it got step 1 wrong. We pass a NULL path parameter
to parse_pack_index, so an existing .idx file always looks
broken. Worse, we do not treat this broken .idx as an
opportunity to re-fetch, but instead return an error,
ignoring the pack entirely. This can lead to a dumb-http
fetch failing to retrieve the necessary objects.
This doesn't come up much in practice, because it must be a
packfile that we found out about (and whose .idx we stored)
during an earlier dumb-http fetch, but whose packfile we
_didn't_ fetch. I.e., we did a partial clone of a
repository, didn't need some packfiles, and now a followup
fetch needs them.
Discovery and tests by Charles Bailey <charles@hashpling.org>.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If an --author argument is specified but does not contain a '>' then git tries
to find the argument within the existing authors; and gives the error
message "No existing author found with '%s'" if there is no match.
This is confusing for users who try to specify a valid complete author
name.
Rename the error message to make it clearer that the failure has two
reasons in this case.
(This codepath is touched only when we know already that the argument
cannot be a completely wellformed author ident.)
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This message is about leaving orphaned commits behind, not about
behind an upstream branch. Try to make this clear.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Such a username with "@" in it isn't all that unusual these days.
cf. https://groups.google.com/forum/#!msg/msysgit/YVuCqmwwRyY/HULHj5OoE88J
Signed-off-by: Aleksey Vasenev <margtu-fivt@ya.ru>
Acked-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
4fe10219 (rev-list: add --indexed-objects option, 2014-10-16) adds
"--indexed-objects" option to "rev-list", and it is only useful in
the context of "git rev-list" and not "git log". There are other
object traversal options that do not make sense for "git log" that
are shown in the manual page.
Move the description of "--indexed-objects" to the object traversal
section so that it sits together with its friends "--objects",
"--objects-edge", etc. and then show them only in "git rev-list"
documentation.
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The list_and_choose() helper is given a prompt and a list, asks the
user to make selection from the list, and then returns a list of
items chosen. Even when it is given an empty list as the original
candidate set to choose from, it gave a prompt to the user, who can
only say "I am done choosing".
Return an empty result when the input is an empty list without
bothering the user. The existing caller must already have a logic
to say "Nothing to do" or an equivalent when the returned list is
empty (i.e. the user chose to select nothing) if it is necessary, so
no change to the callers is necessary.
This fixes the case where "add untracked" is asked in "git add -i"
and there is no untracked files in the working tree. We used to give
an empty list of files to choose from with a prompt, but with this
change, we no longer do.
Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Version numbers in asciidoc-generated content (such as man pages)
went missing as of da8a366 (Documentation: refactor common operations
into variables). Fix by putting the underscore back in the variable
name.
Signed-off-by: Sven van Haastregt <svenvh@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Under --whitespace=fix option, match_fragment() function examines
the preimage (the common context and the removed lines in the patch)
and the file being patched and checks if they match after correcting
all whitespace errors. When they are found to match, the common
context lines in the preimage is replaced with the fixed copy,
because these lines will then be copied to the corresponding place
in the postimage by a later call to update_pre_post_images(). Lines
that are added in the postimage, under --whitespace=fix, have their
whitespace errors already fixed when apply_one_fragment() prepares
the preimage and the postimage, so in the end, application of the
patch can be done by replacing the block of text in the file being
patched that matched the preimage with what is in the postimage that
was updated by update_pre_post_images().
In the earlier days, fixing whitespace errors always resulted in
reduction of size, either collapsing runs of spaces in the indent to
a tab or removing the trailing whitespaces. These days, however,
some whitespace error fix results in extending the size.
250b3c6c (apply --whitespace=fix: avoid running over the postimage
buffer, 2013-03-22) tried to compute the final postimage size but
its math was flawed. It counted the size of the block of text in
the original being patched after fixing the whitespace errors on its
lines that correspond to the preimage. That number does not have
much to do with how big the final postimage would be.
Instead count (1) the added lines in the postimage, whose size is
the same as in the final patch result because their whitespace
errors have already been corrected, and (2) the fixed size of the
lines that are common.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git apply --whitespace=fix" used to be able to assume that fixing
errors will always reduce the size by e.g. stripping whitespaces at
the end of lines or collapsing runs of spaces into tabs at the
beginning of lines. An update to accomodate fixes that lengthens
the result by e.g. expanding leading tabs into spaces were made long
time ago but the logic miscounted the necessary space after such
whitespace fixes, leading to either under-allocation or over-usage
of already allocated space.
Illustrate this with a runtime sanity-check to protect us from
future breakage. The test was stolen from Kyle McKay who helped
to identify the problem.
Helped-by: "Kyle J. McKay" <mackyle@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 908a320363 introduced indentation
to here documents in t3301.sh. However in one place <<-EOF was missing
-, which broke this test when run with mksh-50d. This commit fixes it.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In earlier days, the abbreviated commit object name shown to the end
users were generated with hardcoded --abbrev=7; 56895038 (rebase
-i: respect core.abbrev, 2013-09-28) tried to make it honor the user
specified core.abbrev, but it missed the very initial invocation of
the editor.
These days, we try to use the full 40-hex object names internally to
avoid ambiguity that can arise after rebase starts running. Newly
created objects during the rebase may share the same prefix with
existing commits listed in the insn sheet. These object names are
shortened just before invoking the sequence editor to present the
insn sheet to the end user, and then expanded back to full object
names when the editor returns.
But the code still used the shortened names when preparing the insn
sheet for the very first time, resulting "7 hexdigits or more"
output to the user. Change the code to use full 40-hex commit
object names from the very beginning to make things more uniform.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A typical remote helper will return a `list` of refs containing a symbolic
ref HEAD, pointing to, e.g. refs/heads/master. In the case of a clone, all
the refs are being requested through `fetch` or `import`, including the
symbolic ref.
While this works properly, in some cases of a fetch, like `git fetch url`
or `git fetch origin HEAD`, or any fetch command involving a symbolic ref
without also fetching the corresponding ref it points to, the fetch command
fails with:
fatal: bad object 0000000000000000000000000000000000000000
error: <remote> did not send all necessary objects
(in the case the remote helper returned '?' values to the `list` command).
This is because there is only one ref given to fetch(), and it's not
further resolved to something at the end of fetch_with_import().
While this can be somehow handled in the remote helper itself, by adding
a refspec for the symbolic ref, and storing an explicit ref in a private
namespace, and then handling the `import` for that symbolic ref
specifically, very few existing remote helpers are actually doing that.
So, instead of requesting the exact list of wanted refs to remote helpers,
treat symbolic refs differently and request the ref they point to instead.
Then, resolve the symbolic refs values based on the pointed ref.
This assumes there is no more than one level of indirection (a symbolic
ref doesn't point to another symbolic ref).
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
