The -a and -r options used to be silently ignored in such a command.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Starting from commit 8db35596, "git remote update" (with no
group name given) will fail with the following message if
remotes.default has been set in the config file:
fatal: 'default' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
The problem is that the --multiple option is not passed to
"git fetch" if no remote or group name is given on the command
line. Fix the problem by always passing the --multiple
option to "git fetch" (which actually simplifies the code).
Reported-by: YONETANI Tomokazu
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
395de250 (Expand ~ and ~user in core.excludesfile, commit.template)
introduced a C function git_config_pathname, doing ~/ and ~user/
expansion. This patch makes the feature available to scripts with 'git
config --get --path'.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refspecs without a source side have been reported as confusing by many.
As an alternative, this adds support for commands like:
git push origin --delete somebranch
git push origin --delete tag sometag
Specifically, --delete will prepend a colon to all colon-less refspecs
given on the command line, and will refuse to accept refspecs with
colons to prevent undue confusion.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 952dfc6 tried to tighten the safety valves for doing
a "reset --hard" in a bare repository or outside the work
tree, but accidentally broke the case for GIT_WORK_TREE.
This patch unbreaks it.
Most git commands which need a work tree simply use
NEED_WORK_TREE in git.c to die before they get to their
cmd_* function. Reset, however, only needs a work tree in
some cases, and so must handle the work tree itself. The
error that 952dfc6 made was to simply forbid certain
operations if the work tree was not set up; instead, we need
to do the same thing that NEED_WORK_TREE does, which is to
call setup_work_tree(). We no longer have to worry about dying
in the non-worktree case, as setup_work_tree handles that
for us.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Input to "grep" is supposed to be "text", but we deliberately feed output
from "git diff --color" to sift it into two sets of lines (ones with
errors, the other without). Some implementations of "grep" only report
matches with the exit status, without showing the matched lines in their
output (e.g. OpenBSD 4.6, which says "Binary file .. matches").
Fortunately, "grep -a" is often a way to force the command to treat its
input as text.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"find path ..." command should exit with zero status only when all path
operands were traversed successfully. When a non-existent path is given,
however, some implementations of "find" (e.g. OpenBSD 4.6) exit with zero
status and break the last test in t1200.
Rewrite the test to check that there is no regular files in the objects
fan-out directories to work around this bug; it is closer to what we are
testing anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn gc will compress the unhandled.log files that git svn mkdirs reads,
causing git svn mkdirs to skip directory creation.
[ew: trivial whitespace cleanups]
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
The human-readable author and committer name can be missing from
commits imported from foreign SCM interfaces. Make sure we parse
the "author" and "committer" line a bit more leniently and avoid
segfaulting by assuming the name always exists.
Signed-off-by: David Reiss <dreiss@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old function was incorrect; in some instances it marks a cherry picked
range as a merged branch (because of an incorrect assumption that
'rev-list COMMIT --not RANGE' would work). This is replaced with a
function which should detect them correctly, memoized to limit the expense
of dealing with branches with many cherry picks to one 'merge-base' call
per merge, per branch which used cherry picking.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
SVN's list of commit ranges in mergeinfo tickets is inclusive, whereas
git commit ranges are exclusive on the left hand side. Also, the end
points of the commit ranges may not exist; they simply delineate
ranges of commits which may or may not exist. Fix these two mistakes.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
As shown, git-svn has some problems; not all svn merges are correctly
detected, and cherry picks may incorrectly be detected as real merges.
These test cases will be marked as _success once the relevant fixes are in.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
The "git svn gc" command creates and appends to unhandled.log.gz
files which should be parsed before the uncompressed
unhandled.log files.
Reported-by: Robert Zeh
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If a command is run with an absolute path as a pathspec inside a bare
repository, e.g. "rev-list HEAD -- /home", the code tried to run strlen()
on NULL, which is the result of get_git_work_tree(), and segfaulted. It
should just fail instead.
Currently the function returns NULL even inside .git/ in a repository
with a work tree, but that is a separate issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).
The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.
However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.
This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fast-forward logic is never being triggered because $common and
$MRC are never equivalent. $common is initialized to a commit id by
merge-base and MRC is initialized to HEAD. Fix this by initializing
$MRC to the commit id for HEAD so that its possible for $MRC and
$common to be equal.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Its not very easy to understand what heads are being merged given
the current output of an octopus merge. Fix this by replacing the
sha1 with the (usually) better description in GITHEAD_<SHA1>.
Suggested-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suggesting "'reset HEAD <path>' to unstage" is dead wrong if we are about
to record a merge commit. For either an unmerged path (i.e. with
unresolved conflicts), or an updated path, it would result in discarding
what the other branch did.
Note that we do not do anything special in a case where we are amending a
merge. The user is making an evil merge starting from an already
committed merge, and running "reset HEAD <path>" is the right way to get
rid of the local edit that has been added to the index.
Once "reset --unresolve <path>" becomes available, we might want to
suggest it for a merged path that has unresolve information, but until
then, just remove the incorrect advice.
We might also want to suggest "checkout --conflict <path>" to revert the
file in the work tree to the state of failed automerge for an unmerged
path, but we never did that, and this commit does not change that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the desired resolution is to remove the path, "git rm <path>" is the
command the user needs to use. Just like in "Changed but not updated"
section, suggest to use "git add/rm" as appropriate.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This hook runs after "git fetch" in the repository the objects are
fetched from as the user who fetched, and has security implications.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move a useful script function to decode colored output to
text form from t4034 and use it in this test as well.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 24ab81a fixed the deletion of empty files, but broke
deletion of non-empty files. The approach it took was to
factor out the "deleted" line from the patch header into its
own hunk, the same way we do for mode changes. However,
unlike mode changes, we only showed the special "delete this
file" hunk if there were no other hunks. Otherwise, the user
would annoyingly be presented with _two_ hunks: one for
deleting the file and one for deleting the content.
This meant that in the non-empty case, we forgot about the
deleted line entirely, and we submitted a bogus patch to
git-apply (with "/dev/null" as the destination file, but not
marked as a deletion).
Instead, this patch combines the file deletion hunk and the
content deletion hunk (if there is one) into a single
deletion hunk which is either staged or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also adds a test case for:
"git svn: Don't create empty directories whose parents were deleted"
which was the reason we found this bug in the first place.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The previous error message was the same in many situations (unknown
revision or path not in the working tree). We try to help the user as
much as possible to understand the error, especially with the
sha1:filename notation. In this case, we say whether the sha1 or the
filename is problematic, and diagnose the confusion between
relative-to-root and relative-to-$PWD confusion precisely.
The 7 new error messages are tested.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, test-lib checks that the git_remote_helpers
directory has been built. However, if we are building
without python, we will not have done anything at all in
that directory, and test-lib's sanity check will fail.
We bump the inclusion of GIT-BUILD-OPTIONS further up in
test-lib; it contains configuration, and as such should be
read before we do any checks (and in this particular case,
we need its value to do our check properly).
Signed-off-by: Jeff King <peff@peff.net>
Looks-fine-to-me-by: Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing code checked to make sure we were not in a bare
repository when doing a hard reset. However, we should take
this one step further, and make sure we are in a worktree.
Otherwise, we can end up munging files inside of '.git'.
Furthermore, we should do the same check for --merge resets,
which have the same properties. Actually, a merge reset of
HEAD^ would already complain, since further down in the code
we want a worktree. However, it is nicer to check up-front;
then we are sure we cover all cases ("git reset --merge"
would run, even though it wasn't doing anything) and we can
give a more specific message.
Add tests to t7103 to cover these cases and some missing ones.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is like --author: allow a user to specify a given date without
using the GIT_AUTHOR_DATE environment variable.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only put bin-wrappers in the PATH (not GIT_EXEC_PATH), to emulate the
default installed user environment, and ensure all the programs run
correctly in such an environment. This is now the default, although
it can be overridden with a --with-dashes test option when running
tests.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When loading a notes tree, the code primarily looks for SHA1-like paths
whose total length (discounting directory separators) are 40 chars
(interpreted as valid note entries) or less (interpreted as subtree
entries that may in turn contain note entries when unpacked).
However, there is an additional condition that must hold for valid
subtree entries: They must be _tree_ objects (duh).
This patch adds an appropriate test for this condition, thereby fixing
the crash that occured when passing a non-tree object to the tree-walk
API.
The patch also adds another selftest verifying correct behaviour of
non-notes in note trees.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-chain-reply-to) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--nochain-reply-to'. More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some ancient platforms do not have an extensive list of alternate names for
character encodings. For example, Solaris 7 and IRIX 6.5 do not know that
ISO-8859-1 is the same as ISO8859-1. Modern platforms do know this, so use
the older name.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even if the user explicitly gave her own message to "git merge", the
command still added its standard merge message. It resulted in a
useless repetition like this:
% git merge -m "Merge early part of side branch" `git rev-parse side~2`
% git show -s
commit 37217141e7519629353738d5e4e677a15096206f
Merge: e68e646 a1d2374
Author: しらいし ななこ <nanako3@lavabit.com>
Date: Wed Dec 2 14:33:20 2009 +0900
Merge early part of side branch
Merge commit 'a1d2374f8f52f4e8a53171601a920b538a6cec23'
The gave her own message because she didn't want git to add the
standard message (if she wanted to, she wouldn't have given one,
or she would have prepared it using git-fmt-merge-msg command).
Noticed by Nanako Shiraishi
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were added without documentation in 2009-03-16 (6720721).
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed to allow test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed to allow the test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Give a warning message when send-email uses chain-reply-to to thread the
messages because of the current default, not because the user explicitly
asked to, either from the command line or from the configuration.
This way, by the time 1.7.0 switches the default, everybody will be ready.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Inspired by the coloring of quilt.
Introduce a separate color and paint the hunk comment part, i.e. the name
of the function, in a separate color "diff.func" (defaults to plain).
Whitespace between hunk header and hunk comment is printed in plain color.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds the option to specify the envelope sender as "auto" which
would pick the 'from' address. This is good because now we can specify
the address only in one place in $HOME/.gitconfig and change it easily.
[jc: added tests]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When emit_line() is called with an empty line (but non-zero length, as we
send line terminating LF or CRLF to the function), it used to emit
<SET><RESET> followed by a newline. Stop the wastefulness.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new short status has been completely untested so far. Introduce
tests by duplicating all tests which are present for the long format.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The patch structure has def_name component that is used to validate the
sanity of a "diff --git" patch by checking pathnames that appear on the
patch header lines for consistency. The git_header_name() function is
used to compute this out of "diff --git a/... b/..." line, but the code
always stripped one level of prefix (i.e. "a/" and "b/"), without paying
attention to -p<n> option. Code in find_name() function that parses other
lines in the patch header (e.g. "--- a/..." and "+++ b/..." lines) however
did strip the correct number of leading paths prefixes, and the sanity
check between these computed values failed.
Teach git_header_name() to honor -p<n> option like find_name() function
does.
Found and reported by Steven J. Murdoch who also wrote tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't take the author name information without re-encoding from the raw
commit object buffer.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fourth test of show-branch in t1200 test was failing but only
sometimes. It only failed when two commits created in an earlier
test had different timestamps. When they were created within the
same second, the actual output matched the expected output.
Fix this by using test_tick to force reliable timestamps and update
the expected output so it does not to depend on the commits made in
the same sacond.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch introduces parts of a Python package called
"git_remote_helpers" containing the building blocks for
remote helpers written in Python.
No actual remote helpers are part of this patch, this patch only
includes the common basics needed to start writing such helpers.
The patch includes the necessary Makefile additions to build and
install the git_remote_helpers Python package along with the rest of
Git.
This patch is based on Johan Herland's git_remote_cvs patch and
has been improved by the following contributions:
- David Aguilar: Lots of Python coding style fixes
- David Aguilar: DESTDIR support in Makefile
Cc: David Aguilar <davvid@gmail.com>
Cc: Johan Herland <johan@herland.net>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recognizing \r in a regex is something GNU sed will do, but other sed
implementation's won't (e.g. BSD sed on OS X). Instead of two sed
invocations, use a single Perl script to split output into headers
and body.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thiago Farina