When using a custom format in line termination mode (as opposed to line
separation mode), the configured line terminator is not used, so things
like "git log --pretty=tformat:%H -z" do not work properly.
Make it use the line terminator the user ordered.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, we tested only that "push --quiet --no-progress"
was silent. However, there are many other combinations that
were not tested:
1. no options at all (but stderr as a tty)
2. --no-progress by itself
3. --quiet by itself
4. --progress (when stderr not a tty)
These are tested elsewhere for general "push", but it is
important to test them separately for http. It follows a
very different code path than git://, and options must be
relayed across a remote helper to a separate send-pack
process (and in fact cases (1), (2), and (4) have all been
broken just for http at some point in the past).
We can drop the "--quiet --no-progress" test, as it is not
really interesting (it is already handled by testing them
separately in (2) and (3) above).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
You can already use relative paths in include.path, which
means that including "foo" from your global "~/.gitconfig"
will look in your home directory. However, you might want to
do something clever like putting "~/.gitconfig-foo" in a
specific repository's config file.
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
mksh does not allow $COLUMNS to be set below 12. mksh(1) says that
$COLUMNS is "always set, defaults to 80, unless the value as reported
by stty(1) is non-zero and sane enough". This applies also to setting
it directly for one command:
$ COLUMNS=10 python -c 'import os; print os.environ["COLUMNS"]'
98
Add a test prerequisite by checking if we can set COLUMNS=1, to allow
us to skip tests that needs it.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The shell function that starts git-daemon wants to read the first line of
the daemon's stderr to ensure that it started correctly. Subsequent daemon
errors should be redirected to fd 4 (which is the terminal in verbose mode
or /dev/null in quiet mode). To that end the shell script used 'read' to
get the first line of output, and then 'cat &' to forward everything else
in a background process.
The problem is, that 'cat >&4 &' does not produce any output because the
shell redirects a background process's stdin to /dev/null. To have this
command invocation do anything useful, we have to redirect its stdin
explicitly (which overrides the /dev/null redirection).
The shell function connects the daemon's stderr to its consumers via a
FIFO. We cannot just do this:
read line <git_daemon_output
cat <git_daemon_output >&4 &
because after the first redirection the pipe is closed and the daemon
could receive SIGPIPE if it writes at the wrong moment. Therefore, we open
the readable end of the FIFO only once on fd 7 in the shell and dup from
there to the stdin of the two consumers.
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 PATH contains an unreadable directory, alias expansion code did
not kick in, and failed with an error that said "git-subcmd" was not
found.
By Jeff King (1) and Ramsay Jones (1)
* jk/run-command-eacces:
run-command: treat inaccessible directories as ENOENT
compat/mingw.[ch]: Change return type of exec functions to int
The 'push to upstream' implementation was broken in some corner
cases. "git push $there" without refspec, when the current branch is
set to push to a remote different from $there, used to push to $there
using the upstream information to a remote unreleated to $there.
* jc/push-upstream-sanity:
push: error out when the "upstream" semantics does not make sense
"git clean -d -f" (not "-d -f -f") is supposed to protect nested
working trees of independent git repositories that exist in the
current project working tree from getting removed, but the protection
applied only to such working trees that are at the top-level of the
current project by mistake.
* jc/maint-clean-nested-worktree-in-subdir:
clean: preserve nested git worktree in subdirectories
Rename detection logic used to match two empty files as renames during
merge-recursive, leading unnatural mismerges.
By Jeff King
* jk/diff-no-rename-empty:
merge-recursive: don't detect renames of empty files
teach diffcore-rename to optionally ignore empty content
make is_empty_blob_sha1 available everywhere
drop casts from users EMPTY_TREE_SHA1_BIN
When "git commit --template F" errors out because the user did not
touch the message, it claimed that it aborts due to "empty message",
which was utterly wrong.
By Junio C Hamano (4) and Adam Monsen (1)
* jc/commit-unedited-template:
Documentation/git-commit: rephrase the "initial-ness" of templates
git-commit.txt: clarify -t requires editing message
commit: rephrase the error when user did not touch templated log message
commit: do not trigger bogus "has templated message edited" check
t7501: test the right kind of breakage
"git add -p" is not designed to deal with unmerged paths but did
not exclude them and tried to apply funny patches only to fail.
By Jeff King
* jk/add-p-skip-conflicts:
add--interactive: ignore unmerged entries in patch mode
"git commit --author=$name" did not tell the name that was being
recorded in the resulting commit to hooks, even though it does do so
when the end user overrode the authorship via the "GIT_AUTHOR_NAME"
environment variable.
* jc/commit-hook-authorship:
commit: pass author/committer info to hooks
t7503: does pre-commit-hook learn authorship?
ident.c: add split_ident_line() to parse formatted ident line
The regexp configured with diff.wordregex was incorrectly reused
across files.
By Thomas Rast (2) and Johannes Sixt (1)
* tr/maint-word-diff-regex-sticky:
diff: tweak a _copy_ of diff_options with word-diff
diff: refactor the word-diff setup from builtin_diff_cmd
t4034: diff.*.wordregex should not be "sticky" in --word-diff
Running "notes merge --commit" failed to perform correctly when run
from any directory inside $GIT_DIR/. When "notes merge" stops with
conflicts, $GIT_DIR/NOTES_MERGE_WORKTREE is the place a user edits
to resolve it.
By Johan Herland (3) and Junio C Hamano (1)
* jh/notes-merge-in-git-dir-worktree:
notes-merge: Don't remove .git/NOTES_MERGE_WORKTREE; it may be the user's cwd
notes-merge: use opendir/readdir instead of using read_directory()
t3310: illustrate failure to "notes merge --commit" inside $GIT_DIR/
remove_dir_recursively(): Add flag for skipping removal of toplevel dir
You can feed junk to "git config --rename-section", which
will result in a config file that git will not even parse
(so you cannot fix it with git-config). We already have
syntactic sanity checks when setting a variable; let's do
the same for section names.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test "pushing to local repo" in t5800-remote-helpers can hang
due to a race condition in git-remote-testgit. Fix it by
setting stdin to unbuffered.
On the writer side, "git push" invokes push_refs_with_export(),
which sends to stdout the command "export\n" and immediately
starts up "git fast-export". The latter writes its output stream
to the same stdout.
On the reader side, remote helper "git-remote-testgit" reads from
stdin to get its next command. It uses getc() to read characters
from libc up until \n. Libc has buffered a potentially much
larger chunk of stdin. When it sees the "export\n" command, it
forks "git fast-import" to read the stream.
If fast-export finishes before git fast-import starts, the
fast-export output can end up in libc's buffer in
git-remote-testgit, rather than in git fast-import. The latter
hangs indefinitely on a now-empty stdin.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Exiting from a for-loop early using '|| break' does not propagate the
failure code, and for this reason, the tests used just 'exit'. But this
ends the test script with 'FATAL: Unexpected exit code 1' in the case of
a failed test.
Fix this by moving the loop into a shell function, from which we can
simply return early.
While at it, modernize the style of the affected test cases.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using "\+" in "grep" and expecting that it means one or more
is a GNUism. Spell it in a dumb and portable way.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is used by "git pull" to construct a merge message from list of
remote refs. When pulling redundant set of refs, however, it did not
filter them even though the merge itself discards them as unnecessary.
Teach the command to do the same for consistency.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When COLUMNS or --stat-width restricts the diff-stat width to near the
minimum, 26 columns, the graph_width value becomes negative. Consequently, the
graph part of diff-stat is not resized properly.
Signed-off-by: Lucian Poston <lucian.poston@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of waiting until we record the parents of resulting merge, reduce
redundant parents (including our HEAD) immediately after reading them.
The change to t7602 illustrates the essence of the effect of this change.
The octopus merge strategy used to be fed with redundant commits only to
discard them as "up-to-date", but we no longer feed such redundant commits
to it and the affected test degenerates to a regular two-head merge.
And obviously the known-to-be-broken test in t6028 is now fixed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This happens when git merge is run to merge multiple commits that are
descendants of current HEAD (or are HEAD). We've hit this while updating
master to origin/master but accidentaly we called (while being on master):
$ git merge master origin/master
Here is a minimal testcase:
$ git init a && cd a
$ echo a >a && git add a
$ git commit -minitial
$ echo b >a && git add a
$ git commit -msecond
$ git checkout master^
$ git merge master master
Fast-forwarding to: master
Already up-to-date with master
Merge made by the 'octopus' strategy.
a | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
$ git cat-file commit HEAD
tree eebfed94e75e7760540d1485c740902590a00332
parent bd679e85202280b263e20a57639a142fa14c2c64
author Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 1329132996 +0100
committer Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 1329132996 +0100
Merge branches 'master' and 'master' into HEAD
Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
update_local_ref() used to say "[new branch]" when we stored a new ref
outside refs/tags/ hierarchy, but the message is more about what we
fetched, so use the refname at the origin to make that decision.
Also, only call a new ref a "branch" if it's under refs/heads/.
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adjust tests to verify that the commit history graph tree is taken into
consideration when the diff stat output width is calculated.
Signed-off-by: Lucian Poston <lucian.poston@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add tests which show that the width of the --prefix added by --graph
is not taken into consideration when the diff stat output width is
calculated.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Lucian Poston <lucian.poston@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we pack everything into one big pack with "git repack
-Ad", any unreferenced objects in to-be-deleted packs are
exploded into loose objects, with the intent that they will
be examined and possibly cleaned up by the next run of "git
prune".
Since the exploded objects will receive the mtime of the
pack from which they come, if the source pack is old, those
loose objects will end up pruned immediately. In that case,
it is much more efficient to skip the exploding step
entirely for these objects.
This patch teaches pack-objects to receive the expiration
information and avoid writing these objects out. It also
teaches "git gc" to pass the value of gc.pruneexpire to
repack (which in turn learns to pass it along to
pack-objects) so that this optimization happens
automatically during "git gc" and "git gc --auto".
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Prefer:
test_line_count <OP> COUNT FILE
over:
test $(wc -l <FILE) <OP> COUNT
(or similar usages) in several tests.
Signed-off-by: Stefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is main test case for the original problem that triggered this
patch series. We create a repo with 50k tags and then test whether
git-clone over the smart HTTP protocol succeeds.
Note that we construct the repo in a slightly different way than the
original script used to reproduce the problem. This is because the
original script just created 50k tags all pointing to the same commit,
so if there was a bug where remote-curl.c was not passing all the refs
to fetch-pack we wouldn't know. The clone would succeed even if only one
tag was passed, because all the other tags were pointing at the same SHA
and would be considered present.
Instead we create a repo with 50k independent (dangling) commits and
then tag each of those commits with a unique tag. This way if one of the
tags is not given to fetch-pack, later stages of the clone would
complain about it.
This allows us to test both that the command line overflow was fixed, as
well as that it was fixed in a way that doesn't leave out any of the
refs.
Signed-off-by: Ivan Todoroski <grnch@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These test cases focus only on testing the parsing of refs on stdin,
without bothering with the rest of the fetch-pack machinery. We pass in
the refs using different combinations of command line and stdin and then
we watch fetch-pack's stdout to see whether it prints all the refs we
specified (but we ignore their order).
Signed-off-by: Ivan Todoroski <grnch@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The syntax for the use of mark references in fast-import
demands either a SP (space) or LF (end-of-line) after
a mark reference. Fast-import does not complain when garbage
appears after a mark reference in some cases.
Factor out parsing of mark references and complain if
errant characters are found. Also be a little more careful
when parsing "inline" and SHA1s, complaining if extra
characters appear or if the form of the dataref is unrecognized.
Buggy input can cause fast-import to produce the wrong output,
silently, without error. This makes it difficult to track
down buggy generators of fast-import streams. An example is
seen in the last line of this commit command:
commit refs/heads/S2
committer Name <name@example.com> 1112912893 -0400
data <<COMMIT
commit message
COMMIT
from :1M 100644 :103 hello.c
It is missing a newline and should be:
[...]
from :1
M 100644 :103 hello.c
What fast-import does is to produce a commit with the same
contents for hello.c as in refs/heads/S2^. What the buggy
program was expecting was the contents of blob :103. While
the resulting commit graph looked correct, the contents in
some commits were wrong.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Print out a trailing newline when --show-prefix is run with cwd
at the top level of the tree which results in an empty prefix.
Behavior is now like --show-cdup.
Fixes an expected failure in t1501.
Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
HTTP authentication is currently handled by get_refs and fetch_ref, but
not by fetch_object, fetch_pack or fetch_alternates. In the
single-threaded case, this is not an issue, since get_refs is always
called first. It recognigzes the 401 and prompts the user for
credentials, which will then be used subsequently.
If the curl multi interface is used, however, only the multi handle used
by get_refs will have credentials configured. Requests made by other
handles fail with an authentication error.
Fix this by setting CURLOPT_USERPWD whenever a slot is requested.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Create a repo with multiple loose objects in order to demonstrate http
authentication breakage.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git-rebase--interactive stops due to a conflict and the only change
to be committed is in a submodule, the test for whether there is
anything to be committed ignores the staged submodule change. This
leads rebase to skip creating the commit for the change.
While unstaged submodule changes should be ignored to avoid needing to
update submodules during a rebase, it is safe to remove the
--ignore-submodules option to diff-index because --cached ensures that
it is only checking the index. This was discussed in [1] and a test is
included to ensure that unstaged changes are still ignored correctly.
[1] http://thread.gmane.org/gmane.comp.version-control.git/188713
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/cache-tree:
t0090: be prepared that 'wc -l' writes leading blanks
reset: update cache-tree data when appropriate
commit: write cache-tree data when writing index anyway
Refactor cache_tree_update idiom from commit
Test the current state of the cache-tree optimization
Add test-scrap-cache-tree
* cb/maint-t5541-make-server-port-portable:
t5541: check error message against the real port number used
remote-curl: Fix push status report when all branches fail
* tr/maint-bundle-boundary:
bundle: keep around names passed to add_pending_object()
t5510: ensure we stay in the toplevel test dir
t5510: refactor bundle->pack conversion
* tr/maint-bundle-long-subject:
t5704: match tests to modern style
strbuf: improve strbuf_get*line documentation
bundle: use a strbuf to scan the log for boundary commits
bundle: put strbuf_readline_fd in strbuf.c with adjustments
When execvp reports EACCES, it can be one of two things:
1. We found a file to execute, but did not have
permissions to do so.
2. We did not have permissions to look in some directory
in the $PATH.
In the former case, we want to consider this a
permissions problem and report it to the user as such (since
getting this for something like "git foo" is likely a
configuration error).
In the latter case, there is a good chance that the
inaccessible directory does not contain anything of
interest. Reporting "permission denied" is confusing to the
user (and prevents our usual "did you mean...?" lookup). It
also prevents git from trying alias lookup, since we do so
only when an external command does not exist (not when it
exists but has an error).
This patch detects EACCES from execvp, checks whether we are
in case (2), and if so converts errno to ENOENT. This
behavior matches that of "bash" (but not of simpler shells
that use execvp more directly, like "dash").
Test stolen from Junio.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The user can say "git push" without specifying any refspec. When using
the "upstream" semantics via the push.default configuration, the user
wants to update the "upstream" branch of the current branch, which is the
branch at a remote repository the current branch is set to integrate with,
with this command.
However, there are cases that such a "git push" that uses the "upstream"
semantics does not make sense:
- The current branch does not have branch.$name.remote configured. By
definition, "git push" that does not name where to push to will not
know where to push to. The user may explicitly say "git push $there",
but again, by definition, no branch at repository $there is set to
integrate with the current branch in this case and we wouldn't know
which remote branch to update.
- The current branch does have branch.$name.remote configured, but it
does not specify branch.$name.merge that names what branch at the
remote this branch integrates with. "git push" knows where to push in
this case (or the user may explicitly say "git push $remote" to tell us
where to push), but we do not know which remote branch to update.
- The current branch does have its remote and upstream branch configured,
but the user said "git push $there", where $there is not the remote
named by "branch.$name.remote". By definition, no branch at repository
$there is set to integrate with the current branch in this case, and
this push is not meant to update any branch at the remote repository
$there.
The first two cases were already checked correctly, but the third case was
not checked and we ended up updating the branch named branch.$name.merge
at repository $there, which was totally bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "add -p" sees an unmerged entry, it shows the combined
diff and then immediately skips the hunk. This can be
confusing in a variety of ways, depending on whether there
are other changes to stage (in which case you get the
superfluous combined diff output in between other hunks) or
not (in which case you get the combined diff and the program
exits immediately, rather than seeing "No changes").
The current behavior was not planned, and is just what the
implementation happens to do. Instead, let's explicitly
remove unmerged entries from our list of modified files, and
print a warning that we are ignoring them.
We can cheaply find which entries are unmerged by adding
"--raw" output to the "diff-files --numstat" we already run.
There is one non-obvious thing we must change when parsing
this combined output. Before this patch, when we saw a
numstat line for a file that did not have index changes, we
would create a new record with 'unchanged' in the 'INDEX'
field. Because "--raw" comes before "--numstat", we must
move this special-case down to the raw-line case (and it is
sufficient to move it rather than handle it in both places,
since any file which has a --numstat will also have a --raw
entry).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the user exited editor without editing the commit log template given
by "git commit -t <template>", the commit was aborted (correct) with an
error message that said "due to empty commit message" (incorrect).
This was because the original template support was done by piggybacking on
the check to detect an empty log message. Split the codepaths into two
independent checks to clarify the error.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "-t template" and "-F msg" options are both given (or worse yet,
there is "commit.template" configuration but a message is given in some
other way), the documentation says that template is ignored. However,
the "has the user edited the message?" check still used the contents of
the template file as the basis of the emptyness check.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests try to run "git commit" with various "forbidden" combinations
of options and expect the command to fail, but they do so without having
any change added to the index. We wouldn't be able to catch breakages
that would allow these combinations by mistake with them because the
command will fail with "nothing to commit" anyway.
Make sure we have something added to the index before running the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The http-backend program sets default GIT_COMMITTER_NAME and
GIT_COMMITTER_EMAIL variables based on the REMOTE_USER and
REMOTE_ADDR variables provided by the webserver. However, it
unconditionally overwrites any existing GIT_COMMITTER
variables, which may have been customized by site-specific
code in the webserver (or in a script wrapping http-backend).
Let's leave those variables intact if they already exist,
assuming that any such configuration was intentional. There
is a slight chance of a regression if somebody has set
GIT_COMMITTER_* for the entire webserver, not intending it
to leak through http-backend. We could protect against this
by passing the information in alternate variables. However,
it seems unlikely that anyone will care about that
regression, and there is value in the simplicity of using
the common variable names that are used elsewhere in git.
While we're tweaking the environment-handling in
http-backend, let's switch it to use argv_array to handle
the list of variables. That makes the memory management much
simpler.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
$COLUMNS must be unset to not interfere with the tests. The tests
already ignore the terminal size because output is redirected to a
file, but COLUMNS overrides terminal size detection and changes the
test output away from the standard 80.
Reported-by: Jeff King <peff@peff.net>
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
