Since no version of receive-pack accepts these "funny refs", we should
mirror the check when considering the list of refs to send. IOW, don't
even make them eligible for matching or mirroring.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The comments for normalize_absolute_path explicitly claim
that the source and destination buffers may be the same
(though they may not otherwise overlap). Thus the call to
memcpy may involve copying overlapping data, and memmove
should be used instead.
This fixes a valgrind error in t1504.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the main loop of find_deltas, we do:
struct object_entry *entry = *list++;
...
if (!*list_size)
...
break
Because we look at and increment *list _before_ the check of
list_size, in the very last iteration of the loop we will
look at uninitialized data, and increment the pointer beyond
one past the end of the allocated space. Since we don't
actually do anything with the data until after the check,
this is not a problem in practice.
But since it technically violates the C standard, and
because it provokes a spurious valgrind warning, let's just
move the initialization of entry to a safe place.
This fixes valgrind errors in t5300, t5301, t5302, t303, and
t9400.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most cache_entry structs are allocated by using the
cache_entry_size macro, which rounds the size of the struct
up to the nearest multiple of 8 bytes (presumably to avoid
memory fragmentation).
There is one exception: the special "conflict entry" is
allocated with an empty name, and so is explicitly given
just one extra byte to hold the NUL.
However, later code doesn't realize that this particular
struct has been allocated differently, and happily tries
reading and copying it based on the ce_size macro, which
assumes the 8-byte alignment.
This can lead to reading uninitalized data, though since
that data is simply padding, there shouldn't be any problem
as a result. Still, it makes sense to hold the padding
assumption so as not to surprise later maintainers.
This fixes valgrind errors in t1005, t3030, t4002, and
t4114.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation spoke of the attribute being set "to" a path; this can
mistakenly be interpreted as "the attribute needs to have its value set to
some kind of path". This clarifies things.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test was broken on admittedly broken combination of Windows, Cygwin,
and ActiveState Perl.
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows us replace perl when getting the mtime of a file because
of time zone conversions, though at the moment only one platform which
does this has been identified: Cygwin when used with ActiveState Perl
(as usual).
The output format is:
<mtime1> TAB <filename1> <LF>
<mtime2> TAB <filename2> <LF>
...
which, if only mtime is needed can be parsed with cut(1):
test-chmtime -v +0 filename1 | cut -f 1
Also, the change adds a description of programs features, with examples.
Signed-off-by: Alex Riesen <ariesen@harmanbecker.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Insert an empty <simpara> in manpages after code blocks to force and
empty line.
The problem can be seen on the manpage for the git tutorial, where an
example command and the following paragraph is printed with no empty
line between them:
First, note that you can get documentation for a command such as git
log --graph with:
$ man git-log
It is a good idea to introduce yourself to git [...]
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we refuse to do rename detection due to having too many files
created or deleted, let the user know the numbers. That way there is a
reasonable starting point for setting the diff.renamelimit option.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is one of the server side programs and needs to be found on usual $PATH.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
/etc/passwd shell field must be something execable, you can't enter
"/usr/bin/git shell" there. git-shell must be present as a separate
executable, or it is useless.
Signed-off-by: Tommi Virtanen <tv@eagain.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Current 'git add -p' will say "No changes." if there are no changes to
text files, which can be confusing if there _are_ changes to binary
files. Add some code to distinguish the two cases, and give a
different message in the latter one.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This moves the call to git_config to a place where it doesn't break the
logic for using git archive in a bare repository but retains the fix to
make git archive respect core.autocrlf.
Tests are by René Scharfe.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Tested-by: Deskin Miller <deskinm@umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before commit d0b92a3f6e it was possible to run 'git index-pack'
directly in the .git/objects/pack/ directory. Restore that ability.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
06cbe855 (Make core.sharedRepository more generic, 2008-04-16) made
several testcases in t1301-shared-repo.sh which fail if on a system
which creates files with extended attributes (e.g. SELinux), since ls
appends a '+' sign to the permission set in such cases. In fact,
POSIX.1 allows ls to add a single printable character after the usual
3x3 permission bits to show that an optional alternate/additional access
method is associated with the path.
This fixes the testcase to strip any such sign prior to verifying the
permission set.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tested-by: Deskin Miller <deskinm@umich.edu>
'--signoff' uses commiter name always to add the signoff line,
make it explicit in the documentation.
Signed-off-by: Abhijit Bhopatkar <bain@devslashzero.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
read_packed_sha1 expectes its caller to free the buffer it returns, which
force_object_loose didn't do.
This leak is eventually triggered by "git gc", when it is manually invoked
or there are too many packs around, making gc totally unusable when there
are lots of unreachable objects.
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 969c8775 introduced a test which uses the non-portable construct:
command1 && ! command2 | command3
which must be
command1 && ! (command2 | command3)
to work on bsd shells (this is another example of bbf08124, which fixed
several similar cases).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test creates files with several different umasks and expects their
permissions to be initialized according to the umask, so a default ACL on the
trash directory (which overrides the umask for files created in that directory)
causes the test to fail. To avoid that, remove the default ACL if possible with
setfacl(1).
Signed-off-by: Matt McCutchen <matt@mattmccutchen.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Plumbing tools should document what output can be expected.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
POSIX doth sayeth:
"In the regular expression processing described in IEEE Std 1003.1-2001,
the <newline> is regarded as an ordinary character and both a period and
a non-matching list can match one. ... Those utilities (like grep) that
do not allow <newline>s to match are responsible for eliminating any
<newline> from strings before matching against the RE."
Thus far git has not been removing the trailing newline from strings matched
against regular expression patterns. This has the effect that (quoting
Jonathan del Strother) "... a line containing just 'FUNCNAME' (terminated by
a newline) will be matched by the pattern '^(FUNCNAME.$)' but not
'^(FUNCNAME$)'", and more simply not '^FUNCNAME$'.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since the newline is not removed from lines before pattern matching, a
pattern cannot match to the end of the line using the '$' operator without
using an additional operator which will indirectly match the '\n' character.
Introduce a test which should pass, but which does not due to this flaw.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test used the non-zero exit status of 'git diff' to indicate that a
negated funcname pattern, when placed last, was correctly rejected.
The problem with this is that 'git diff' always returns non-zero if it
finds differences in the files it is comparing, and the files must
contain differences in order to trigger the funcname pattern codepath.
Instead of checking for non-zero exit status, make sure the expected
error message is printed.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test is supposed to disallow remote entries in the config file of the
form:
[remote "/foobar"]
...
The leading slash in '/foobar' is not acceptable.
Instead it was incorrectly testing that the subkey had no leading '/', which
had no effect since the subkey pointer was made to point at a '.' in the
preceding lines.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We carefully verify that the input to git-apply is sane,
including cross-checking that the filenames we see in "+++"
headers match what was provided on the command line of "diff
--git". When --directory is used, however, we ended up
comparing the unadorned name to one with the prepended root,
causing us to complain about a mismatch.
We simply need to prepend the root directory, if any, when
pulling the name out of the git header.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In case there is no commit to apply (for example because you rebase to
upstream and all your local patches have been applied there), do not
fail. The non-interactive rebase already behaves that way.
Do this by introducing a new command, "noop", which is substituted for
an empty commit list, so that deleting the commit list can still abort
as before.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When executing a single test with colors enabled, the cursor was not set
back to the previous one, and you had to hit an extra enter to get it
back.
Work around this problem by calling 'tput sgr0' before printing the
final newline.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since v1.6.0.2~13^2~ the completion of a thin pack uses sha1write() for
its ability to compute a SHA1 on the written data. This also provides
data buffering which, along with commit 92392b4a45, will confuse pread()
whenever an appended object is 1) freed due to memory pressure because
of the depth-first delta processing, and 2) needed again because it has
many delta children, and 3) its data is still buffered by sha1write().
Let's fix the issue by simply forcing cached data out when such an
object is written so it can be pread()'d at leisure.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This typo led to stack corruption for lines with whitespace fixes
and length > 1024.
Signed-off-by: Imre Deak <imre.deak@gmail.com>
Looks-good-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The referenced commit tried to fix a flaw in stash's handling of a user
supplied invalid ref. i.e. 'git stash apply fake_ref@{0}' should fail
instead of applying stash@{0}. But, it did so in a naive way by avoiding the
use of the --default option of rev-parse, and instead manually supplied the
default revision if the user supplied an empty command line. This prevented
a common usage scenario of supplying flags on the stash command line (i.e.
non-empty command line) which would be parsed by lower level git commands,
without supplying a specific revision. This should fall back to the default
revision, but now it causes an error. e.g. 'git stash show -p'
The correct fix is to use the --verify option of rev-parse, which fails
properly if an invalid ref is supplied, and still allows falling back to a
default ref when one is not supplied.
Convert stash-drop to use --verify while we're at it, since specifying
multiple revisions for any of these commands is also an error and --verify
makes it so.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Fix two memory allocation errors which allocate space for a pointer
rather than enough space for the structure itself.
This:
struct commit_list *parent = xmalloc(sizeof(struct commit_list *));
should have been this:
struct commit_list *parent = xmalloc(sizeof(struct commit_list));
But while we're at it, change the allocation to reference the
variable it is allocating memory for to try to prevent a similar
mistake, for example if the type is changed, in the future.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we use pread() while at the end of the file, it will return 0, which is
not an error from the operating system point of view. In this case, errno
has not been set and must not be used.
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If core.bare or core.sharedRepository are set in /etc/gitconfig or
~/.gitconfig, then 'git init' will read the values when constructing a
new config file; reading them, however, will override the values
specified on the command line. In the case of --bare, this ends up
causing a segfault, without the repository being properly initialised;
in the case of --shared, the permissions are set according to the
existing config settings, not what was specified on the command line.
This fix saves any specified values for --bare and --shared prior to
reading existing config settings, and restores them after reading but
before writing the new config file. core.bare is ignored in all
situations, while core.sharedRepository will only be used if --shared
is not specified to git init.
Also includes testcases which use a specified global config file
override, demonstrating the former failure scenario.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
