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>
Only add a symlink to the repository if both the filesystem and
unzip support symlinks. To check the latter, add a ZIP file
containing a symlink, created like this with InfoZIP zip 3.0:
$ echo sample text >textfile
$ ln -s textfile symlink
$ zip -y infozip-symlinks.zip textfile symlink
If we can extract it successfully, we add a symlink to the test
repository for git archive --format=zip, or otherwise skip that
step. Users can see the skipped test and perhaps run it again
with a different unzip version.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change makes the code smaller and we can put it at the top of
the script, its rightful place as setup code.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
InfoZIP's unzip takes default parameters from the environment variable
UNZIP. Unset it in the test library and use GIT_UNZIP for specifying
alternate versions of the unzip command instead.
t0024 wasn't even using variable for the actual extraction. t5000
was, but when setting it to InfoZIP's unzip it would try to extract
from itself (because it treats the contents of $UNZIP as parameters),
which failed of course.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Windows disallows file names that contain a star. Arrange the test setup
to insert the file name "f*" in the repository without the corresponding
file in the worktree.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jeff King <peff@peff.net>
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>
The beginning of 'integrate with the tip of the remote branch, not
the commit recorded in the superproject gitlink' support.
* wk/submodule-update-remote:
submodule add: If --branch is given, record it in .gitmodules
submodule update: add --remote for submodule's upstream changes
submodule: add get_submodule_config helper funtion
Allow scripts to feed literal paths to commands that take
pathspecs, by disabling wildcard globbing.
* jk/pathspec-literal:
add global --literal-pathspecs option
Conflicts:
dir.c
Introduce "log --format=%C(auto,blue)Foo%C(auto,reset)" that does
not color its output when writing to a non-terminal.
* jc/format-color-auto:
log --format: teach %C(auto,black) to respect color config
t6006: clean up whitespace
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
Allow us to read, and default to read, mailmap files from the tip
of the history in bare repositories. This will help running tools
like shortlog in server settings.
* jk/mailmap-from-blob:
mailmap: default mailmap.blob in bare repositories
mailmap: fix some documentation loose-ends for mailmap.blob
mailmap: clean up read_mailmap error handling
mailmap: support reading mailmap from blobs
mailmap: refactor mailmap parsing for non-file sources
Avoid false error from an attempt to update local symbolic ref via
fetch.
* jc/fetch-ignore-symref:
fetch: ignore wildcarded refspecs that update local symbolic refs
Require "-f" for push to update a tag, even if it is a fast-forward.
* cr/push-force-tag-update:
push: allow already-exists advice to be disabled
push: rename config variable for more general use
push: cleanup push rules comment
push: clarify rejection of update to non-commit-ish
push: require force for annotated tags
push: require force for refs under refs/tags/
push: flag updates that require force
push: keep track of "update" state separately
push: add advice for rejected tag reference
push: return reject reasons as a bitset
Various updates to fast-export used in the context of the remote
helper interface.
* fc/fast-export-fixes:
fast-export: make sure updated refs get updated
fast-export: don't handle uninteresting refs
fast-export: fix comparison in tests
fast-export: trivial cleanup
remote-testgit: implement the "done" feature manually
remote-testgit: report success after an import
remote-testgit: exercise more features
remote-testgit: cleanup tests
remote-testgit: remove irrelevant test
remote-testgit: remove non-local functionality
Add new simplified git-remote-testgit
Rename git-remote-testgit to git-remote-testpy
remote-helpers: fix failure message
remote-testgit: fix direction of marks
fast-export: avoid importing blob marks
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>
Accept "-v" as a synonym to "--reroll-count", so that users can say
"git format-patch -v4 master", instead of having to fully spell it
out as "git format-patch --reroll-count=4 master".
As I do not think of a reason why users would want to tell the
command to be "verbose", I think this should be OK.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Output from the tests is coloured using "green is okay, yellow is
questionable, red is bad and blue is informative" scheme.
* as/test-tweaks:
tests: paint unexpectedly fixed known breakages in bold red
tests: test the test framework more thoroughly
tests: refactor mechanics of testing in a sub test-lib
tests: change info messages from yellow/brown to cyan
tests: paint skipped tests in blue
tests: paint known breakages in yellow
tests: test number comes first in 'not ok $count - $message'
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>
We only try to get branch name in "format-patch origin" case or
similar and not "format-patch -22" where HEAD is automatically
added. Without correct branch name, branch description cannot be
added. Make sure we always get branch name.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@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>
find_branch_name() assumes to take refs/heads/<branch>. But we also
have symbolic refs, such as HEAD, that can point to a valid branch in
refs/heads and do not follow refs/heads/<branch> syntax. Remove the
assumption and apply normal ref resolution. After all it would be
confusing if rev machinery resolves a ref in one way and
find_branch_name() another.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the perl script "check-non-portable-shell.pl" to detect
non-portable shell syntax.
"echo -n" is an example of a shell command working on Linux, but not
on Mac OS X.
These shell commands are checked and reported as error:
- "echo -n" (printf should be used)
- "sed -i" (GNUism; use a temp file instead)
- "declare" (bashism, often used with arrays)
- "which" (unreliable exit status and output; use type instead)
- "test a == b" (bashism for "test a = b")
"make test-lint-shell-syntax" can be used to run only the check.
Helped-By: Jeff King <peff@peff.net>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed to
add a newline after such a line.
* sp/shortlog-missing-lf:
strbuf_add_wrapped*(): Remove unused return value
shortlog: fix wrapping lines of wraplen
After "git add -N" and then writing a tree object out of the
index, the cache-tree data structure got corrupted.
* 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 --graph code fell into infinite loop when asked to do what the
code did not expect.
* mk/maint-graph-infinity-loop:
graph.c: infinite loop in git whatchanged --graph -m
t9200 runs "cvs init" on a directory that already exists, but a
platform can configure this fail for the current user (e.g. you need
to be in the cvsadmin group on NetBSD 6.0).
* jc/test-cvs-no-init-in-existing-dir:
t9200: let "cvs init" create the test repository
t4014, t9502 and t0200 tests had various portability issues that
broke on OpenBSD.
* jc/maint-test-portability:
t4014: fix arguments to grep
t9502: do not assume GNU tar
t0200: "locale" may not exist
An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* mh/ceiling:
string_list_longest_prefix(): remove function
setup_git_directory_gently_1(): resolve symlinks in ceiling paths
longest_ancestor_length(): require prefix list entries to be normalized
longest_ancestor_length(): take a string_list argument for prefixes
longest_ancestor_length(): use string_list_split()
Introduce new function real_path_if_valid()
real_path_internal(): add comment explaining use of cwd
Introduce new static function real_path_internal()
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>
Test all possible use-cases of git-status "--ignored" with the
"--untracked-files" option with values "normal" and "all":
- An untracked directory is listed as untracked if it has a mix of
untracked and ignored files in it. With -uall, ignored/untracked
files are listed as ignored/untracked.
- An untracked directory with only ignored files is listed as
ignored. With -uall, all files in the directory are listed.
- An ignored directory is listed as ignored. With -uall, all files
in the directory are listed as ignored.
- An ignored and committed directory is listed as ignored if it has
untracked files. With -uall, all untracked files in the
directory are listed as ignored.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Normally when we match "*X" on "abcX", we call dowild("X", "abcX"),
dowild("X", "bcX"), dowild("X", "cX") and dowild("X", "X"). Only the
last call may have a chance of matching. By skipping the text before
"X", we can eliminate the first three useless calls.
compat, '*/*/*' on linux-2.6.git file list 2000 times, before:
wildmatch 7s 985049us
fnmatch 2s 735541us or 34.26% faster
and after:
wildmatch 4s 492549us
fnmatch 0s 888263us or 19.77% slower
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Normally we need recursion for "*". In this case we know that it
matches everything until "/" so we can skip the recursion.
glibc, '*/*/*' on linux-2.6.git file list 2000 times
before:
wildmatch 8s 74513us
fnmatch 1s 97042us or 13.59% faster
after:
wildmatch 3s 521862us
fnmatch 3s 488616us or 99.06% slower
Same test with compat/fnmatch:
wildmatch 8s 110763us
fnmatch 2s 980845us or 36.75% faster
wildmatch 3s 522156us
fnmatch 1s 544487us or 43.85% slower
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So far, wildmatch() has always honoured directory boundary and there
was no way to turn it off. Make it behave more like fnmatch() by
requiring all callers that want the FNM_PATHNAME behaviour to pass
that in the equivalent flag WM_PATHNAME. Callers that do not specify
WM_PATHNAME will get wildcards like ? and * in their patterns matched
against '/', just like not passing FNM_PATHNAME to fnmatch().
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"**" is adjusted to only be effective when surrounded by slashes, in
40bbee0 (wildmatch: adjust "**" behavior - 2012-10-15). Except that
the commit did it wrong:
1. when it checks for "the preceding slash unless ** is at the
beginning", it compares to wrong pointer. It should have compared
to the beginning of the pattern, not the text.
2. prev_p points to the character before "**", not the first "*". The
correct comparison must be "prev_p < pattern" or
"prev_p + 1 == pattern", not "prev_p == pattern".
3. The pattern must be surrounded by slashes unless it's at the
beginning or the end of the pattern. We do two checks: one for the
preceding slash and one the trailing slash. Both checks must be
met. The use of "||" is wrong.
This patch fixes all above.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
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>
The previous commit documented two known breakages revolving around
a case where one side flips a tree into a blob (or vice versa),
where the original code simply gets confused and feeds a mixture of
trees and blobs into either the recursive merge-tree (and recursing
into the blob will fail) or three-way merge (and merging tree contents
together with blobs will fail).
Fix it by feeding trees (and only trees) into the recursive
merge-tree machinery and blobs (and only blobs) into the three-way
content level merge machinery separately; when this happens, the
entire merge has to be marked as conflicting at the structure level.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rename the "branch1" parameter given to resolve() to "ours", to
clarify what is going on. Also, annotate the unresolved_directory()
function with some comments to show what decisions are made in each
step, and highlight two bugs that need to be fixed.
Add two tests to t4300 to illustrate these bugs.
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>
cherry-picking into an unborn branch should work, so make it work,
with or without --ff.
Cherry-picking anything other than a commit that only adds files, will
naturally result in conflicts. Similarly, revert also works, but will
result in conflicts unless the specified revision only deletes files.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A function for checking that two given parameters refer to the same
revision was defined in several places, so move the definition to
test-lib-functions.sh instead.
Signed-off-by: Martin von Zweigbergk <martinvonz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change color of unexpectedly fixed known breakages to bold red. An
unexpectedly passing test indicates that the test code is somehow
broken or out of sync with the code it is testing. Either way this is
an error which is potentially as bad as a failing test, and as such is
no longer portrayed as a pass in the output.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add 5 new full test suite runs each with a different number of
passing/failing/broken/fixed tests, in order to ensure that the
correct exit code and output are generated in each case. As before,
these are run in a subdirectory to avoid disrupting the metrics for
the parent tests.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This will allow us to test the test framework more thoroughly
without disrupting the top-level test metrics.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that we've adopted a "traffic lights" coloring scheme, yellow is
used for warning messages, so we need to re-color info messages to
something less alarmist. Blue is a universal color for informational
messages; however we are using that for skipped tests in order to
align with the color schemes of other test suites. Therefore we use
cyan which is also blue-ish, but visually distinct from blue.
This was suggested on the list a while ago and no-one raised any
objections:
http://thread.gmane.org/gmane.comp.version-control.git/205675/focus=205966
An earlier iteration of this patch used bold cyan, but the point of
this change is to make them less alarming; let's drop the boldness.
Also paint the message to report skipping the whole thing via
GIT_SKIP_TESTS mechanism in the same color as the "info" color
that is used on the final summary line for the entire script.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Skipped tests indicate incomplete test coverage. Whilst this is not a
test failure or other error, it's still not a complete success.
Other testsuite related software like automake, autotest and prove
seem to use blue for skipped tests, so let's follow suit.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Yellow seems a more appropriate color than bold green when
considering the universal traffic lights coloring scheme, where
green conveys the impression that everything's OK, and amber that
something's not quite right.
Likewise, change the color of the summarized total number of known
breakages from bold red to the same yellow to be less alarmist and
more consistent with the above.
An earlier version of this patch used bold yellow but because these
are all long-known failures, reminding them to developers in bold
over and over does not help encouraging them to take a look at them
very much. This iteration paints them in plain yellow instead to
make them less distracting.
Signed-off-by: Adam Spiers <git@adamspiers.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git takes pathspec arguments in many places to limit the
scope of an operation. These pathspecs are treated not as
literal paths, but as glob patterns that can be fed to
fnmatch. When a user is giving a specific pattern, this is a
nice feature.
However, when programatically providing pathspecs, it can be
a nuisance. For example, to find the latest revision which
modified "$foo", one can use "git rev-list -- $foo". But if
"$foo" contains glob characters (e.g., "f*"), it will
erroneously match more entries than desired. The caller
needs to quote the characters in $foo, and even then, the
results may not be exactly the same as with a literal
pathspec. For instance, the depth checks in
match_pathspec_depth do not kick in if we match via fnmatch.
This patch introduces a global command-line option (i.e.,
one for "git" itself, not for specific commands) to turn
this behavior off. It also has a matching environment
variable, which can make it easier if you are a script or
porcelain interface that is going to issue many such
commands.
This option cannot turn off globbing for particular
pathspecs. That could eventually be done with a ":(noglob)"
magic pathspec prefix. However, that level of granularity is
more cumbersome to use for many cases, and doing ":(noglob)"
right would mean converting the whole codebase to use
"struct pathspec", as the usual "const char **pathspec"
cannot represent extra per-item flags.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows you to easily record a submodule.<name>.branch option in
.gitmodules when you add a new submodule. With this patch,
$ git submodule add -b <branch> <repository> [<path>]
$ git config -f .gitmodules submodule.<path>.branch <branch>
reduces to
$ git submodule add -b <branch> <repository> [<path>]
This means that future calls to
$ git submodule update --remote ...
will get updates from the same branch that you used to initialize the
submodule, which is usually what you want.
Signed-off-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current `update` command incorporates the superproject's gitlinked
SHA-1 ($sha1) into the submodule HEAD ($subsha1). Depending on the
options you use, it may checkout $sha1, rebase the $subsha1 onto
$sha1, or merge $sha1 into $subsha1. This helps you keep up with
changes in the upstream superproject.
However, it's also useful to stay up to date with changes in the
upstream subproject. Previous workflows for incorporating such
changes include the ungainly:
$ git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
With this patch, all of the useful functionality for incorporating
superproject changes can be reused to incorporate upstream subproject
updates. When you specify --remote, the target $sha1 is replaced with
a $sha1 of the submodule's origin/master tracking branch. If you want
to merge a different tracking branch, you can configure the
`submodule.<name>.branch` option in `.gitmodules`. You can override
the `.gitmodules` configuration setting for a particular superproject
by configuring the option in that superproject's default configuration
(using the usual configuration hierarchy, e.g. `.git/config`,
`~/.gitconfig`, etc.).
Previous use of submodule.<name>.branch
=======================================
Because we're adding a new configuration option, it's a good idea to
check if anyone else is already using the option. The foreach-pull
example above was described by Ævar in
commit f030c96d86
Author: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Fri May 21 16:10:10 2010 +0000
git-submodule foreach: Add $toplevel variable
Gerrit uses the same interpretation for the setting, but because
Gerrit has direct access to the subproject repositories, it updates
the superproject repositories automatically when a subproject changes.
Gerrit also accepts the special value '.', which it expands into the
superproject's branch name.
Although the --remote functionality is using `submodule.<name>.branch`
slightly differently, the effect is the same. The foreach-pull
example uses the option to record the name of the local branch to
checkout before pulls. The tracking branch to be pulled is recorded
in `.git/modules/<name>/config`, which was initialized by the module
clone during `submodule add` or `submodule init`. Because the branch
name stored in `submodule.<name>.branch` was likely the same as the
branch name used during the initial `submodule add`, the same branch
will be pulled in each workflow.
Implementation details
======================
In order to ensure a current tracking branch state, `update --remote`
fetches the submodule's remote repository before calculating the
SHA-1. However, I didn't change the logic guarding the existing fetch:
if test -z "$nofetch"
then
# Run fetch only if $sha1 isn't present or it
# is not reachable from a ref.
(clear_local_git_env; cd "$path" &&
( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
test -z "$rev") || git-fetch)) ||
die "$(eval_gettext "Unable to fetch in submodule path '\$path'")"
fi
There will not be a double-fetch, because the new $sha1 determined
after the `--remote` triggered fetch should always exist in the
repository. If it doesn't, it's because some racy process removed it
from the submodule's repository and we *should* be re-fetching.
Signed-off-by: W. Trevor King <wking@tremily.us>
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>
Traditionally, %C(color attr) always emitted the ANSI color
sequence; it was up to the scripts that wanted to conditionally
color their output to omit %C(...) specifier when they do not want
colors.
Optionally allow "auto," to be prefixed to the color, so that the
output is colored iff we would color regular "log" output
(e.g., taking into account color.* and --color command line
options).
Tests and pretty_context bits by Jeff King <peff@peff.net>.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test_format function did not indent its in-line test
script in an attempt to make the output of the test look
better. But it does not make a big difference to the output,
and the source looks quite ugly. Let's use our normal
indenting instead.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old output to say "not ok - 1 messsage" was working by accident
only because the test numbers are optional in TAP.
Signed-off-by: Adam Spiers <git@adamspiers.org>
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>
The failing tests make use of a POSIX character class, '[:xdigit:]'
in this case, which some versions of the fnmatch() library function
do not support. In the spirit of commit f1cf7b79 ("t3070: disable
unreliable fnmatch tests", 15-10-2012), we disable the fnmatch() half
of these tests.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The motivation for mailmap.blob is to let users of bare
repositories use the mailmap feature, as they would not have
a checkout containing the .mailmap file. We can make it even
easier for them by just looking in HEAD:.mailmap by default.
We can't know for sure that this is where they would keep a
mailmap, of course, but it is the best guess (and it matches
the non-bare behavior, which reads from HEAD:.mailmap in the
working tree). If it's missing, git will silently ignore the
setting.
We do not do the same magic in the non-bare case, because:
1. In the common case, HEAD:.mailmap will be the same as
the .mailmap in the working tree, which is a no-op.
2. In the uncommon case, the user has modified .mailmap
but not yet committed it, and would expect the working
tree version to take precedence.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a bare repository, there isn't a simple way to respect an
in-tree mailmap without extracting it to a temporary file.
This patch provides a config variable, similar to
mailmap.file, which reads the mailmap from a blob in the
repository.
Signed-off-by: Jeff King <peff@peff.net>
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>
Use TAB's for indentation, and wrap overlong lines.
Put the closing ' at the beginning of the line.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Checking and comparing the number of line in check.list and check.cvsCount
had been replaced by comparing both files line by line.
Rename the filenames to make clear which is expected and which is actual:
check.list -> list.expected
check.cvsCount-> list.actual
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use "git ls-tree --name-only" which does not need a sed to filter out the sha
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add missing && at 2 places
Re-formated the sub-shell parantheses (coding style)
Added missing ] in the test_expect_success header at 2 places
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Redirection should not have SP before the filename
(i.e. ">out", not "> out").
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
check_end_tree():
- Instead of counting lines using wc in expectCount and cvsCount:
Sort and compare the files byte by byte with test_cmp,
which is more exact and easier to debug
- Chain all shell comands together using &&
check_end_full_tree()
- Instead of counting lines using wc in expectCount, cvsCount and gitCount:
Sort and compare the files byte by byte with test_cmp,
which is more exact and easier to debug
- Break the test using two conditions anded together with -a
into to call to test_cmp
- Chain all shell comands together using &&
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On some systems sed allows the usage of e.g.
sed -i -e "s/line1/line2/" afile
to edit the file "in place".
Other systems don't allow that: one observed behaviour is that
sed -i -e "s/line1/line2/" afile
creates a backup file called afile-e, which breaks the test.
As sed -i is not part of POSIX, avoid it.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
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
When an object has already been exported (and thus is in the marks) it's
flagged as SHOWN, so it will not be exported again, even if in a later
time it's exported through a different ref.
We don't need the object to be exported again, but we want the ref
updated, which doesn't happen.
Since we can't know if a ref was exported or not, let's just assume that
if the commit was marked (flags & SHOWN), the user still wants the ref
updated.
IOW: If it's specified in the command line, it will get updated,
regardless of whether or not the object was marked.
So:
% git branch test master
% git fast-export $mark_flags master
% git fast-export $mark_flags test
Would export 'test' properly.
Additionally, this fixes issues with remote helpers; now they can push
refs whose objects have already been exported, and a few other issues as
well. Update the tests accordingly.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
They have been marked as UNINTERESTING for a reason, lets respect
that. Currently the first ref is handled properly, but not the
rest. Assuming that all the refs point at the same commit in the
following example:
% git fast-export master ^uninteresting ^foo ^bar
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
reset refs/heads/uninteresting
from :0
% git fast-export ^uninteresting ^foo ^bar master
reset refs/heads/master
from :0
reset refs/heads/bar
from :0
reset refs/heads/foo
from :0
Clearly this is wrong; the negative refs should be ignored.
After this patch:
% git fast-export ^uninteresting ^foo ^bar master
# nothing
% git fast-export master ^uninteresting ^foo ^bar
# nothing
And even more, it would only happen if the ref is pointing to exactly
the same commit, but not otherwise:
% git fast-export ^next next
reset refs/heads/next
from :0
% git fast-export ^next next^{commit}
# nothing
% git fast-export ^next next~0
# nothing
% git fast-export ^next next~1
# nothing
% git fast-export ^next next~2
# nothing
The reason this happens is that before traversing the commits,
fast-export checks if any of the refs point to the same object, and any
duplicated ref gets added to a list in order to issue 'reset' commands
after the traversing. Unfortunately, it's not even checking if the
commit is flagged as UNINTERESTING. The fix of course, is to check it.
However, in order to do it properly we need to get the UNINTERESTING
flag from the command line, not from the commit object, because
"^foo bar" will mark the commit 'bar' uninteresting if foo and bar
points at the same commit. rev_cmdline_info, which was introduced
exactly to handle this situation, contains all the information we
need for get_tags_and_duplicates(), plus the ref flag. This way the
rest of the positive refs will remain untouched; it's only the
negative ones that change in behavior.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- 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>
Do not allow fast-forwarding of references that point to a tag object.
Updating from a tag is potentially destructive since it would likely
leave the tag dangling. Disallowing updates to a tag also makes sense
semantically and is consistent with the behavior of lightweight tags.
Signed-off-by: Chris Rorvick <chris@rorvick.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
References are allowed to update from one commit-ish to another if the
former is an ancestor of the latter. This behavior is oriented to
branches which are expected to move with commits. Tag references are
expected to be static in a repository, though, thus an update to
something under refs/tags/ should be rejected unless the update is
forced.
Signed-off-by: Chris Rorvick <chris@rorvick.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
New remote helper for hg.
* fc/remote-hg: (22 commits)
remote-hg: fix for older versions of python
remote-hg: fix for files with spaces
remote-hg: avoid bad refs
remote-hg: try the 'tip' if no checkout present
remote-hg: fix compatibility with older versions of hg
remote-hg: add missing config for basic tests
remote-hg: the author email can be null
remote-hg: add option to not track branches
remote-hg: add extra author test
remote-hg: add tests to compare with hg-git
remote-hg: add bidirectional tests
test-lib: avoid full path to store test results
remote-hg: add basic tests
remote-hg: fake bookmark when there's none
remote-hg: add compat for hg-git author fixes
remote-hg: add support for hg-git compat mode
remote-hg: match hg merge behavior
remote-hg: make sure the encoding is correct
remote-hg: add support to push URLs
remote-hg: add support for remote pushing
...
General clean-ups in various areas, originally written to support a
patch that later turned out to be unneeded.
* jk/send-email-sender-prompt:
t9001: check send-email behavior with implicit sender
t: add tests for "git var"
ident: keep separate "explicit" flags for author and committer
ident: make user_ident_explicitly_given static
t7502: factor out autoident prerequisite
test-lib: allow negation of prerequisites
Finishing touches to "git rm $submodule" that removes the working
tree of a submodule.
* jl/submodule-rm:
Teach rm to remove submodules when given with a trailing '/'
Clean up completion tests. Use of conslidated helper may make
instrumenting one particular test during debugging of the test
itself, but I think that issue should be addressed in some other
way (e.g. making sure individual tests in 9902 can be skipped).
* fc/completion-test-simplification:
completion: simplify __gitcomp() test helper
completion: refactor __gitcomp related tests
completion: consolidate test_completion*() tests
completion: simplify tests using test_completion_long()
completion: standardize final space marker in tests
completion: add comment for test_completion()
First the expected, then the actual, otherwise the diff would be the
opposite of what we want.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unfortunately a lot of these tests fail.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We don't need a bare 'server' and an intermediary 'public'. The repos
can talk to each other directly; that's what we want to exercise.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was only to cover a bug that was fixed in remote-testpy not to
resurface.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This only makes sense for the python remote helpers framework. The tests
don't exercise any feature of transport helper. Remove them.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Exercising the python remote helper framework is for another tool and
another test. This is about testing the remote-helper interface.
It's way simpler, it exercises the same features of remote helpers, it's
easy to read and understand, and it doesn't depend on python.
For now let's just copy the old remote-helpers test script, although
some of those tests don't make sense. In addition, this script would be
able to test other features not currently being tested.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This script is not really exercising the remote-helper functionality,
but more the python framework for remote helpers that live in
git_remote_helpers.
It's also not a good example of how to write remote-helpers, unless you
are planning to use python, and even then you might not want to use this
framework.
So let's use a more appropriate name: git-remote-testpy.
A patch that replaces git-remote-testgit with a simpler version is on
the way.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The primary thing Linus's patch wanted to change was to make sure
that 0-line change appears for a mode-only change. Update the
first test to chmod a file that we can see in the output (limited
by --stat-count) to demonstrate it. Also make sure to use test_chmod
and compare the index and the tree, so that we can run this test
even on a filesystem without permission bits.
Later two tests are about fixes to separate issues that were
introduced and/or uncovered by Linus's patch as a side effect, but
the issues are not related to mode-only changes. Remove chmod from
the tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Having a ".git" entry inside a tree can cause confusing
results on checkout. At the top-level, you could not
checkout such a tree, as it would complain about overwriting
the real ".git" directory. In a subdirectory, you might
check it out, but performing operations in the subdirectory
would confusingly consider the in-tree ".git" directory as
the repository.
The regular git tools already make it hard to accidentally
add such an entry to a tree, and do not allow such entries
to enter the index at all. Teaching fsck about it provides
an additional safety check, and let's us avoid propagating
any such bogosity when transfer.fsckObjects is on.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We allow send-email to use an implicitly-defined identity
for the sender (because there is still a confirmation step),
but we abort when we cannot generate such an identity. Let's
make sure that we test this.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git p4" used to try expanding malformed "$keyword$" that spans
across multiple lines.
* pw/maint-p4-rcs-expansion-newline:
git p4: RCS expansion should not span newlines
We do not currently have any explicit tests for "git var" at
all (though we do exercise it to some degree as a part of
other tests). Let's add a few basic sanity checks.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A tree with meta-paths like '.' or '..' does not work well
with git; the index will refuse to load it or check it out
to the filesystem (and even if we did not have that safety,
it would look like we were overwriting an untracked
directory). For the same reason, it is difficult to create
such a tree with regular git.
Let's warn about these dubious entries during fsck, just in
case somebody has created a bogus tree (and this also lets
us prevent them from propagating when transfer.fsckObjects
is set).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jh/update-ref-d-through-symref:
Fix failure to delete a packed ref through a symref
t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
Even though we show a separate *UNMERGED* entry in the patch and
diffstat output (or in the --raw format, for that matter) in
addition to and separately from the diff against the specified stage
(defaulting to #2) for unmerged paths, they should not be counted in
the total number of files affected---that would lead to counting the
same path twice.
The separation done by the previous step makes this fix simple and
straightforward. Among the filepairs in diff_queue, paths that
weren't modified, and the extra "unmerged" entries do not count as
total number of files.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The diffstat generation logic, with --stat-count limit, is
implemented as three loops.
- The first counts the width necessary to show stats up to
specified number of entries, and notes up to how many entries in
the data we need to iterate to show the graph;
- The second iterates that many times to draw the graph, adjusts
the number of "total modified files", and counts the total
added/deleted lines for the part that was shown in the graph;
- The third iterates over the remainder and only does the part to
count "total added/deleted lines" and to adjust "total modified
files" without drawing anything.
Move the logic to count added/deleted lines and modified files from
the second loop to the third loop.
This incidentally fixes a bug. The third loop was not filtering
binary changes (counted in bytes) from the total added/deleted as it
should. The second loop implemented this correctly, so if a binary
change appeared earlier than the --stat-count cutoff, the code
counted number of added/deleted lines correctly, but if it appeared
beyond the cutoff, the number of lines would have mixed with the
byte count in the buggy third loop.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a few problems in diff.c around --stat area, partially
caused by the recent 74faaa1 (Fix "git diff --stat" for interesting
- but empty - file changes, 2012-10-17), and largely caused by the
earlier change that introduced when --stat-count was added.
Add a few test pieces to t4049 to expose the issues.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently we keep getting questions even when the user has properly
configured his full name and password:
Who should the emails appear to be from?
[Felipe Contreras <felipe.contreras@gmail.com>]
And once a question pops up, other questions are turned on. This is
annoying.
The reason it's safe to avoid this question is because currently the
script fails completely when the author (or committer) is not correct,
so we won't even be reaching this point in the code.
The scenarios, and the current situation:
1) No information at all, no fully qualified domain name
fatal: empty ident name (for <felipec@nysa.(none)>) not allowed
2) Only full name
fatal: unable to auto-detect email address (got 'felipec@nysa.(none)')
3) Full name + fqdm
Who should the emails appear to be from?
[Felipe Contreras <felipec@nysa.felipec.org>]
4) Full name + EMAIL
Who should the emails appear to be from?
[Felipe Contreras <felipe.contreras@gmail.com>]
5) User configured
6) GIT_COMMITTER
7) GIT_AUTHOR
All these are the same as 4)
After this patch:
1) 2) won't change: git send-email would still die
4) 5) 6) 7) will change: git send-email won't ask the user
This is good, that's what we would expect, because the identity is
explicit.
3) will change: git send-email won't ask the user
This is bad, because we will try with an address such as
'felipec@nysa.felipec.org', which is most likely not what the user
wants, but the user will get warned by default (confirm=auto), and if
not, most likely the sending won't work, which the user would readily
note and fix.
The worst possible scenario is that such mail address does work, and the
user sends an email from that address unintentionally, when in fact the
user expected to correct that address in the prompt. This is a very,
very, very unlikely scenario, with many dependencies:
1) No configured user.name/user.email
2) No specified $EMAIL
3) No configured sendemail.from
4) No specified --from argument
5) A fully qualified domain name
6) A full name in the geckos field
7) A sendmail configuration that allows sending from this domain name
8) confirm=never, or
8.1) confirm configuration not hitting, or
8.2) Getting the error, not being aware of it
9) The user expecting to correct this address in the prompt
In a more likely scenario where 7) is not the case (can't send from
nysa.felipec.org), the user will simply see the mail was not sent
properly, and fix the problem.
The much more likely scenario though, is where 5) is not the case
(nysa.(none)), and git send-email will fail right away like it does now.
So the likelihood of this affecting anybody seriously is very very slim,
and the chances of this affecting somebody slightly are still very
small. The vast majority, if not all, of git users won't be affected
negatively, and a lot will benefit from this.
Tests-by: Jeff King <peff@peff.net>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We want to be able to import, and then export, using the same marks, so
that we don't push things that the other side already received.
Unfortunately, fast-export doesn't store blobs in the marks, but
fast-import does. This creates a mismatch when fast export is reusing a
mark that was previously stored by fast-import.
There is no point in one tool saving blobs, and the other not, but for
now let's just check in fast-export that the objects are indeed commits.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test passes already. Make sure p4 diagnostic errors are displayed.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Error messages that arise during the "p4 print" phase of
generating commits were silently ignored. Catch them,
abort the fast-import, and exit.
Without this fix, the sync/clone appears to work, but files that
are inaccessible by the p4d server will still be imported to git,
although without the proper contents. Instead the errant files
will contain a p4 error message, such as "Librarian checkout
//depot/path failed".
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support for the "p4 move" command was added in 8e9497c (git p4:
add support for 'p4 move' in P4Submit, 2012-07-12), which checks
to make sure that the client and server support the command.
But older versions of p4d may not handle the "-k" argument, and
newer p4d allow disabling "p4 move" with a configuration setting.
Check for both these cases by testing a p4 move command on bogus
filenames and looking for strings in the error messages.
Reported-by: Vitor Antunes <vitor.hda@gmail.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow "git diff --submodule=log" to set to be the default via
configuration.
* rr/submodule-diff-config:
submodule: display summary header in bold
diff: rename "set" variable
diff: introduce diff.submodule configuration variable
Documentation: move diff.wordRegex from config.txt to diff-config.txt
"update-ref -d --deref SYM" to delete a ref through a symbolic ref
that points to it did not remove it correctly.
* jh/update-ref-d-through-symref:
Fix failure to delete a packed ref through a symref
t1400-update-ref: Add test verifying bug with symrefs in delete_ref()
We failed to mention a file without any content change but whose
permission bit was modified, or (worse yet) a new file without any
content in the "git diff --stat" output.
* lt/diff-stat-show-0-lines:
Fix "git diff --stat" for interesting - but empty - file changes
Doing a "git rm submod/" on a submodule results in an error:
fatal: pathspec 'submod/' did not match any files
This is really inconvenient as e.g. using TAB completion in a shell on a
submodule automatically adds the trailing '/' when it completes the path
of the submodule directory. The user has then to remove the '/' herself to
make a "git rm" succeed. Doing a "git rm -r somedir/" is working fine, so
there is no reason why that shouldn't work for submodules too.
Teach git rm to not error out when a '/' is appended to the path of a
submodule. Achieve this by chopping off trailing slashes from the path
names given if they represent directories. Add tests to make sure that
logic only applies to directories and not to files.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Drop duplicate detection from "git-config --get"; this lets it
better match the internal config callbacks, which clears up some
corner cases with includes.
* jk/config-ignore-duplicates:
builtin/config.c: Fix a sparse warning
git-config: use git_config_with_options
git-config: do not complain about duplicate entries
git-config: collect values instead of immediately printing
git-config: fix regexp memory leaks on error conditions
git-config: remove memory leak of key regexp
t1300: test "git config --get-all" more thoroughly
t1300: remove redundant test
t1300: style updates
The MSYS bash mangles arguments that begin with a forward slash
when they are passed to test-wildmatch. This causes tests to fail.
Avoid mangling by prepending "XXX", which is removed by
test-wildmatch before further processing.
[J6t: reworded commit message]
Reported-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
"git config --path $key" segfaulted on "[section] key" (a boolean
"true" spelled without "=", not "[section] key = true").
* cn/config-missing-path:
config: don't segfault when given --path with a missing value
Fixes fetch from servers that ask for auth only during the actual
packing phase. This is not really a recommended configuration, but it
cleans up the code at the same time.
* jk/maint-http-half-auth-fetch:
remote-curl: retry failed requests for auth even with gzip
remote-curl: hoist gzip buffer size to top of post_rpc
"git diff -G<pattern>" did not honor textconv filter when looking
for changes.
* jk/maint-diff-grep-textconv:
diff_grep: use textconv buffers for add/deleted files
Various rfc2047 quoting issues around a non-ASCII name on the From:
line in the output from format-patch have been corrected.
* js/format-2047:
format-patch tests: check quoting/encoding in To: and Cc: headers
format-patch: fix rfc2047 address encoding with respect to rfc822 specials
format-patch: make rfc2047 encoding more strict
format-patch: introduce helper function last_line_length()
format-patch: do not wrap rfc2047 encoded headers too late
format-patch: do not wrap non-rfc2047 headers too early
utf8: fix off-by-one wrapping of text
A symbolic ref refs/heads/SYM was not correctly removed with "git
branch -d SYM"; the command removed the ref pointed by SYM instead.
* rs/branch-del-symref:
branch: show targets of deleted symrefs, not sha1s
branch: skip commit checks when deleting symref branches
branch: delete symref branch, not its target
branch: factor out delete_branch_config()
branch: factor out check_branch_commit()
"git grep -e pattern <tree>" asked the attribute system to read
"<tree>:.gitattributes" file in the working tree, which was
nonsense.
* nd/grep-true-path:
grep: stop looking at random places for .gitattributes
"git log -F -E --grep='<ere>'" failed to use the given <ere>
pattern as extended regular expression, and instead looked for the
string literally.
* 'jc/grep-pcre-loose-ends' (early part):
log --grep: use the same helper to set -E/-F options as "git grep"
revisions: initialize revs->grep_filter using grep_init()
grep: move pattern-type bits support to top-level grep.[ch]
grep: move the configuration parsing logic to grep.[ch]
builtin/grep.c: make configuration callback more reusable
The "say" function in the test scaffolding incorrectly allowed
"echo" to interpret "\a" as if it were a C-string asking for a BEL
output.
* jc/test-say-color-avoid-echo-escape:
test-lib: Fix say_color () not to interpret \a\b\c in the message
