For a clone or sync, --branch says where the newly imported
branch should go, or which existing branch to sync up. It
takes an argument, which is currently either something that
starts with "refs/", or if not, "refs/heads/p4" is prepended.
Putting it in heads seems like a bad default; these should
go in remotes/p4/ in most situations. Make that the new default,
and be more liberal in the form of the branch name.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using the --branch argument to "git p4 clone", one
might specify a destination for p4 changes different from
the default refs/remotes/p4/master. Both cases should
create a master branch and checkout files.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure that the standard branches are created as expected.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is code to create a symbolic reference from p4/HEAD to
p4/master. This allows saying "git show p4" as a shortcut
to "git show p4/master", for example.
But this reference was only created on the second "git p4 sync"
(or first sync after a clone). Make it work on the initial
clone or sync.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add failing tests to document behavior when there are multiple p4
branches, as created using the --branch option. In particular:
Using clone --branch populates the specified branch correctly, but
dies with an error when trying to checkout master.
Calling sync without a master branch dies with an error looking for
master. When there are two or more branches, a sync does
nothing due to branch detection code, but that is expected.
Using sync --branch to try to update just a particular branch
updates no branch, but appears to succeed.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git clone --separate-git-dir=$over_there" is interrupted, it
failed to remove the real location of the $GIT_DIR it created. This
was most visible when interrupting a submodule update.
* jl/interrupt-clone-remove-separate-git-dir:
clone: support atomic operation with --separate-git-dir
We have two simple and quick tests to catch common mistakes when
writing test scripts, but we did not run them by default when
running tests.
* jk/enable-test-lint-by-default:
tests: turn on test-lint by default
"git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook.
* ap/merge-stop-at-prepare-commit-msg-failure:
merge: Honor prepare-commit-msg return code
The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does.
* ja/directory-attrs:
Add directory pattern matching to attributes
"git fetch --mirror" and fetch that uses other forms of refspec with
wildcard used to attempt to update a symbolic ref that match the
wildcard on the receiving end, which made little sense (the real ref
that is pointed at by the symbolic ref would be updated anyway).
Symbolic refs no longer are affected by such a fetch.
* jc/fetch-ignore-symref:
fetch: ignore wildcarded refspecs that update local symbolic refs
* nd/invalidate-i-t-a-cache-tree:
cache-tree: invalidate i-t-a paths after generating trees
cache-tree: fix writing cache-tree when CE_REMOVE is present
cache-tree: replace "for" loops in update_one with "while" loops
cache-tree: remove dead i-t-a code in verify_cache()
The test fails for me on NetBSD 6.0.1 and reports:
ok 1 - ref name '' is invalid
ok 2 - ref name '/' is invalid
ok 3 - ref name '/' is invalid with options --allow-onelevel
ok 4 - ref name '/' is invalid with options --normalize
error: bug in the test script: not 2 or 3 parameters to test-expect-success
The alleged bug is in this line:
invalid_ref NOT_MINGW '/' '--allow-onelevel --normalize'
invalid_ref() constructs a test case description using its last argument,
but the shell seems to split it up into two pieces if it contains a
space. Minimal test case:
# on NetBSD with /bin/sh
$ a() { echo $#-$1-$2; }
$ t="x"; a "${t:+$t}"
1-x-
$ t="x y"; a "${t:+$t}"
2-x-y
$ t="x y"; a "${t:+x y}"
1-x y-
# and with bash
$ t="x y"; a "${t:+$t}"
1-x y-
$ t="x y"; a "${t:+x y}"
1-x y-
This may be a bug in the shell, but here's a simple workaround: Construct
the description string first and store it in a variable, and then use
that to call test_expect_success().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a sub-command dies due to a signal, we encode the
signal number into the numeric exit status as "signal -
128". This is easy to identify (versus a regular positive
error code), and when cast to an unsigned integer (e.g., by
feeding it to exit), matches what a POSIX shell would return
when reporting a signal death in $? or through its own exit
code.
So we have a negative value inside the code, but once it
passes across an exit() barrier, it looks positive (and any
code we receive from a sub-shell will have the positive
form). E.g., death by SIGPIPE (signal 13) will look like
-115 to us in inside git, but will end up as 141 when we
call exit() with it. And a program killed by SIGPIPE but run
via the shell will come to us with an exit code of 141.
Unfortunately, this means that when the "use_shell" option
is set, we need to be on the lookout for _both_ forms. We
might or might not have actually invoked the shell (because
we optimize out some useless shell calls). If we didn't invoke
the shell, we will will see the sub-process's signal death
directly, and run-command converts it into a negative value.
But if we did invoke the shell, we will see the shell's
128+signal exit status. To be thorough, we would need to
check both, or cast the value to an unsigned char (after
checking that it is not -1, which is a magic error value).
Fortunately, most callsites do not care at all whether the
exit was from a code or from a signal; they merely check for
a non-zero status, and sometimes propagate the error via
exit(). But for the callers that do care, we can make life
slightly easier by just using the consistent positive form.
This actually fixes two minor bugs:
1. In launch_editor, we check whether the editor died from
SIGINT or SIGQUIT. But we checked only the negative
form, meaning that we would fail to notice a signal
death exit code which was propagated through the shell.
2. In handle_alias, we assume that a negative return value
from run_command means that errno tells us something
interesting (like a fork failure, or ENOENT).
Otherwise, we simply propagate the exit code. Negative
signal death codes confuse us, and we print a useless
"unable to run alias 'foo': Success" message. By
encoding signal deaths using the positive form, the
existing code just propagates it as it would a normal
non-zero exit code.
The downside is that callers of run_command can no longer
differentiate between a signal received directly by the
sub-process, and one propagated. However, no caller
currently cares, and since we already optimize out some
calls to the shell under the hood, that distinction is not
something that should be relied upon by callers.
Fix the same logic in t/test-terminal.perl for consistency [jc:
raised by Jonathan in the discussion].
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since b57fb80a7d (init, clone: support --separate-git-dir for .git file)
git clone supports the --separate-git-dir option to create the git dir
outside the work tree. But when that option is used, the git dir won't be
deleted in case the clone fails like it would be without this option. This
makes clone lose its atomicity as in case of a failure a partly set up git
dir is left behind. A real world example where this leads to problems is
when "git submodule update" fails to clone a submodule and later calls to
"git submodule update" stumble over the partially set up git dir and try
to revive the submodule from there, which then fails with a not very user
friendly error message.
Fix that by updating the junk_git_dir variable (used to remember if and
what git dir should be removed in case of failure) to the new value given
with the --seperate-git-dir option. Also add a test for this to t5600 (and
while at it fix the former last test to not cd into a directory to test
for its existence but use "test -d" instead).
Reported-by: Manlio Perillo <manlio.perillo@gmail.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
65969d4 (merge: honor prepare-commit-msg hook, 2011-02-14) tried to
make "git commit" and "git merge" consistent, because a merge that
required user assistance has to be concluded with "git commit", but
back then only "git commit" triggered prepare-commit-msg hook.
When it added a call to run the prepare-commit-msg hook, however, it
forgot to check the exit code from the hook like "git commit" does,
and ended up replacing one inconsistency with another.
When prepare-commit-msg hook that is run from "git merge" exits with
a non-zero status, abort the commit.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test Makefile knows about a few "lint" checks for common
errors. However, they are not enabled as part of "make test"
by default, which means that many people do not bother
running them. Since they are both quick to run and accurate
(i.e., no false positives), there should be no harm in
turning them on and helping submitters catch errors earlier.
We could just set:
TEST_LINT = test-lint
to enable all tests. But that would be unnecessarily
annoying later on if we add slower or less accurate tests
that should not be part of the default. Instead, we name the
tests individually.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
sed -i is not portable on all systems. Use sed with different input
and output files. Utilize a tmp file whenever needed.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When testing aliases in t/t1020-subdirectory.sh use longer names so that
they're less likely to conflict with a git-* command somewhere in the
$PATH.
I have a git-ss command in my path which prevents the 'ss' alias from
being used. This command will always fail for git.git, causing the test
to fail. Even if the command succeeded, that would be a false success
for the test since the alias wasn't actually used. A longer, more
descriptive name will make it much less likely that somebody has a
command in their $PATH which will shadow the alias created for the test.
While here, use a longer name for the 'test' alias as well since that is
also short and meaningful enough to make it not unlikely that somebody
would have a command in their $PATH which will shadow that as well.
Signed-off-by: Aaron Schrab <aaron@schrab.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some platforms (e.g. NetBSD 6.0) seem to configure their CVS to
allow "cvs init" in an existing directory only to members of
"cvsadmin".
Instead of preparing an empty directory and then running "cvs init"
on it, let's run "cvs init" and let it create the necessary
directory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test helper svnrdump_sim.py is used as "svnrdump" during the
execution of this test, but the arrangement was not optimal:
- it relied on symbolic links;
- unportable "export VAR=VAL" was used;
- GIT_BUILD_DIR variable was not quoted correctly;
- it assumed that the Python interpreter is in /usr/bin/ and
called "python" (i.e. not "python2.7" etc.)
Rework this by writing a small shell script that spawns the right
Python interpreter, using the right quoting.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With d4a7ffa (tests: "cp -a" is a GNUism, 2012-10-08), we got rid of
most of them, but the ones in a topic that was still in flight were
missed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These "expect-failure" tests were not looking for the right string
in the patch file. For example:
grep "^ *"S. E. Cipient" <scipient@example.com>\$" patch5
was looking for "^ *S." in these three files:
"E."
"Cipient <scipient@example.com>$"
"patch5"
With some implementations of grep, the lack of file "E." was
reported as an error, leading to the failure of the test.
With other implementations of grep, the pattern "^ *S." matched what
was in patch5, without diagnosing the missing files as an error, and
made these tests unexpectedly pass.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The check_snapshot function makes sure that no cruft outside the
repository hierarchy is added to the tar archive. The output from
"tar tf" on the resulting archive is inspected to see if there is
anything that does not begin with "$prefix/".
There are two issues with this implementation:
- Traditional tar implemenations that do not understand
pax_global_header will write it out as if it is a plain file at
the top-level;
- Some implementations of tar do not add trailing slash when
showing a directory entry (i.e. the output line for the entire
archive will show "$prefix", not "$prefix/").
Fix them so that what we want to validate can be tested with
traditional tar implementations.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On systems without "locale" installed, t0200-gettext-basic.sh leaked
error messages when checking if some test locales are available.
Hide them, as they are not very useful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests themselves are properly protected by the GPG
prerequisite, but one of the set-up steps outside the
test_expect_success block unconditionally assumed that there is a
gpghome/ directory, which is not true if GPG is not being used.
It may be a good idea to move the whole set-up steps in the test but
that is a follow-up topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git log -p -S<string>" now looks for the <string> after applying
the textconv filter (if defined); earlier it inspected the contents
of the blobs without filtering.
The manpage of gitattributes says: "The rules how the pattern
matches paths are the same as in .gitignore files" and the gitignore
pattern matching has a pattern ending with / for directory matching.
This rule is specifically relevant for the 'export-ignore' rule used
for git archive.
Signed-off-by: Jean-Noel Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Intent-to-add entries used to forbid writing trees so it was not a
problem. After commit 3f6d56d (commit: ignore intent-to-add entries
instead of refusing - 2012-02-07), we can generate trees from an index
with i-t-a entries.
However, the commit forgets to invalidate all paths leading to i-t-a
entries. With fully valid cache-tree (e.g. after commit or
write-tree), diff operations may prefer cache-tree to index and not
see i-t-a entries in the index, because cache-tree does not have them.
Reported-by: Jonathon Mah <me@JonathonMah.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a repository cloned from somewhere else, you typically have a
symbolic ref refs/remotes/origin/HEAD pointing at the 'master'
remote-tracking ref that is next to it. When fetching into such a
repository with "git fetch --mirror" from another repository that
was similarly cloned, the implied wildcard refspec refs/*:refs/*
will end up asking to update refs/remotes/origin/HEAD with the
object at refs/remotes/origin/HEAD at the remote side, while asking
to update refs/remotes/origin/master the same way. Depending on the
order the two updates happen, the latter one would find that the
value of the ref before it is updated has changed from what the code
expects.
When the user asks to update the underlying ref via the symbolic ref
explicitly without using a wildcard refspec, e.g. "git fetch $there
refs/heads/master:refs/remotes/origin/HEAD", we should still let him
do so, but when expanding wildcard refs, it will result in a more
intuitive outcome if we simply ignore local symbolic refs.
As the purpose of the symbolic ref refs/remotes/origin/HEAD is to
follow the ref it points at (e.g. refs/remotes/origin/master), its
value would change when the underlying ref is updated.
Earlier commit da3efdb (receive-pack: detect aliased updates which
can occur with symrefs, 2010-04-19) fixed a similar issue for "git
push".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A recent commit [1] fixed a off-by-one wrapping error. As a
side-effect, the conditional in add_wrapped_shortlog_msg() to decide
whether to append a newline needs to be removed. The function
should always append a newline, which was the case before the
off-by-one fix, because strbuf_add_wrapped_text() never returns a
value of wraplen; when it returns wraplen, the string does not end
with a newline, so this caller needs to add one anyway.
[1] 14e1a4e1ff utf8: fix off-by-one
wrapping of text
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Consistently use a single space before and after the "=" (or ":=", "+=",
etc.) in assignments to make macros. Granted, this was not a big deal,
but I did find the needless inconsistency quite distracting.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff --stat" miscounted the total number of changed lines when
binary files were involved and hidden beyond --stat-count. It also
miscounted the total number of changed files when there were
unmerged paths.
* lt/diff-stat-show-0-lines:
t4049: refocus tests
diff --shortstat: do not count "unmerged" entries
diff --stat: do not count "unmerged" entries
diff --stat: move the "total count" logic to the last loop
diff --stat: use "file" temporary variable to refer to data->files[i]
diff --stat: status of unmodified pair in diff-q is not zero
test: add failing tests for "diff --stat" to t4049
Fix "git diff --stat" for interesting - but empty - file changes
- Enclose tests in single quotes as opposed to double quotes. This is
the prevalent style in other tests.
- Remove the unused variable $head4_full.
- Indent the expected output so that it lines up with the rest of the
test text.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of "cd there and then come back", use the "cd there in a
subshell" pattern. Also fix '&&' chaining in one place.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
`git rev-list --max-count=1 HEAD` is a roundabout way of saying `git
rev-parse --verify HEAD`; replace a bunch of instances of the former
with the latter. Also, don't unnecessarily `cut -c1-7` the rev-parse
output when the `--short` option is available.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git diff --stat" miscounted the total number of changed lines when
binary files were involved and hidden beyond --stat-count. It also
miscounted the total number of changed files when there were
unmerged paths.
* lt/diff-stat-show-0-lines:
t4049: refocus tests
diff --shortstat: do not count "unmerged" entries
diff --stat: do not count "unmerged" entries
diff --stat: move the "total count" logic to the last loop
diff --stat: use "file" temporary variable to refer to data->files[i]
diff --stat: status of unmodified pair in diff-q is not zero
test: add failing tests for "diff --stat" to t4049
