This attempts to fix a regression in git-commit, where non-abbreviated
SHA-1s were printed in the summary.
One possible fix would be to set ctx.abbrev to DEFAULT_ABBREV in the
`if` block, where format_commit_message() is used.
Instead, we do away with the format_commit_message() codeblock
altogether, replacing it with a re-run of log_tree_commit().
We re-run log_tree_commit() with rev.always_show_header set, to force
the invocation of show_log(). The effect of this flag can be seen from
this excerpt from log-tree.c:560, the only area that
rev.always_show_header is checked:
shown = log_tree_diff(opt, commit, &log);
if (!shown && opt->loginfo && opt->always_show_header) {
log.parent = NULL;
show_log(opt);
shown = 1;
}
We also set rev.use_terminator, so that a newline is appended at the end
of the log message. Note that callers in builtin/log.c that also set
rev.always_show_header don't have to set rev.use_terminator, but still
get a newline, because they are wrapped in a pager.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
9c7304e (print the usage string on stdout instead of stderr,
2010-05-17) broke rev-parse --parseopt: when run with -h, the usage
notice on stdout ended up in the shell eval.
Wrap the usage in a cat <<\EOF ... EOF block when printing to stdout.
I do not expect any usage lines to ever start with EOF so this
shouldn't be an undue burden.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suppose you want to edit all files that contain a specific search term.
Of course, you can do something totally trivial such as
git grep -z -e <term> | xargs -0r vi +/<term>
but maybe you are happy that the same will be achieved by
git grep -Ovi <term>
now.
[jn: rebased and added tests]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds an option to open the matching files in the pager, and if the
pager happens to be "less" (or "vi") and there is only one grep pattern,
it also jumps to the first match right away.
The short option was chose as '-O' to avoid clashes with GNU grep's
options (as suggested by Junio).
So, 'git grep -O abc' is a short form for 'less +/abc $(grep -l abc)'
except that it works also with spaces in file names, and it does not
start the pager if there was no matching file.
[jn: rebased and added tests; with error handling fix from Junio
squashed in]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a --count option that, instead of actually listing the commits,
merely counts them.
This is mostly geared towards script use, and to this end it acts
specially when used with --left-right: it outputs the left and right
counts separately. Previously, scripts would have to run a shell loop
or small inline script over to achieve the same. (Without
--left-right, a simple |wc -l does the job.)
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We've had this option since f423ef5 (tests: allow user to specify
trash directory location, 2009-08-09). Make it easier to look up :-)
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise running individual tests from t/ directory may lack the definition
of $DIFF, $GIT_TEST_CMP and friends.
Noticed and initial patch provided by Thomas Rast, alternative solution
suggested by Brandon Casey, which this patch implements.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Thomas Rast <trast@student.ethz.ch>
In some use cases it is not desirable that the diff family considers
submodules that only contain untracked content as dirty. This may happen
e.g. when the submodule is not under the developers control and not all
build generated files have been added to .gitignore by the upstream
developers. Using the "untracked" parameter for the "--ignore-submodules"
option disables checking for untracked content and lets git diff report
them as changed only when they have new commits or modified content.
Sometimes it is not wanted to have submodules show up as changed when they
just contain changes to their work tree. An example for that are scripts
which just want to check for submodule commits while ignoring any changes
to the work tree. Also users having large submodules known not to change
might want to use this option, as the - sometimes substantial - time it
takes to scan the submodule work tree(s) is saved.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 86140d5 the new test t4041-diff-submodule.sh was introduced although
t4027-diff-submodule.sh already existed. Rename the newer test to
t4041-diff-submodule-option.sh to fix that.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Untracked content in the working tree may prevent rebase -i from checking out
the new base onto which it wants to replay commits, if the new base commit
includes files at those (now untracked) paths. Currently, rebase -i dies
uncleanly in this situation, updating ORIG_HEAD and leaving a useless
.git/rebase-merge directory, with which the user can do nothing useful except
rebase --abort. Make rebase -i abort the procedure itself instead, as
non-interactive rebase already does, and add a test for this behavior.
Signed-off-by: Ian Ward Comfort <icomfort@stanford.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When one side of a merge turns a directory into a submodule, and the other
side does not touch that directory (but has other non-conflicting changes),
then a merge should succeed. But currently, it does not; it rather fails
with a file/directory conflict.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rebase --preserve-merges facility presents a list of commits
in its instruction sheet and uses a separate table to keep
track of their parents. Unfortunately, in practice this means
that with -p after most attempts to rearrange patches, some
commits have the "wrong" parent and the resulting history is
rarely what the caller expected.
Yes, it would be nice to fix that. But first, add a warning to the
manual to help the uninitiated understand what is going on.
Reported-by: Jiří Paleček <jpalecek@web.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a new configuration variable, "core.eol", that allows the user
to set which line endings to use for end-of-line-normalized files in the
working directory. It defaults to "native", which means CRLF on Windows
and LF everywhere else.
Note that "core.autocrlf" overrides core.eol. This means that
[core]
autocrlf = true
puts CRLFs in the working directory even if core.eol is set to "lf".
Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A bug was introduced in 3e97c7c6af
(No diff -b/-w output for all-whitespace changes, Nov 19 2009)
that made the lines:
diff --git a/bar b/sub/bar
similarity index 100%
rename from bar
rename to sub/bar
disappear from "git show -C -C" output when file bar is a binary
file.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using --ancestry-path together with history simplification (typically
triggered by path limiting), history simplification would get in the way of
--ancestry-path by prematurely removing the parent links between commits on
which the ancestry path calculations are made.
This patch disables this history simplification when --ancestry-path is
enabled. This is similar to what e.g. --full-history already does.
The patch also includes a simple testcase verifying that --ancestry-path
works together with path limiting.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git ls-files used to error out if given paths which point outside the current
working directory, such as '../'. We now allow such paths and the output is
analogous to git grep -l.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default reflogs are always created for new local branches by
"checkout -b". But by setting core.logAllRefUpdates to false this will
not be true anymore.
In that case you only create the reflogs when you use -l switch with
"checkout -b".
Added missing tests to check expected behaviors.
Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Added changes to satisfy a corner case: creating reflogs by using -l
when core.logAllRefUpdates is set to false.
Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The UTF-8 prerequisite test checked explicitly for en_US.utf8 in the
output from "locale -a", but the tests that are actually protected by the
prerequisite were asking LC_ALL=en_US.UTF-8 from the system.
This inconsistency leads the tests to fail on platforms that do not know
both en_US.UTF-8 and en_US.utf8 (thanks you, Yann Droneaud, for bringing
this up with an initial patch).
Instead, pick a locale with ".UTF-8" (with or without hyphen, spelled in
either upper or lowercase) in its name from "locale -a" output, and use it
for running the test.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Note that there is an expected failure when running:
git cherry-pick -3 fourth
that's because:
git rev-list --no-walk -3 fourth
produce only one commit and not 3 as "--no-walk" seems to
take over "-3".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
IRIX 6.5 has a default maximum argument list length of 20480. The file
glob that is passed to aggregate-results currently exceeds this length, and
so the script cannot run successfully. Work around this issue by passing
the file names in via the standard input rather than the argument list.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The unset builtin of Solaris's xpg4/sh returns non-zero if it is passed a
variable name which was not previously set. Since the unset is not likely
to fail, ignore its return status, but add a semicolon as a clue that the
'&&' was deliberately left off.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Solaris's xpg4/sed and IRIX's sed fail to parse these negated matching
expressions when the '!' is separated from the command that follows.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test script depends on the git-remote-testgit python script. This
python script makes use of the hashlib module which was released in python
version 2.5. So, add a new pre-requisite named PYTHON_2_5_OR_NEWER to
test-lib.sh and check for it in t5800.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When -h is used, print usage messages on stdout. If a command is invoked with
wrong arguments then print the usage messages on stderr.
Signed-off-by: Giuseppe Scrivano <gscrivano@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Create a new subdirectory called 'static' in gitweb/, and move
all static files required by gitweb.cgi when running, which means
styles, images and Javascript code. This should make gitweb more
readable and easier to maintain.
Update t/gitweb-lib.sh to reflect this change.The install-gitweb
now also include moving of static files into 'static' subdirectory
in target directory: update Makefile, gitweb's INSTALL, README and
Makefile accordingly.
Signed-off-by: Pavan Kumar Sunkara <pavan.sss1991@gmail.com>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Mentored-by: Petr Baudis <pasky@ucw.cz>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Strip out options before checking for a missing upstream argument.
Before:
$ git rebase -m
shift: 426: can't shift that many
After:
$ git rebase -m
Usage: git rebase ...
While at it, fix the usage message to explain that the upstream
argument is mandatory.
Reported-by: Jon Dowland <jmtd@debian.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the metainfo section of git diffs there's an "index" line providing
abbreviated (unless --full-index is used) blob SHA1s from the
pre-/post-images used to generate the diff. These provide hints that
can be used to reconstruct a 3-way merge when applying the patch
(see the --3way option to 'git am' for more details).
In order for this to work, however, the blob SHA1s must not be
abbreviated into ambiguity.
This patch eliminates the possible ambiguity by using find_unique_abbrev()
to produce the abbreviated SHA1s (instead of blind abbreviation by way of
"%.*s").
A testcase verifying the fix is also included.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default the testsuite calls 'diff -u' whenever a file comparison is
called for. Unfortunately that throws a "diff: unknown option '-u'"
error for most non-GNU diffs.
This patch sets GIT_TEST_CMP to 'cmp' on all the architectures where
that happens. The previous version of this patch forgot to export
GIT_TEST_CMP from t/Makefile, which is why 'make test' continued to
fail most tests on most architectures - test-lib.sh was falling back
on its default of `diff -u' for GIT_TEST_CMP. This version of this
patch shows a vast improvement in testsuite results where either GNU
diff is in the path at configure time, or where Makefile knows that
GIT_TEST_CMP=cmp is required.
Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In tests, call test_cmp rather than raw diff where possible (i.e. if
the output does not go to a pipe), to allow the use of, say, 'cmp'
when the default 'diff -u' is not compatible with a vendor diff.
When that is not possible, use $DIFF, as set in GIT-BUILD-OPTIONS.
Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Makefile: reenable install with NO_CURL
completion: --set-upstream option for git-branch
get_cwd_relative(): do not misinterpret suffix as subdirectory
After c197702 (pretty: Respect --abbrev option), non-abbreviated hashes
began to appear, leading to failures for these tests.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
daae1922 (fsck: check ident lines in commit objects, 2010-04-24)
taught fsck to expect commit objects to have the form
tree <object name>
<parents>
author <valid ident string>
committer <valid ident string>
log message
The check is overly strict: for example, it errors out with the
message “expected blank line” for perfectly valid commits with an
"encoding ISO-8859-1" line.
Later it might make sense to teach fsck about the rest of the header
and warn about unrecognized header lines, but for simplicity, let’s
accept arbitrary trailing lines for now.
Reported-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the current working directory is the same as the work tree path
plus a suffix, e.g. 'work' and 'work-xyz', then the suffix '-xyz'
would be interpreted as a subdirectory of 'work'.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Documentation/SubmittingPatches: clarify GMail section and SMTP
show-branch: use DEFAULT_ABBREV instead of 7
t7502-commit: fix spelling
test get_git_work_tree() return value for NULL
Add a $toplevel variable accessible to `git submodule foreach`, it
contains the absolute path of the top level directory (where
.gitmodules is).
This makes it possible to e.g. read data in .gitmodules from within
foreach commands. I'm using this to configure the branch names I want
to track for each submodule:
git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
For a little history: This patch is borne out of my continuing fight
of trying to have Git track the branches of submodules, not just their
commits.
Obviously that's not how they work (they only track commits), but I'm
just interested in being able to do:
git submodule foreach 'git pull'
Of course that won't work because the submodule is in a disconnected
head, so I first have to connect it, but connect it *to what*.
For a while I was happy with this because as fate had it, it just so
happened to do what I meant:
git submodule foreach 'git checkout $(git describe --all --always) && git pull'
But then that broke down, if there's a tag and a branch the tag will
win out, and I can't git pull a branch:
$ git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/master
$ git tag -l
release-0.0.6
$ git describe --always --all
release-0.0.6
So I figured that I might as well start tracking the branches I want
in .gitmodules itself:
[submodule "yaml-mode"]
path = yaml-mode
url = git://github.com/yoshiki/yaml-mode.git
branch = master
So now I can just do (as stated above):
git submodule foreach 'git checkout $(git config --file $toplevel/.gitmodules submodule.$name.branch) && git pull'
Maybe there's a less painful way to do *that* (I'd love to hear about
it). But regardless of that I think it's a good idea to be able to
know what the top-level is from git submodule foreach.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We generally treat these as equivalent to "/path/to/repo"
and "host:path_to_repo" respectively. However, they are URLs
and as such may be percent-encoded. The current code simply
uses them as-is without any decoding.
With this patch, we will now percent-decode any file:// or
ssh:// url (or ssh+git, git+ssh, etc) at the transport
layer. We continue to treat plain paths and "host:path"
syntax literally.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Search patterns in a file specified with -f can contain NUL characters.
The current code ignores all characters on a line after a NUL.
Pass the actual length of the line all the way from the pattern file to
fixmatch() and use it for case-sensitive fixed string matching.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactor REG_STARTEND handling inlook_ahead() into a new helper,
regmatch(), and use it for line matching, too. This allows regex
matching beyond NUL characters if regexec() supports the flag. NUL
characters themselves are not matched in any way, though.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Functions for C strings, like strcasestr(), can't see beyond NUL
characters. Check if there is such an obstacle on the line and try
again behind it.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow searching beyond NUL characters by using memmem() instead of
strstr().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As with the option -c/--count, git grep with the option -l/--name-only
should work the same with binary files as with text files because
there is no danger of messing up the terminal with control characters
from the contents of matching files. GNU grep does the same.
Move the check for ->name_only before the one for binary_match_only,
thus making the latter irrelevant for git grep -l.
Reported-by: Dmitry Potapov <dpotapov@gmail.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The intent of showing the message "Binary file xyz matches" for
binary files is to avoid annoying users by potentially messing up
their terminals by printing control characters. In --count mode,
this precaution isn't necessary.
Display counts of matches if -c/--count was specified, even if -a
was not given. GNU grep does the same.
Moving the check for ->count before the code for handling binary
file also avoids printing context lines if --count and -[ABC] were
used together, so we can remove the part of the comment that
mentions this behaviour. Again, GNU grep does the same.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* by/log-follow:
tests: rename duplicate t4205
Make git log --follow find copies among unmodified files.
Make diffcore_std only can run once before a diff_flush
Add a macro DIFF_QUEUE_CLEAR.
* cb/maint-stash-orphaned-file:
stash tests: stash can lose data in a file removed from the index
stash: Don't overwrite files that have gone from the index
* jn/gitweb-caching-prep:
gitweb: Move generating page title to separate subroutine
gitweb: Add custom error handler using die_error
gitweb: Use nonlocal jump instead of 'exit' in die_error
gitweb: href(..., -path_info => 0|1)
Export more test-related variables when running external tests
* jn/request-pull:
tests: chmod +x t5150
adapt request-pull tests for new pull request format
t5150: protect backslash with backslash in shell
request-pull: protect against OPTIONS_KEEPDASHDASH from environment
tests for request-pull
* jn/shortlog:
pretty: Respect --abbrev option
shortlog: Document and test --format option
t4201 (shortlog): Test output format with multiple authors
t4201 (shortlog): guard setup with test_expect_success
Documentation/shortlog: scripted users should not rely on implicit HEAD
* js/maint-receive-pack-symref-alias:
t5516-fetch-push.sh: style cleanup
receive-pack: detect aliased updates which can occur with symrefs
receive-pack: switch global variable 'commands' to a parameter
Conflicts:
t/t5516-fetch-push.sh
* sp/maint-dumb-http-pack-reidx:
http.c::new_http_pack_request: do away with the temp variable filename
http-fetch: Use temporary files for pack-*.idx until verified
http-fetch: Use index-pack rather than verify-pack to check packs
Allow parse_pack_index on temporary files
Extract verify_pack_index for reuse from verify_pack
Introduce close_pack_index to permit replacement
http.c: Remove unnecessary strdup of sha1_to_hex result
http.c: Don't store destination name in request structures
http.c: Drop useless != NULL test in finish_http_pack_request
http.c: Tiny refactoring of finish_http_pack_request
t5550-http-fetch: Use subshell for repository operations
http.c: Remove bad free of static block
* jc/maint-no-reflog-expire-unreach-for-head:
reflog --expire-unreachable: special case entries in "HEAD" reflog
more war on "sleep" in tests
Document gc.<pattern>.reflogexpire variables
Conflicts:
Documentation/config.txt
* sp/maint-describe-tiebreak-with-tagger-date:
describe: Break annotated tag ties by tagger date
tag.c: Parse tagger date (if present)
tag.c: Refactor parse_tag_buffer to be saner to program
tag.h: Remove unused signature field
tag.c: Correct indentation
* sr/remote-helper-export:
t5800: testgit helper requires Python support
Makefile: Simplify handling of python scripts
remote-helpers: add tests for testgit helper
remote-helpers: add testgit helper
remote-helpers: add support for an export command
remote-helpers: allow requesing the path to the .git directory
fast-import: always create marks_file directories
clone: also configure url for bare clones
clone: pass the remote name to remote_get
Conflicts:
Makefile
* ar/config-from-command-line:
Complete prototype of git_config_from_parameters()
Use strbufs instead of open-coded string manipulation
Allow passing of configuration parameters in the command line
* maint:
Fix checkout of large files to network shares on Windows XP
start_command: close cmd->err descriptor when fork/spawn fails
Fix "Out of memory? mmap failed" for files larger than 4GB on Windows
Bigger writes to network drives on Windows XP fail. Cap them at 31MB to
allow them to succeed. Callers need to be prepared for write() calls
that do less work than requested anyway.
On local drives, write() calls are translated to WriteFile() calls with
a cap of 64KB on Windows XP and 256KB on Vista. Thus a cap of 31MB won't
affect the number of WriteFile() calls which do the actual work. There's
still room for some other version of Windows to use a chunk size of 1MB
without increasing the number of system calls.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix the problem where the cmd->err passed into start_command wasn't
being properly closed when certain types of errors occurr. (Compare
the affected code with the clean shutdown code later in the function.)
On Windows, this problem would be triggered if mingw_spawnvpe()
failed, which would happen if the command to be executed was malformed
(e.g. a text file that didn't start with a #! line). If cmd->err was
a pipe, the failure to close it could result in a hang while the other
side was waiting (forever) for either input or pipe close, e.g. while
trying to shove the output into the side band. On msysGit, this
problem was causing a hang in t5516-fetch-push.
[J6t: With a slight adjustment of the test case, the hang is also
observed on Linux.]
Signed-off-by: bert Dvornik <dvornik+git@gmail.com>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce -n and -v options for "git notes prune" in complete analogy to
"git prune" so that one can check for dangling notes easily.
The output is a list of names of objects whose notes would be resp.
are removed so that one can check the object ("git show sha1") as well as
the note ("git notes show sha1").
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add ‘git remote set-branches’ for changing the list of tracked refs
for a remote repository with one "porcelain-level" command. This
complements the longstanding ‘git remote add --track’ option.
The interface is based on the ‘git remote set-url’ subcommand.
git remote set-branches base --add C
git remote set-branches base A B D
git remote set-branches base --delete D; # not implemented
Suggested-by: martin f. krafft <madduck@debian.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As discussed on the list, "crlf" is not an optimal name. Linus
suggested "text", which is much better.
Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the semantics of the "crlf" attribute so that it enables
end-of-line normalization when it is set, regardless of "core.autocrlf".
Add a new setting for "crlf": "auto", which enables end-of-line
conversion but does not override the automatic text file detection.
Add a new attribute "eol" with possible values "crlf" and "lf". When
set, this attribute enables normalization and forces git to use CRLF or
LF line endings in the working directory, respectively.
The line ending style to be used for normalized text files in the
working directory is set using "core.autocrlf". When it is set to
"true", CRLFs are used in the working directory; when set to "input" or
"false", LFs are used.
Signed-off-by: Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a :short modifier to objectname which outputs the abbreviated
object name.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Reviewed-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, autocrlf would only work well for normalized
repositories. Any text files that contained CRLF in the repository
would cause problems, and would be modified when handled with
core.autocrlf set.
Change autocrlf to not do any conversions to files that in the
repository already contain a CR. git with autocrlf set will never
create such a file, or change a LF only file to contain CRs, so the
(new) assumption is that if a file contains a CR, it is intentional,
and autocrlf should not change that.
The following sequence should now always be a NOP even with autocrlf
set (assuming a clean working directory):
git checkout <something>
touch *
git add -A . (will add nothing)
git commit (nothing to commit)
Previously this would break for any text file containing a CR.
Some of you may have been folowing Eyvind's excellent thread about
trying to make end-of-line translation in git a bit smoother.
I decided to attack the problem from a different angle: Is it possible
to make autocrlf behave non-destructively for all the previous problem cases?
Stealing the problem from Eyvind's initial mail (paraphrased and
summarized a bit):
1. Setting autocrlf globally is a pain since autocrlf does not work well
with CRLF in the repo
2. Setting it in individual repos is hard since you do it "too late"
(the clone will get it wrong)
3. If someone checks in a file with CRLF later, you get into problems again
4. If a repository once has contained CRLF, you can't tell autocrlf
at which commit everything is sane again
5. autocrlf does needless work if you know that all your users want
the same EOL style.
I belive that this patch makes autocrlf a safe (and good) default
setting for Windows, and this solves problems 1-4 (it solves 2 by being
set by default, which is early enough for clone).
I implemented it by looking for CR charactes in the index, and
aborting any conversion attempt if this is found.
Signed-off-by: Finn Arne Gangstad <finag@pvv.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After 9c00de5 (ls-remote: fall-back to default remotes when no remote
specified), when no repository is specified, ls-remote may use
the URL/remote in the config "branch.<name>.remote" or the remote
"origin"; it may not be immediately obvious to the user which was used.
In such cases, print a simple "From <URL>" line to indicate which
repository was used. This message is similar to git-fetch's, and is
printed to stderr to avoid breaking existing scripts that depend on
ls-remote's output behaviour.
It can also be disabled with -q/--quiet.
Modify tests related to falling back on default remotes to check for
this as well, and add a test to check for suppression of the message.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the user specifies a message, use fmt_merge_msg_shortlog() to
append the shortlog.
Previously, when a message was specified, we ignored the merge title
("Merge <foo> into <bar>") and shortlog from fmt_merge_msg().
Update the documentation for -m to reflect this too.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we know we are creating a bare repository, we use setenv
to set the GIT_DIR directory to the current directory
(either where we already were, or one we created and chdir'd
into with "git init --bare <dir>").
However, with "git --bare init <dir>" (note the --bare as a
git wrapper option), the setup code actually sets GIT_DIR
for us, but it uses the wrong, original cwd when a directory
is given. Because our setenv does not use the overwrite
flag, it is ignored.
We need to set the overwrite flag, but only when we are
given a directory on the command line. That still allows:
GIT_DIR=foo.git git init --bare
to work. The behavior is changed for:
GIT_DIR=foo.git git init --bare bar.git
which used to create the repository in foo.git, but now will
use bar.git. This is more sane, as command line options
should generally override the environment.
Noticed by Oliver Hoffmann.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-check-ref-format(1) describes names which
cannot be used as refnames for git. Some are
legal branchnames in subversion however.
Mangle the not yet handled cases.
Signed-off-by: Torsten Schmutzler <git-ts@theblacksun.eu>
Acked-by: Eric Wong <normalperson@yhbt.net>
* rc/maint-curl-helper:
remote-curl: ensure that URLs have a trailing slash
http: make end_url_with_slash() public
t5541-http-push: add test for URLs with trailing slash
Conflicts:
remote-curl.c
* hg/maint-attr-fix:
attr: Expand macros immediately when encountered.
attr: Allow multiple changes to an attribute on the same line.
attr: Fixed debug output for macro expansion.
* mh/status-optionally-refresh:
t7508: add a test for "git status" in a read-only repository
git status: refresh the index if possible
t7508: add test for "git status" refreshing the index
* cw/ws-indent-with-tab:
whitespace: tests for git-apply --whitespace=fix with tab-in-indent
whitespace: add tab-in-indent support for --whitespace=fix
whitespace: replumb ws_fix_copy to take a strbuf *dst instead of char *dst
whitespace: tests for git-diff --check with tab-in-indent error class
whitespace: add tab-in-indent error class
whitespace: we cannot "catch all errors known to git" anymore
* jk/cached-textconv:
diff: avoid useless filespec population
diff: cache textconv output
textconv: refactor calls to run_textconv
introduce notes-cache interface
make commit_tree a library function
* pc/remove-warn:
Remove a redundant errno test in a usage of remove_path
Introduce remove_or_warn function
Implement the rmdir_or_warn function
Generalise the unlink_or_warn function
stripspace/text-based formatting kicks in when specifying the notes
content with -m or -F, or when an editor is used to edit the notes.
To binary-safely create notes from files, the following construct is
required:
git notes add -C $(git hash-object -w <file>) <object>
Explain this trick (thanks, Johan!) in the manual. Add an ordinary
example, too, to keep this esoteric one company.
Cc: Johan Herland <johan@herland.net>
Cc: Thomas Rast <trast@student.ethz.ch>
Cc: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously the test would print to stdout which interfered with the
TAP output. Now this scaffolding code is just a normal test.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The naming of this test library conflicted with the recommendation in
t/README's "Naming Tests" section.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
10eb0007 (request-pull: avoid mentioning that the start point is a
single commit, 2010-01-29), changed the pull request format, so the
test needs some changes to still pass:
- tolerate a missing blank line between “in the git repository at:”
and the name of repository and branch
- recognize subject and date in the new request format
- update the expected request template to match the new format
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At least /bin/sh on FreeBSD 8 interprets backslash followed by newline in an
unquoted here text as "empty".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git log --follow <path>' don't track copies from unmodified
files, and this patch fix it.
Signed-off-by: Bo Yang <struggleyb.nku@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, status gives a lot of hints even when advice.statusHints is
false. Change this so that all hints depend on the config variable.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
edf563f (status: make "how to stage" messages optional, 2009-09-09)
introduced advice.statusHints without tests. Add a few tests to describe
and test the status quo.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 3bf7886 (test-lib: Let tests specify commands to be run at end of
test, 2010-05-02), the git test harness learned to run cleanup
commands unconditionally at the end of a test. During each test,
the intended cleanup actions are collected in the test_cleanup variable
and evaluated. That variable looks something like this:
eval_ret=$?; clean_something && (exit "$eval_ret")
eval_ret=$?; clean_something_else && (exit "$eval_ret")
eval_ret=$?; final_cleanup && (exit "$eval_ret")
eval_ret=$?
All cleanup actions are run unconditionally but if one of them fails
it is properly reported through $eval_ret.
On FreeBSD, unfortunately, $? is set at the beginning of an ‘eval’
to 0 instead of the exit status of the previous command. This results
in tests using test_expect_code appearing to fail and all others
appearing to pass, unless their cleanup fails. Avoid the problem by
setting eval_ret before the ‘eval’ begins.
Thanks to Jeff King for the explanation.
Cc: Jeff King <peff@peff.net>
Cc: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Prior to this, the output of git log -1 --format=%h was always 7
characters long, without regard to whether --abbrev had been passed.
Signed-off-by: Will Palmer <wmpalmer@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not document the --pretty synonym, since it takes too long to
explain the name to people.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Follow the current prevailing style. This also has the benefit of
capturing any stray output and noticing if any of the setup commands
start failing.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Though I have not seen this in the wild, it has been said that there
are likely to be git repositories converted from other version control
systems with an invalid ident line like this one:
author <user@example.com> 18746342 +0000
Because there is no space between the (empty) user name and the email
address, commit --amend chokes. When searching for a
space-left-bracket sequence on the ident line, it finds it in the
committer line, ending up utterly confused.
Better for commit --amend to treat this like a valid ident line with
empty username and complain.
The tests remove the questionable commit objects after use so there is
no chance for them to confuse later tests.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Certain actions can imply that if the test fails early, recovery from
within other tests is too much to expect:
- creating unwritable directories, like the EACCESS test in t0001-init
- setting unusual configuration, like user.signingkey in t7004-tag
- crashing and leaving the index lock held, like t3600-rm once did
Some test scripts work around this by running cleanup actions outside
the supervision of the test harness, with the unfortunate consequence
that those commands are not appropriately echoed and their output not
suppressed. Others explicitly save exit status, clean up, and then
reset the exit status within the tests, which has excellent behavior
but makes the tests hard to read. Still others ignore the problem.
Allow tests a fourth option: by calling this function, tests can
stack up commands they would like to be run to clean up.
Commands passed to test_when_finished during a test are
unconditionally run in the test environment immediately before the
test is completed, in last-in-first-out order. If some cleanup
command fails, then the other cleanup commands are still run before
the failure is reported and the test script allowed to continue.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, a local git clone reports only initializing an empty
git dir, which is potentially confusing.
Instead, report that cloning is in progress and when it is done
(unless -q) is given, and suppress the init report.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Dear Junio,
this is a resend of relicensing patch for test suite library, which
was initially sent by Carl Worth. Since the time you sent me acks for
this patch collected by you, I collected 8 additional acks as is
documented at
https://git.wiki.kernel.org/index.php/Test-lib_reclicensing. There are
still three contributors missing: Bert Wesarg, Stephan Beyer and Bryan
Donlan. The contributions of first two are clearly not copyrightable.
I'm not sure about the copyrightability of Bryan Donlan's
contributions (git log -p --author='Bryan Donlan' t/test-lib.sh).
Carl told me that in your ack collection process you missed only three
acks. So I wonder whether you already did some analysis of which
contributions are copyrightable. If so, are the missing acks in the
list bellow?
Thanks
Michal
8<--------8<--------8<--------
This file has had no explicit license information noted in it, but
has clearly been created and modified according to the terms of GPLv2
as with the rest of the git code base.
The purpose of relicensing is to allow other GPLv3+ projects (in
particular, the notmuch project: http://notmuchmail.org) to use this
same test-suite structure and to contribute changes back as well.
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Acked-by: Brandon Casey <drafnel@gmail.com>
Acked-by: Clemens Buchacher <drizzd@aon.at>
Acked-by: David Reiss <dreiss@facebook.com>
Acked-by: Emil Sit <sit@emilsit.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Acked-by: Fredrik Kuivinen <frekui@gmail.com>
Acked-by: Gerrit Pape <pape@smarden.org>
Acked-by: Christian Couder <chriscool@tuxfamily.org>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Acked-by: Johan Herland <johan@herland.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Acked-by: Josh Triplett <josh@joshtriplett.org>
Acked-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Lea Wiemann <lewiemann@gmail.com>
Acked-by: Markus Heidelberg <markus.heidelberg@web.de>
Acked-by: Martin Waitz <tali@admingilde.org>
Acked-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Acked-by: Matthias Lederhofer <matled@gmx.net>
Acked-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Michele Ballabio <barra_cuda@katamail.com>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Acked-by: Pavel Roskin <proski@gnu.org>
Acked-by: Petr Baudis <pasky@ucw.cz>
Acked-by: Pierre Habouzit <madcoder@debian.org>
Acked-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
Acked-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
previously the only ways to alias a --pretty format within git were
either to set the format as your default format (via the format.pretty
configuration variable), or by using a regular git alias. This left the
definition of more complicated formats to the realm of "builtin or
nothing", with user-defined formats usually being reserved for quick
one-offs.
Here we allow user-defined formats to enjoy more or less the same
benefits of builtins. By defining pretty.myalias, "myalias" can be
used in place of whatever would normally come after --pretty=. This
can be a format:, tformat:, raw (ie, defaulting to tformat), or the name
of another builtin or user-defined pretty format.
Signed-off-by: Will Palmer <wmpalmer@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This refactoring (adding guess_file_syntax and run_highlighter
subroutines) is meant to make it easier in the future to add support
for other syntax highlighing solutions, or make it smarter by not
re-running `git cat-file` second time.
Instead of looping over list of regexps (keys of %highlight_type hash),
make use of the fact that choosing syntax is based either on full
basename (%highlight_basename), or on file extension (%highlight_ext).
Add some basic test of syntax highlighting (with 'highlight' as
prerequisite) to t/t9500-gitweb-standalone-no-errors.sh test.
While at it make git_blob Perl style prettier.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check that email addresses do not contain <, >, or newline so they can
be quickly scanned without trouble. The copy() function in ident.c
already ensures that ordinary git commands will not write email
addresses without this property.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add exporting TEST_DIRECTORY and TRASH_DIRECTORY to test_external, for
external tests to be able to find test script (and git sources), and
to find trash directory (usually with test repository in it).
Add also exporting GIT_TEST_LONG, so that external test can skip
time-intensive tests unless test is invoked with `--long' option.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A merge will fail gracefully if it needs to update files marked
"assume unchanged", but other similar commands will not. In
particular, checkout and rebase will silently overwrite changes to
such files.
This is a regression introduced in commit 1dcafcc0 (verify_uptodate():
add ce_uptodate(ce) test), which avoids lstat's during a merge, if the
index entry is up-to-date. If the CE_VALID flag is set, however, we
cannot trust CE_UPTODATE.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Like most git commands, request-pull supports a -- delimiter to allow
callers to pass arguments that would otherwise be treated as an option
afterwards. The internal OPTIONS_KEEPDASHDASH variable is passed
empty to git-sh-setup to indicate that request-pull itself does not
care about the position of the -- delimiter. But if the user has
that variable in her environment, request-pull will see the “--” and
fail.
Empty it explicitly to guard against this. While at it, make the
corresponding fix to git-resurrect, too (all other scripts in git.git
already protect themselves).
Acked-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test that request-pull handles failure to push cleanly, writes
pull requests that produce the correct effect when followed, and
uses a predictable format.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"rev-list A..H" computes the set of commits that are ancestors of H, but
excludes the ones that are ancestors of A. This is useful to see what
happened to the history leading to H since A, in the sense that "what does
H have that did not exist in A" (e.g. when you have a choice to update to
H from A).
x---x---A---B---C <-- topic
/ \
x---x---x---o---o---o---o---M---D---E---F---G <-- dev
/ \
x---o---o---o---o---o---o---o---o---o---o---o---N---H <-- master
The result in the above example would be the commits marked with caps
letters (except for A itself, of course), and the ones marked with 'o'.
When you want to find out what commits in H are contaminated with the bug
introduced by A and need fixing, however, you might want to view only the
subset of "A..B" that are actually descendants of A, i.e. excluding the
ones marked with 'o'. Introduce a new option --ancestry-path to compute
this set with "rev-list --ancestry-path A..B".
Note that in practice, you would build a fix immediately on top of A and
"git branch --contains A" will give the names of branches that you would
need to merge the fix into (i.e. topic, dev and master), so this may not
be worth paying the extra cost of postprocessing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a file is removed from the index and then modified in the working
tree then stash will discard the working tree file with no way to
recover the changes.
This can might be done in one of a number of ways.
git rm file
vi file # edit a new version
git stash
or with git mv
git mv file newfile
vi file # make a new file with the old name
git stash
Signed-off-by: Charles Bailey <charles@hashpling.org>
Cleanup t5516-fetch-push.sh to use prevailing test script style
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When pushing to a remote repo the sending side filters out aliased
updates (e.g., foo:baz bar:baz). However, it is not possible for the
sender to know if two refs are aliased on the receiving side via
symrefs. Here is one such scenario:
$ git init origin
$ (cd origin && touch file && git add file && git commit -a -m intial)
$ git clone --bare origin origin.git
$ rm -rf origin
$ git clone origin.git client
$ git clone --mirror client backup.git &&
$ (cd backup.git && git remote set-head origin --auto)
$ (cd client &&
git remote add --mirror backup ../backup.git &&
echo change1 > file && git commit -a -m change1 &&
git push origin &&
git push backup
)
The push to backup fails with:
Counting objects: 5, done.
Writing objects: 100% (3/3), 244 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
error: Ref refs/remotes/origin/master is at ef3... but expected 262...
remote: error: failed to lock refs/remotes/origin/master
To ../backup.git
262cd57..ef307ff master -> master
262cd57..ef307ff origin/HEAD -> origin/HEAD
! [remote rejected] origin/master -> origin/master (failed to lock)
error: failed to push some refs to '../backup.git'
The reason is that refs/remotes/origin/HEAD is a symref to
refs/remotes/origin/master, but it is not possible for the sending side
to unambiguously know this.
This commit fixes the issue by having receive-pack ignore any update to
a symref whose target is being identically updated. If a symref and its
target are being updated inconsistently, then the update for both fails
with an error message ("refusing inconsistent update...") to help
diagnose the situation.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As long as no rev-list arguments are supplied on the command line,
git bundle create --stdin currently segfaults. With added rev-list
arguments, it does not segfault, but the revisions from stdin are
ignored.
Thanks to Joey Hess <joey@kitenet.net> for the report.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, there are 6 tests which are not even written but are
'test_expect_failure message false'.
Do not abuse test_expect_failure as a to do marker, but mark them as
'#TODO' instead.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Verify that a downloaded pack-*.idx file is consistent and valid
as an index file before we rename it into its final destination.
This prevents a corrupt index file from later being treated as a
usable file, confusing readers.
Check that we do not have the pack index file before invoking
fetch_pack_index(); that way, we can do without the has_pack_index()
check in fetch_pack_index().
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To ensure we don't leave a corrupt pack file positioned as though
it were a valid pack file, run index-pack on the temporary pack
before we rename it to its final name. If index-pack crashes out
when it discovers file corruption (e.g. GitHub's error HTML at the
end of the file), simply delete the temporary files to cleanup.
By waiting until the pack has been validated before we move it
to its final name, we eliminate a race condition where another
concurrent reader might try to access the pack at the same time
that we are still trying to verify its not corrupt.
Switching from verify-pack to index-pack is a change in behavior,
but it should turn out better for users. The index-pack algorithm
tries to minimize disk seeks, as well as the number of times any
given object is inflated, by organizing its work along delta chains.
The verify-pack logic does not attempt to do this, thrashing the
delta base cache and the filesystem cache.
By recreating the index file locally, we also can automatically
upgrade from a v1 pack table of contents to v2. This makes the
CRC32 data available for use during later repacks, even if the
server didn't have them on hand.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add '--[no-]tags' options to 'git remote add' which add the
'remote.REMOTE.tagopt = --[no-]tags' to the configuration file.
This mimics the "--tags" and "--no-tags" options of "git fetch".
Signed-off-by: Samuel Tardieu <sam@rfc1149.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I have an alias that takes two arguments and compares their patch IDs.
I would like to use to make sure I've tested exactly what I submit
(patch by patch), like
git patch-cmp origin/master.. file-being-sent
However, I cannot do that because git patch-id is fooled by the "-- "
trailer that git format-patch puts, or likely by the MIME boundary.
This patch adds hunk parsing logic to git patch-id in order to detect an
out of place "-" line and split the patch when it comes. In addition,
commit ids in the "From " lines are considered and printed in the output.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Two more tests that sleep only to waste tick can be converted to use
test_tick and take expiry parameters relative to $test_tick. The basic
idea is to replace "sleep 1" with "test_tick" to cause the "time" to pass.
These tests are interested in expiring things with "now" as the timestamp,
soo use a timestamp relative to $test_tick to give them more stability and
reproducibility.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change into the server repository's directory using a subshell,
so we can return back to the top of the trash directory before
doing anything more in the test script.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
t1010-mktree: Adjust expected result to code and documentation
combined diff: correctly handle truncated file
Document new "already-merged" rule for branch -d
The last two tests here were always supposed to fail in the sense
that, according to code and documentation, mktree should read non-recursive
ls-tree output, but not recursive one, and therefore explicitely refuses
to deal with slashes.
Adjust the test (must_fail) so that it succeeds when mktree dies on
slashes.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Consider an evil merge of two commits A and B, both of which have a
file 'foo', but the merge result does not have that file.
The combined-diff code learned in 4462731 (combine-diff: do not punt
on removed or added files., 2006-02-06) to concisely show only the
removal, since that is the evil part and the previous contents are
presumably uninteresting.
However, to diagnose an empty merge result, it overloaded the variable
that holds the file's length. This means that the check also triggers
for truncated files. Consequently, such files were not shown in the
diff at all despite the merge being clearly evil.
Fix this by adding a new variable that distinguishes whether the file
was deleted (which is the case 4462731 handled) or truncated. In the
truncated case, we show the full combined diff again, which is rather
spammy but at least does not hide the evilness.
Reported-by: David Martínez Martí <desarrollo@gestiweb.com>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of these tests are removing files, environment variables, and
configuration that might interfere outside the test. Putting these
clean-up commands in the test (in the same spirit as v1.7.1-rc0~59,
2010-03-20) means that errors during setup will be caught quickly and
non-error text will be suppressed without -v.
While at it, apply some other minor fixes:
- do not rely on the shell to export variables defined with the same
command as a function call
- avoid whitespace immediately after the > redirection operator, for
consistency with the style of other tests
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches the --color-words engine a more general interface that
supports two new modes:
* --word-diff=plain, inspired by the 'wdiff' utility (most similar to
'wdiff -n <old> <new>'): uses delimiters [-removed-] and {+added+}
* --word-diff=porcelain, which generates an ad-hoc machine readable
format:
- each diff unit is prefixed by [-+ ] and terminated by newline as
in unified diff
- newlines in the input are output as a line consisting only of a
tilde '~'
Both of these formats still support color if it is enabled, using it
to highlight the differences. --color-words becomes a synonym for
--word-diff=color, which is the color-only format. Also adds some
compatibility/convenience options.
Thanks to Junio C Hamano and Miles Bader for good ideas.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If more than one annotated tag points at the same commit, use the
tag whose tagger field has a more recent date stamp. This resolves
non-deterministic cases where the maintainer has done:
$ git tag -a -m "2.1-rc1" v2.1-rc1 deadbeef
$ git tag -a -m "2.1" v2.1 deadbeef
If the tag is an older-style annotated tag with no tagger date, we
assume a date stamp at the UNIX epoch. This will cause us to prefer
an annotated tag that has a valid date.
We could also try to consider the tag object chain, favoring a tag
that "includes" another one:
$ git tag -a -m "2.1-rc0" v2.1-rc1 deadbeef
$ git tag -a -m "2.1" v2.1 v2.1-rc1
However traversing the tag's object chain looking for inclusion
is much more complicated. Its already very likely that even in
these cases the v2.1 tag will have a more recent tagger date than
v2.1-rc1, so with this change describe should still resolve this
by selecting the more recent v2.1.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git remote-testgit is written in Python. In a NO_PYTHON build, tests
using it would fail, so skip them.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If there are foreign $Id$ keywords in the repository, they are most
likely there for a reason. Let's keep them on checkout (which is also
what the documentation indicates). Foreign $Id$ keywords are now
recognized by there being multiple space separated fields in $Id:xxxxx$.
Signed-off-by: Henrik Grubbström <grubba@grubba.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code to contract $Id:xxxxx$ strings could eat an arbitrary amount
of source text if the terminating $ was lost. It now refuses to
contract $Id:xxxxx$ strings spanning multiple lines.
Signed-off-by: Henrik Grubbström <grubba@grubba.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, add a missing && to the update --init test.
The goal is to make it clearer what happened when one of these
tests fails. The update --init test is currently (consistently)
failing on a few unusual machines.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A new reader may not realize what properties the $submodurl
repository needs to have.
One of the tests is checking that ‘submodule add -b foo’ creates
a ‘foo’ branch. Put this test in context by checking that
without -b, no ‘foo’ branch is created.
While at it, make sure each added submodule is a reasonable
repository, with clean index, no stray files, and so on.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The setup in t7400-submodule-basic does a number of different
things to support different tests. Splitting it up makes the
test a little easier to read and should provide an opportunity
to move each piece of setup closer to the tests that require it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using macros it is otherwise hard to know whether an
attribute set by the macro should override an already set
attribute. Consider the following .gitattributes file:
[attr]mybinary binary -ident
* ident
foo.bin mybinary
bar.bin mybinary ident
Without this patch both foo.bin and bar.bin will have
the ident attribute set, which is probably not what
the user expects. With this patch foo.bin will have an
unset ident attribute, while bar.bin will have it set.
Signed-off-by: Henrik Grubbström <grubba@grubba.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using macros it isn't inconceivable to have an attribute
being set by a macro, and then being reset explicitly.
Signed-off-by: Henrik Grubbström <grubba@grubba.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The simple test for an existing .git directory gives an incorrect result
if .git is a file that records "gitdir: overthere". So for submodules that
use a .git file, "git status" and the diff family - when the "--submodule"
option is given - did assume the submodule was not populated at all when
a .git file was used, thus generating wrong output or no output at all.
This is fixed by using read_gitfile_gently() to get the correct location
of the .git directory. While at it, is_submodule_modified() was cleaned up
to use the "dir" member of "struct child_process" instead of setting the
GIT_WORK_TREE and GIT_DIR environment variables.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, we blindly assumed that URLs passed to the remote-curl
helper did not end with a trailing slash.
Use the convenience function end_url_with_slash() from http.[ch] to
ensure that URLs have a trailing slash on invocation of the remote-curl
helper, and use the URL as one with a trailing slash throughout.
It is possible for users to pass a URL with a trailing slash to
remote-curl, by, say, setting it in remote.<name>.url in their git
config. The resulting requests have an empty path component (//) and may
break implementations of the http git protocol.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unlike notes that are often multi-line and disrupting to be placed in many
output formats, a decoration is designed to be a small token that can be
tacked after an existing line of the output where a commit object name sits.
Disabling log.decorate for something like "log --oneline" would defeat the
purpose of the configuration.
We _might_ want to change it further in the future to force scripts that
do not want to be broken by random end user configurations to explicitly
say "log --no-decorate", but that would be an incompatible change that
needs the usual multi-release-cycle deprecation process.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of breaking execution when no remote (as specified in the
variable dest) is specified when git-ls-remote is invoked, continue on
and let remote_get() handle it.
This way, we are able to use the default remotes (eg. "origin",
branch.<name>.remote), as git-fetch, git-push, and other users of
remote_get(), do.
If no suitable remote is found, exit with a message describing the
issue, instead of just the usage text, as we do previously.
Add several tests to check that git-ls-remote handles the
no-remote-specified situation.
Also add a test that "git ls-remote <pattern>" does not work; we are
unable to guess the remote in that situation, as are git-fetch and
git-push.
In that test, we are testing for messages coming from two separate
processes, but we should be OK, because the second message is triggered
by closing the fd which must happen after the first message is printed.
(analysis by Jeff King.)
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 51667147be, "git apply --whitespace=fix" was extended to
allow a blank context line to match beyond the end of the file,
but only if the context line was in the leading part of the
hunk (i.e. the hunk inserted additional contents at the end
of the file).
Drop the restriction that the context line must be in the
leading part of the hunk, thus allowing a file to be changed
from:
a
(blank line)
to:
b
a
(blank line)
Note that the blank line will be kept, because "--whitespace=fix"
only removes trailing blank lines that a hunk would add, never
trailing blank lines in the context.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change git-commit(1) to accept the --allow-empty-message option
to allow a commit with an empty message. This is analogous to the
existing --allow-empty option which allows a commit that records
no changes. As these are mainly for interoperating with foreign SCM
systems, and are not meant for normal use, ensure that "git commit -h"
does not talk about them.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In many places in test suite we have "sleep"s that do not have to be
there.
- I do not simply see the point of the one in t3500. It may be making
sure that the timestamp order of commits generated during the test is
stable, in which case test_tick is the right ingredient to use without
wasting tester's time.
- The one in t4011 is to make sure that the plumbing diff-index notices
the stat-dirtyness of a removed then identically recreated symlink.
Keeping the old symlink around to make sure that a newly created
symlink gets different ino would be sufficient for that purpose.
- The one in t7600 is to make sure that "git merge" does not get confused
by stat-dirty "file" in the working tree. Again, keeping the old file
around and creating an identical copy to ensure a different ino would
be sufficient for that purpose.
The "racy git" tests in t0010 are inherently about mtime between the index
itself and index entries. The "sleep" in that test must stay as they are.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sb/fmt-merge-msg:
fmt-merge-msg: hide summary option
fmt-merge-msg: remove custom string_list implementation
string-list: add unsorted_string_list_lookup()
fmt-merge-msg: use pretty.c routines
t6200: test fmt-merge-msg more
t6200: modernize with test_tick
fmt-merge-msg: be quiet if nothing to merge
Many scripts, most notably gitk, rely on output from the log family of
command not to be molested by random user configuration. This is
especially true when --pretty=raw is given.
Just like we disable notes output unless the command line explicitly
asks for --show-notes, disable the decoration code unless --decorate is
given explicitly from the command line and --pretty or --oneline is
given.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/merge-diff3-label:
merge-recursive: add a label for ancestor
cherry-pick, revert: add a label for ancestor
revert: clarify label on conflict hunks
compat: add mempcpy()
checkout -m --conflict=diff3: add a label for ancestor
merge_trees(): add ancestor label parameter for diff3-style output
merge_file(): add comment explaining behavior wrt conflict style
checkout --conflict=diff3: add a label for ancestor
ll_merge(): add ancestor label parameter for diff3-style output
merge-file --diff3: add a label for ancestor
xdl_merge(): move file1 and file2 labels to xmparam structure
xdl_merge(): add optional ancestor label to diff3-style output
tests: document cherry-pick behavior in face of conflicts
tests: document format of conflicts from checkout -m
Conflicts:
builtin/revert.c
* bc/acl-test:
t/t1304: make a second colon optional in the mask ACL check
t/t1304: set the ACL effective rights mask
t/t1304: use 'test -r' to test readability rather than looking at mode bits
t/t1304: set the Default ACL base entries
t/t1304: avoid -d option to setfacl
This was already the case before commit 9e4b7ab6 (git status: not
"commit --dry-run" anymore, 2009-08-15) with the difference that it died
at failure.
It got lost during the new implementation of "git status", which was
meant to only change behaviour when invoked with arguments.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running a textconv filter can take a long time. It's
particularly bad for a large file which needs to be spooled
to disk, but even for small files, the fork+exec overhead
can add up for something like "git log -p".
This patch uses the notes-cache mechanism to keep a fast
cache of textconv output. Caches are stored in
refs/notes/textconv/$x, where $x is the userdiff driver
defined in gitattributes.
Caching is enabled only if diff.$x.cachetextconv is true.
In my test repo, on a commit with 45 jpg and avi files
changed and a textconv to show their exif tags:
[before]
$ time git show >/dev/null
real 0m13.724s
user 0m12.057s
sys 0m1.624s
[after, first run]
$ git config diff.mfo.cachetextconv true
$ time git show >/dev/null
real 0m14.252s
user 0m12.197s
sys 0m1.800s
[after, subsequent runs]
$ time git show >/dev/null
real 0m0.352s
user 0m0.148s
sys 0m0.200s
So for a slight (3.8%) cost on the first run, we achieve an
almost 40x speed up on subsequent runs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't output an error on `git format-patch --ignore-if-in-upstream HEAD`.
This matches the behavior of `git format-patch HEAD`.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The notes code intends to write reflog entries, but currently they are
not written because log_ref_write() checks for the refname path
explicitly.
Add refs/notes to the list of allowed paths so that notes references are
treated just like branch heads, i.e. according to core.logAllRefUpdates
and core.bare.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test whether the notes code writes reflog entries. It intends to
(setting up the reflog messages) but currently does not.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cc/cherry-pick-ff:
revert: fix tiny memory leak in cherry-pick --ff
rebase -i: use new --ff cherry-pick option
Documentation: describe new cherry-pick --ff option
cherry-pick: add tests for new --ff option
revert: add --ff option to allow fast forward when cherry-picking
builtin/merge: make checkout_fast_forward() non static
parse-options: add parse_options_concat() to concat options
The post-rewrite support, in the form of the call to
'record_in_rewritten', was hidden in the arm where we have to record a
new commit for the user. This meant that it was never invoked in the
case where the user has already amended the commit by herself.
[The test is designed to exercise both arms of the 'if' in question.]
Furthermore, recording the stopped-sha (the SHA1 of the commit before
the editing) suffered from a cut&paste error from die_with_patch and
used the wrong variable, hence it never recorded anything.
Noticed by Junio.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
t9350: fix careless use of "cd"
difftool: Fix '--gui' when diff.guitool is unconfigured
fast-export: don't segfault when marks file cannot be opened
Upon failure of any of these tests (or when a test that is marked as
expecting a failure is fixed), we will end up running later tests in
random places.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch introduces the remove_or_warn function which is a
generalised version of the {unlink,rmdir}_or_warn functions. It takes
an additional parameter indicating the mode of the file to be removed.
The patch also modifies certain functions to use remove_or_warn
where appropriate, and adds a test case for a bug fixed by the use
of remove_or_warn.
Signed-off-by: Peter Collingbourne <peter@pcc.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The values passed this way will override whatever is defined
in the config files.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When diff.guitool is unconfigured and "--gui" is specified
git-difftool dies with the following error message:
config diff.guitool: command returned error: 1
Catch the error so that the "--gui" flag is a no-op when
diff.guitool is unconfigured.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add some more tests so we don't break behavior upon modernizing
fmt-merge-msg.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test defines its own version of test_tick. Get rid of it.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When FETCH_HEAD contains only 'not-for-merge' entries fmt-merge-msg
still outputs "Merge" (and if the branch isn't master " into <branch>").
In this case fmt-merge-msg is outputting junk and should really just
be quiet. Fix it.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/notes-display:
git-notes(1): add a section about the meaning of history
notes: track whether notes_trees were changed at all
notes: add shorthand --ref to override GIT_NOTES_REF
commit --amend: copy notes to the new commit
rebase: support automatic notes copying
notes: implement helpers needed for note copying during rewrite
notes: implement 'git notes copy --stdin'
rebase -i: invoke post-rewrite hook
rebase: invoke post-rewrite hook
commit --amend: invoke post-rewrite hook
Documentation: document post-rewrite hook
Support showing notes from more than one notes tree
test-lib: unset GIT_NOTES_REF to stop it from influencing tests
Conflicts:
git-am.sh
refs.c
* jl/submodule-diff-dirtiness:
git status: ignoring untracked files must apply to submodules too
git status: Fix false positive "new commits" output for dirty submodules
Refactor dirty submodule detection in diff-lib.c
git status: Show detailed dirty status of submodules in long format
git diff --submodule: Show detailed dirty status of submodules
* pb/log-first-parent-p-m:
show --first-parent/-m: do not default to --cc
show -c: show patch text
revision: introduce setup_revision_opt
t4013: add tests for log -p -m --first-parent
git log -p -m: document -m and honor --first-parent
* jk/maint-add-ignored-dir:
tests for "git add ignored-dir/file" without -f
dir: fix COLLECT_IGNORED on excluded prefixes
t0050: mark non-working test as such
* bg/apply-fix-blank-at-eof:
t3417: Add test cases for "rebase --whitespace=fix"
t4124: Add additional tests of --whitespace=fix
apply: Allow blank context lines to match beyond EOF
apply: Remove the quick rejection test
apply: Don't unnecessarily update line lengths in the preimage
For git-rebase.sh, --no-ff is a synonym for --force-rebase.
For git-rebase--interactive.sh, --no-ff cherry-picks all the commits in
the rebased branch, instead of fast-forwarding over any unchanged commits.
--no-ff offers an alternative way to deal with reverted merges. Instead of
"reverting the revert" you can use "rebase --no-ff" to recreate the branch
with entirely new commits (they're new because at the very least the
committer time is different). This obviates the need to revert the
reversion, as you can re-merge the new topic branch directly. Added an
addendum to revert-a-faulty-merge.txt describing the situation and how to
use --no-ff to handle it.
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Similar to -b, --orphan creates a new branch, but it starts without any
commit. After running "git checkout --orphan newbranch", you are on a
new branch "newbranch", and the first commit you create from this state
will start a new history without any ancestry.
"git checkout --orphan" keeps the index and the working tree files
intact in order to make it convenient for creating a new history whose
trees resemble the ones from the original branch.
When creating a branch whose trees have no resemblance to the ones from
the original branch, it may be easier to start work on the new branch by
untracking and removing all working tree files that came from the
original branch, by running a 'git rm -rf .' immediately after running
"checkout --orphan".
Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
55246aa (Dont use "<unknown>" for placeholders and suppress printing
of empty user formats) introduced a check to prevent empty
user-formats from being printed. This test didn't take empty commit
messages into account, and prevented the line-termination from being
output. This lead to multiple commits on a single line.
Correct it by guarding the check with a check for user-format. A
similar correction for the --graph code-path has been included.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When writing conflict hunks in ‘diff3 -m’ format, also add a label to
the common ancestor. Especially in a cherry-pick, it is not immediately
obvious without such a label what the common ancestor represents.
git rerere does not have trouble parsing the new output and its preimage
ids are unchanged since it includes its own code for recreating conflict
hunks. No other code in git parses conflict hunks.
Requested-by: Stefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When reverting a commit, the commit being merged is not the commit
to revert itself but its parent. Add “parent of” to the conflict
hunk label to make this more clear.
The conflict hunk labels are all pieces of a single string written in
the new get_message() function. Avoid some complication by using
mempcpy to advance a pointer as the result is written.
Also free the corresponding temporary buffer (it was leaked before).
This is not important because it is a small one-time allocation. It
would become a memory leak if unnoticed when libifying revert.
This patch uses calls to strlen() instead of integer constants in some
places. GCC will compute the length at compile time; I am not sure
about other compilers, but this is not performance-critical anyway.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git checkout --merge --conflict=diff3 can be used to present conflict
hunks including text from the common ancestor. The added information
is helpful for resolving a merge by hand, and merge tools tend to
understand it because it is very similar to what ‘diff3 -m’ produces.
Unlike current git, diff3 -m includes a label for the merge base on
the ||||||| line, and unfortunately, some tools cannot parse the
conflict hunks without it. Humans can benefit from a cue when
learning to interpreting the format, too. Mark the start of the text
from the old branch with a label based on the branch’s name.
git rerere does not have trouble parsing this output and its preimage
ids are unchanged since it includes its own code for recreating
conflict hunks. No other code in git tries to parse conflict hunks.
Requested-by: Stefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git checkout --conflict=diff3 can be used to present conflicts hunks
including text from the common ancestor:
<<<<<<< ours
ourside
|||||||
original
=======
theirside
>>>>>>> theirs
The added information is helpful for resolving a merge by hand, and
merge tools can usually understand it without trouble because it looks
like output from ‘diff3 -m’.
diff3 includes a label for the merge base on the ||||||| line, and it
seems some tools (for example, Emacs 22’s smerge-mode) cannot parse
conflict hunks without such a label. Humans could use help in
interpreting the output, too. So change the marker for the start of the
text from the common ancestor to include the label “base”.
git rerere’s conflict identifiers are not affected: to parse conflict
hunks, rerere looks for whitespace after the ||||||| marker rather
than a newline, and to compute preimage ids, rerere has its own code
for creating conflict hunks. No other code in git tries to parse
conflict hunks.
Requested-by: Stefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git merge-file --diff3 can be used to present conflicts hunks
including text from the common ancestor.
The added information is helpful for resolving a merge by hand, and
merge tools can usually grok it because it looks like output from
diff3 -m. However, ‘diff3’ includes a label for the merge base on the
||||||| line and some tools cannot parse conflict hunks without such a
label. Write the base-name as passed in a -L option (or the name of
the ancestor file by default) on that line.
git rerere will not have trouble parsing this output, since instead of
looking for a newline, it looks for whitespace after the |||||||
marker. Since rerere includes its own code for recreating conflict
hunks, conflict identifiers are unaffected. No other code in git tries
to parse conflict hunks.
Requested-by: Stefan Monnier <monnier@iro.umontreal.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We are about to change the format of the conflict hunks that
cherry-pick and revert write. Add tests checking the current behavior
first.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We are about to change the format of the conflict hunks that ‘checkout
--merge’ writes. Add tests checking the current behavior first.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/maint-add-ignored-dir:
tests for "git add ignored-dir/file" without -f
dir: fix COLLECT_IGNORED on excluded prefixes
t0050: mark non-working test as such
* cc/reset-keep:
Documentation: improve description of "git reset --keep"
reset: disallow using --keep when there are unmerged entries
reset: disallow "reset --keep" outside a work tree
Documentation: reset: describe new "--keep" option
reset: add test cases for "--keep" option
reset: add option "--keep" to "git reset"
* bg/apply-fix-blank-at-eof:
t3417: Add test cases for "rebase --whitespace=fix"
t4124: Add additional tests of --whitespace=fix
apply: Allow blank context lines to match beyond EOF
apply: Remove the quick rejection test
apply: Don't unnecessarily update line lengths in the preimage
* bw/union-merge-refactor:
merge-file: add option to select union merge favor
merge-file: add option to specify the marker size
refactor merge flags into xmparam_t
make union merge an xdl merge favor
Several tests did not use test_expect_success for their setup
commands. Putting these start commands into the testing framework
means both that errors during setup will be caught quickly and that
non-error text will be suppressed without -v.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test is supposed to check that git-remote correctly refuses to delete
all URLS for the specified remote which match the '.*' regular expression.
Since the '*' was not protected, it was interpreted by the shell as a file
glob and expanded before being passed to git-remote. The call to
git-remote still exited non-zero in this case, and the overall test still
passed, but it exited non-zero because git-remote was passed the incorrect
number of arguments, not for the reason it was supposed to fail.
Correct the test by escaping the '*'.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Solaris only uses one colon in the listing of the ACL mask, Linux uses two,
so substitute egrep for grep and make the second colon optional.
The -q option for Solaris 7's /usr/xpg4/bin/egrep does not appear to be
implemented, so redirect output to /dev/null.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some implementations of setfacl do not recalculate the effective rights
mask when the ACL is modified. So, set the effective rights mask
explicitly to ensure that the ACL's that are set on the directories will
have effect.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This test was using the group read permission bit as an indicator of the
default ACL mask. This behavior is valid on Linux but not on other
platforms like Solaris. So, rather than looking at mode bits, just test
readability for the user. This, along with the checks for the existence
of the ACL's that were set on the parent directories, should be enough.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
According to the Linux setfacl man page, in order for an ACL to be valid,
the following rules must be satisfied:
* Whenever an ACL contains any Default ACL entries, the three Default
ACL base entries (default owner, default group, and default others)
must also exist.
* Whenever a Default ACL contains named user entries or named group
objects, it must also contain a default effective rights mask.
Some implementations of setfacl (Linux) do this automatically when
necessary, some (Solaris) do not. Solaris's setfacl croaks when trying to
create a default user ACL if the above rules are not satisfied. So, create
them before modifying the default user ACL's.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some platforms (Solaris) have a setfacl whose -d switch works differently
than the one on Linux. On Linux, it causes all operations to be applied
to the Default ACL. There is a notation for operating on the Default ACL:
[d[efault]:] [u[ser]:]uid [:perms]
so use it instead of the -d switch.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brandon Casey noticed that t5505 had accidentally broken its && chain,
hiding inconsistency between the code that writes the warning to the
standard output and the test that expects to see the warning on the
standard error, which was introduced by f8948e2 (remote prune: warn
dangling symrefs, 2009-02-08).
It turns out that the issue is deeper than that. After f8948e2, a symref
that is dangling is marked with a NULL sha1, and the idea of using NULL
sha1 to mean a deleted ref was scrapped, but somehow a follow-up eafb452
(do_one_ref(): null_sha1 check is not about broken ref, 2009-07-22)
incorrectly reorganized do_one_ref(), still thinking NULL sha1 is never
used in the code.
Fix this by:
- adopt Brandon's fix to t5505 test;
- introduce REF_BROKEN flag to mark a ref that fails to resolve (dangling
symref);
- move the check for broken ref back inside the "if we are skipping
dangling refs" code block.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sd/format-patch-to:
send-email: add --no-cc, --no-to, and --no-bcc
format-patch: add --no-cc, --no-to, and --no-add-headers
format-patch: use a string_list for headers
Add 'git format-patch --to=' option and 'format.to' configuration variable.
* tc/http-cleanup:
remote-curl: init walker only when needed
remote-curl: use http_fetch_ref() instead of walker wrapper
http: init and cleanup separately from http-walker
http-walker: cleanup more thoroughly
http-push: remove "|| 1" to enable verbose check
t554[01]-http-push: refactor, add non-ff tests
t5541-http-push: check that ref is unchanged for non-ff test
* ld/push-porcelain:
t5516: Use test_cmp when appropriate
git-push: add tests for git push --porcelain
git-push: make git push --porcelain print "Done"
git-push: send "To <remoteurl>" messages to the standard output in --porcelain mode
git-push: fix an advice message so it goes to stderr
Conflicts:
transport.c
* jh/notes: (33 commits)
Documentation: fix a few typos in git-notes.txt
notes: fix malformed tree entry
builtin-notes: Minor (mostly parse_options-related) fixes
builtin-notes: Add "copy" subcommand for copying notes between objects
builtin-notes: Misc. refactoring of argc and exit value handling
builtin-notes: Add -c/-C options for reusing notes
builtin-notes: Refactor handling of -F option to allow combining -m and -F
builtin-notes: Deprecate the -m/-F options for "git notes edit"
builtin-notes: Add "append" subcommand for appending to note objects
builtin-notes: Add "add" subcommand for adding notes to objects
builtin-notes: Add --message/--file aliases for -m/-F options
builtin-notes: Add "list" subcommand for listing note objects
Documentation: Generalize git-notes docs to 'objects' instead of 'commits'
builtin-notes: Add "prune" subcommand for removing notes for missing objects
Notes API: prune_notes(): Prune notes that belong to non-existing objects
t3305: Verify that removing notes triggers automatic fanout consolidation
builtin-notes: Add "remove" subcommand for removing existing notes
Teach builtin-notes to remove empty notes
Teach notes code to properly preserve non-notes in the notes tree
t3305: Verify that adding many notes with git-notes triggers increased fanout
...
Conflicts:
Makefile
git rebase allows you to specify a non-branch commit-ish as the "branch"
argument, which leaves HEAD detached when it's finished. This is
occasionally useful, and this patch brings the same functionality to git
rebase --interactive.
Signed-off-by: Dave Olszewski <cxreg@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test is to prepare an empty file "camelcase" in the index, remove
and replace it with another file "CamelCase" with "1" as its contents
in the working tree, and add it to the index, in a repository configured
to be case insensitive.
However, the test actually checked ls-files knows about a pathname that
matches "camelcase" case insensitively. It didn't check if the added
contents actually was the updated one.
Mark the test as non-working.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 1.7.0 submodules are considered dirty when they contain untracked
files. But when git status is called with the "-uno" option, the user
asked to ignore untracked files, so they must be ignored in submodules
too. To achieve this, the new flag DIFF_OPT_IGNORE_UNTRACKED_IN_SUBMODULES
is introduced.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
don't use default revision if a rev was specified
for_each_recent_reflog_ent(): use strbuf, fix offset handling
t/Makefile: remove test artifacts upon "make clean"
blame: fix indent of line numbers
If a revision is specified, it happens not to have any commits, don't
use the default revision. By doing so, surprising and undesired
behavior can happen, such as showing the reflog for HEAD when a branch
was specified.
[jc: squashed a test from René]
Signed-off-by: Dave Olszewski <cxreg@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Correct the calculation of the number of digits for line counts of the
form 10^n-1 (9, 99, ...) in lineno_width(). This makes blame stop
printing an extra space before the line numbers of files with that many
total lines.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rewrite-root option seems to be a bit problematic with merge
detecting, so it's better to have a merge detecting test with it
turned on.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Testing if the output "new commits" should appear in the long format of
"git status" is done by comparing the hashes of the diffpair. This always
resulted in printing "new commits" for submodules that contained untracked
or modified content, even if they did not contain new commits. The reason
was that match_stat_with_submodule() did set the "changed" flag for dirty
submodules, resulting in two->sha1 being set to the null_sha1 at the call
sites, which indicates that new commits are present. This is changed so
that when no new commits are present, the same object names are in the
sha1 field for both sides of the filepair, and the working tree side will
have the "dirty_submodule" flag set when appropriate. For a submodule to
be seen as modified even when it just has a dirty work tree, some
conditions had to be extended to also check for the "dirty_submodule"
flag.
Unfortunately the test case that should have found this bug had been
changed incorrectly too. It is fixed and extended to test for other
combinations too.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running 'git notes copy -h' is not very helfpul right now. It lists
the options for all the git notes subcommands and is rather confusing.
Fix this by splitting cmd_notes() into separate functions for each
subcommand (besides append and edit since they're very similar) and
only providing a usage message for the subcommand.
This has an added benefit of reducing the code complexity while making
it safer and easier to read. The downside is we get some code bloat
from similar setup and teardown needed for notes and options parsing.
We also get a bit stricter in options parsing by only allowing
the ref option to come before the subcommand.
Acked-by: Johan Herland <johan@herland.net>
Cc: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teaches 'git commit --amend' to copy notes. The catch is that this
must also be guarded by --no-post-rewrite, which we use to prevent
--amend from copying notes during a rebase -i 'edit'/'reword'.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Luckily, all the support already happens to be there.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Implement helper functions to load the rewriting config, and to
actually copy the notes. Also document the config.
Secondly, also implement an undocumented --for-rewrite=<cmd> option to
'git notes copy' which is used like --stdin, but also puts the
configuration for <cmd> into effect. It will be needed to support the
copying in git-rebase.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This implements a mass-copy command that takes a sequence of lines in
the format
<from-sha1> SP <to-sha1> [ SP <rest> ] LF
on stdin, and copies each <from-sha1>'s notes to the <to-sha1>. The
<rest> is ignored. The intent, of course, is that this can read the
same input that the 'post-rewrite' hook gets.
The copy_note() function is exposed for everyone's and in particular
the next commit's use.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Aside from the same issue that rebase also has (remembering the
original commit across a conflict resolution), rebase -i brings an
extra twist: We need to defer writing the rewritten list in the case
of {squash,fixup} because their rewritten result should be the last
commit in the squashed group.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have to deal with two separate code paths: a normal rebase, which
actually goes through git-am; and rebase {-m|-s}.
The only small issue with both is that they need to remember the
original sha1 across a possible conflict resolution. rebase -m
already puts this information in $dotest/current, and we just
introduce a similar file for git-am.
Note that in git-am, the hook really only runs when coming from
git-rebase: the code path that sets the $dotest/original-commit file
is guarded by a test for $dotest/rebasing.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rough structure of run_rewrite_hook() comes from
run_receive_hook() in receive-pack.
We introduce a --no-post-rewrite option and use it to avoid the hook
when called from git-rebase -i 'edit'. The next patch will add full
support in git-rebase, and we only want to invoke the hook once.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this patch, you can set notes.displayRef to a glob that points at
your favourite notes refs, e.g.,
[notes]
displayRef = refs/notes/*
Then git-log and friends will show notes from all trees.
Thanks to Junio C Hamano for lots of feedback, which greatly
influenced the design of the entire series and this commit in
particular.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Consistently using test_cmp would make debugging test scripts far easier,
as output from them run under "-v" option becomes readable.
Besides, some platforms' "diff" implementations lack "-q" option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Consistently using test_cmp would make debugging test scripts far easier,
as output from them run under "-v" option becomes readable.
Besides, some platforms' "diff" implementations lack "-q" option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sd/init-template:
wrap-for-bin: do not export an empty GIT_TEMPLATE_DIR
t/t0001-init.sh: add test for 'init with init.templatedir set'
init: having keywords without value is not a global error.
Add a "TEMPLATE DIRECTORY" section to git-init[1].
Add `init.templatedir` configuration variable.
* sh/am-keep-cr:
git-am: Add tests for `--keep-cr`, `--no-keep-cr` and `am.keepcr`
git-am: Add am.keepcr and --no-keep-cr to override it
git-am: Add command line parameter `--keep-cr` passing it to git-mailsplit
documentation: 'git-mailsplit --keep-cr' is not hidden anymore
Given that "git show" always shows some diff and does not walk the history
by default, it is natural to expect "git show --first-parent" to show the
difference between the given commit and its first parent. It also would
be natural, given that "--cc" is the default, "git show -m" to show
pairwise difference from each of the parents.
We however always defaulted to --cc and there was no way to turn it off.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Traditionally, "show" defaulted to "show --cc" (dense combined patch), but
asking for combined patch with "show -c" didn't turn the patch output
format on; the placement of this logic in setup_revisions() dates back to
cd2bdc5 (Common option parsing for "git log --diff" and friends,
2006-04-14).
This unfortunately cannot be done as a trivial change of "if dense
combined is asked, default to patch format" done in setup_revisions() to
"if any combined is asked, default to patch format", as "diff-tree -c"
needs to default to raw, while "diff-tree --cc" needs to default to patch,
and they share the codepath. These command specific defaults are now
handled in the new "tweak" callback that can be customized by individual
command implementations.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's no way to override the sendemail.to, sendemail.cc, and
sendemail.bcc config settings. Add options allowing the user to tell
git to ignore the config settings and take whatever is on the command
line.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These new options allow users to override their config settings for
format.cc, format.to and format.headers respectively. These options
only make git ignore the config settings and any previous command line
options, so you'll still have to add more command line options to add
extra headers. For example,
$ cat .git/config
[format]
to = Someone <someone@out.there>
$ git format-patch -1 --no-to --to="Someone Else <else@out.there>"
would format a patch addressed to "Someone Else" and not "Someone".
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 1.7.0 there are three reasons a submodule is considered modified
against the work tree: It contains new commits, modified content or
untracked content. Lets show all reasons in the long format of git status,
so the user can better asses the nature of the modification. This change
does not affect the short and porcelain formats.
Two new members are added to "struct wt_status_change_data" to store the
information gathered by run_diff_files(). wt-status.c uses the new flag
DIFF_OPT_DIRTY_SUBMODULES to tell diff-lib.c it wants to get detailed
dirty information about submodules.
A hint line for submodules is printed in the dirty header when dirty
submodules are present.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/fetch-param:
fetch --all/--multiple: keep all the fetched branch information
builtin-fetch --all/--multi: propagate options correctly
t5521: fix and modernize
* mm/mkstemps-mode-for-packfiles:
Use git_mkstemp_mode instead of plain mkstemp to create object files
git_mkstemps_mode: don't set errno to EINVAL on exit.
Use git_mkstemp_mode and xmkstemp_mode in odb_mkstemp, not chmod later.
git_mkstemp_mode, xmkstemp_mode: variants of gitmkstemps with mode argument.
Move gitmkstemps to path.c
Add a testcase for ACL with restrictive umask.
* sp/maint-push-sideband:
receive-pack: Send internal errors over side-band #2
t5401: Use a bare repository for the remote peer
receive-pack: Send hook output over side band #2
receive-pack: Wrap status reports inside side-band-64k
receive-pack: Refactor how capabilities are shown to the client
send-pack: demultiplex a sideband stream with status data
run-command: support custom fd-set in async
run-command: Allow stderr to be a caller supplied pipe
* jc/fetch-param:
fetch --all/--multiple: keep all the fetched branch information
builtin-fetch --all/--multi: propagate options correctly
t5521: fix and modernize
* nd/root-git:
Add test for using Git at root of file system
Support working directory located at root
Move offset_1st_component() to path.c
init-db, rev-parse --git-dir: do not append redundant slash
make_absolute_path(): Do not append redundant slash
Conflicts:
setup.c
sha1_file.c
* mm/mkstemps-mode-for-packfiles:
Use git_mkstemp_mode instead of plain mkstemp to create object files
git_mkstemps_mode: don't set errno to EINVAL on exit.
Use git_mkstemp_mode and xmkstemp_mode in odb_mkstemp, not chmod later.
git_mkstemp_mode, xmkstemp_mode: variants of gitmkstemps with mode argument.
Move gitmkstemps to path.c
Add a testcase for ACL with restrictive umask.
In configuration files (and "git config --color" command line), we
supported one and only one attribute after foreground and background
color. Accept combinations of attributes, e.g.
[diff.color]
old = red reverse bold
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I used to set GREP_OPTIONS to exclude *.orig and *.rej files. But with this
the test t4252-am-options.sh fails because it calls grep with a .rej file:
grep "@@ -1,3 +1,3 @@" file-2.rej
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command "git rebase --whitespace=fix HEAD~<N>" is supposed to
only clean up trailing whitespace, and the expectation is that it
cannot fail.
Unfortunately, if one commit adds a blank line at the end of a file
and a subsequent commit adds more non-blank lines after the blank
line, "git apply" (used indirectly by "git rebase") will fail to apply
the patch of the second commit.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the next commit, we will make it possible for blank context
lines to match beyond the end of the file. That means that a hunk
with a preimage that has more lines than present in the file may
be possible to successfully apply. Therefore, we must remove
the quick rejection test in find_pos().
find_pos() will already work correctly without the quick
rejection test, but that might not be obvious. Therefore,
comment the test for handling out-of-range line numbers in
find_pos() and cast the "line" variable to the same (unsigned)
type as img->nr.
What are performance implications of removing the quick
rejection test?
It can only help "git apply" to reject a patch faster. For example,
if I have a file with one million lines and a patch that removes
slightly more than 50 percent of the lines and try to apply that
patch twice, the second attempt will fail slightly faster
with the test than without (based on actual measurements).
However, there is the pathological case of a patch with many
more context lines than the default three, and applying that patch
using "git apply -C1". Without the rejection test, the running
time will be roughly proportional to the number of context lines
times the size of the file. That could be handled by writing
a more complicated rejection test (it would have to count the
number of blanks at the end of the preimage), but I don't find
that worth doing until there is a real-world use case that
would benfit from it.
It would be possible to keep the quick rejection test if
--whitespace=fix is not given, but I don't like that from
a testing point of view.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The use case for --keep option is to remove previous commits unrelated
to the current changes in the working tree. So in this use case we are
not supposed to have unmerged entries. This is why it seems safer to
just disallow using --keep when there are unmerged entries.
And this patch changes the error message when --keep was disallowed and
there were some unmerged entries from:
error: Entry 'file1' would be overwritten by merge. Cannot merge.
fatal: Could not reset index file to revision 'HEAD^'.
to:
fatal: Cannot do a keep reset in the middle of a merge.
which is nicer.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is safer and consistent with "--merge" and "--hard" resets to disallow
"git reset --keep" outside a work tree.
So let's just do that and add some tests while at it.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests have been broken since they were introduced in commits
ca2cedb (git-submodule: add support for --rebase., 2009-04-24) and
42b4917 (git-submodule: add support for --merge., 2009-06-03).
'git submodule init' expects the submodules to exist in the index.
In this case, the submodules don't exist and therefore looking for
the submodules will always fail. To make matters worse, git submodule
fails visibly to the user by saying:
error: pathspec 'rebasing' did not match any file(s) known to git.
Did you forget to 'git add'?
but doesn't return an error code. This allows the test to fail silently.
Fix it by adding the submodules first.
Cc: Johan Herland <johan@herland.net>
Cc: Peter Hutterer <peter.hutterer@who-t.net>
Cc: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Has the same functionality as the '--cc' option and 'format.cc'
configuration variable but for the "To:" email header. Half of the code to
support this was already there.
With email the To: header usually more important than the Cc: header.
[jc: tests are by Stephen Boyd]
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/maint-fix-pager:
tests: Fix race condition in t7006-pager
t7006-pager: if stdout is not a terminal, make a new one
tests: Add tests for automatic use of pager
am: Fix launching of pager
git svn: Fix launching of pager
git.1: Clarify the behavior of the --paginate option
Make 'git var GIT_PAGER' always print the configured pager
Fix 'git var' usage synopsis
When encountering a dirty submodule while doing "git diff --submodule"
print an extra line for new untracked content and another for modified
but already tracked content. And if the HEAD of the submodule is equal
to the ref diffed against in the superproject, drop the output which
would just show the same SHA1s and no commit message headlines.
To achieve that, the dirty_submodule bitfield is expanded to two bits.
The output of "git status" inside the submodule is parsed to set the
according bits.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All tests in t9119 were disabled for subversion versions other than
1.[45].*. Make the test script run with subversion 1.[456].*.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
* sp/maint-push-sideband:
receive-pack: Send internal errors over side-band #2
t5401: Use a bare repository for the remote peer
receive-pack: Send hook output over side band #2
receive-pack: Wrap status reports inside side-band-64k
receive-pack: Refactor how capabilities are shown to the client
send-pack: demultiplex a sideband stream with status data
run-command: support custom fd-set in async
run-command: Allow stderr to be a caller supplied pipe
Conflicts:
builtin-receive-pack.c
run-command.c
t/t5401-update-hooks.sh
This adds the abbility to specify the conflict marker size for merges outside
a git repository.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/maint-fix-pager:
tests: Fix race condition in t7006-pager
t7006-pager: if stdout is not a terminal, make a new one
tests: Add tests for automatic use of pager
am: Fix launching of pager
git svn: Fix launching of pager
git.1: Clarify the behavior of the --paginate option
Make 'git var GIT_PAGER' always print the configured pager
Fix 'git var' usage synopsis
This commit fixes a bug in processing project-specific override in
a situation when there is no project, e.g. for the projects list page.
When 'snapshot' feature had project specific config override enabled
by putting
$feature{'snapshot'}{'override'} = 1;
(or equivalent) in $GITWEB_CONFIG, and when viewing toplevel gitweb
page, which means the projects list page (to be more exact this
happens for any project-less action), gitweb would put the following
Perl warnings in error log:
gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2065.
fatal: error processing config file(s)
gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2221.
gitweb.cgi: Use of uninitialized value $git_dir in concatenation (.) or string at gitweb.cgi line 2218.
The problem is in the following fragment of code:
# path to the current git repository
our $git_dir;
$git_dir = "$projectroot/$project" if $project;
# list of supported snapshot formats
our @snapshot_fmts = gitweb_get_feature('snapshot');
@snapshot_fmts = filter_snapshot_fmts(@snapshot_fmts);
For the toplevel gitweb page, which is the list of projects, $project is not
defined, therefore neither is $git_dir. gitweb_get_feature() subroutine
calls git_get_project_config() if project specific override is turned
on... but we don't have project here.
Those errors mentioned above occur in the following fragment of code in
git_get_project_config():
# get config
if (!defined $config_file ||
$config_file ne "$git_dir/config") {
%config = git_parse_project_config('gitweb');
$config_file = "$git_dir/config";
}
git_parse_project_config() calls git_cmd() which has '--git-dir='.$git_dir
There are (at least) three possible solutions:
1. Harden gitweb_get_feature() so that it doesn't call
git_get_project_config() if $project (and therefore $git_dir) is not
defined; there is no project for project specific config.
2. Harden git_get_project_config() like you did in your fix, returning early
if $git_dir is not defined.
3. Harden git_cmd() so that it doesn't add "--git-dir=$git_dir" if $git_dir
is not defined, and change git_get_project_config() so that it doesn't
even try to access $git_dir if it is not defined.
This commit implements both 1.) and 2.), i.e. gitweb_get_feature() doesn't
call project-specific override if $git_dir is not defined (if there is no
project), and git_get_project_config() returns early if $git_dir is not
defined.
Add a test for this bug to t/t9500-gitweb-standalone-no-errors.sh test.
Reported-by: Eli Barzilay <eli@barzilay.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move non-fast forward tests to lib-httpd.sh so that we don't have to
duplicate the tests in both t5540 and t5541.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As reported by Mark Lodato, "git bisect", when it was started with
path parameters that match no commit was kind of working without
taking account of path parameters and was reporting something like:
Bisecting: -1 revisions left to test after this (roughly 0 steps)
It is more correct and safer to just error out in this case, before
displaying the revisions left, so this patch does just that.
Note that this bug is very old, it exists at least since v1.5.5.
And it is possible to detect that case earlier in the bisect
algorithm, but it is not clear that it would be an improvement to
error out earlier, on the contrary it may change the behavior of
"git rev-list --bisect-all" for example, which is currently correct.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add tests for git-am using files with DOS line endings for various
combinations of `--keep-cr`, `--no-keep-cr` and `am.keepcr`.
Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Verify that the output format is correct for successful, rejected, and
flagrantly erroneous pushes.
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, if gc.reflogexpire or gc.reflogexpire were set to "never"
or "false", the builtin default values were used instead.
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, prune treated an expiration time of 0 to mean that no
expire argument was supplied, and everything should be pruned. As a
result, "prune --expire=never" would prune all unreachable objects,
regardless of their timestamp.
prune can be called with --expire=never automatically by gc, when the
gc.pruneExpire configuration is set to "never".
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If parent J is an ancestor of parent I, then parent J should be
discarded, not I.
Note that J is an ancestor of I if and only if rev-list I..J is emtpy,
which is what we are testing here.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
When svn:mergeinfo contains two new parents in a specific order and
one is ancestor of the other, it is possible that git-svn discards the
wrong one. The first test case ("commit made to merged branch is
reachable from the merge") proves this.
The second test case ("merging two branches in one commit is detected
correctly") is just for completeness, since there was no test for
merging two (feature) branches to trunk in one commit.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
A few "svn cp" commands and commit commands were executed in incorrect
order. Therefore some of the desired commits were missing and some
were committed with wrong revision number in the commit message. This
made it hard to compare the produced git repository with the SVN
repository.
The dump file is updated too, but only the relevant parts and with
hand-edited timestamps to make history linear.
Signed-off-by: Tuomas Suutari <tuomas.suutari@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Requires a small change to wrap-for-bin.sh in order to work.
Signed-off-by: Steven Drake <sdrake@xnet.co.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, the equivalent of "/dev/null" is "nul". This implements
compatibility wrappers around fopen() and freopen() that check for this
particular file name.
The new tests exercise code paths where this is relevant.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is required on Windows because git-notes is now a built-in
rather than a shell script.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since "git fetch" learned "--all" and "--multiple" options, it has become
tempting for users to say "git pull --all". Even though it may fetch from
remotes that do not need to be fetched from for merging with the current
branch, it is handy.
"git fetch" however clears the list of fetched branches every time it
contacts a different remote. Unless the current branch is configured to
merge with a branch from a remote that happens to be the last in the list
of remotes that are contacted, "git pull" that fetches from multiple
remotes will not be able to find the branch it should be merging with.
Make "fetch" clear FETCH_HEAD (unless --append is given) and then append
the list of branches fetched to it (even when --append is not given). That
way, "pull" will be able to find the data for the branch being merged in
FETCH_HEAD no matter where the remote appears in the list of remotes to be
contacted by "git fetch".
Reported-by: Michael Lukashov
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running a subfetch, the code propagated some options but not others.
Propagate --force, --update-head-ok and --keep options as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All of these tests were bogus, as they created new directory and tried to
run "git pull" without even running "git init" in there. They were mucking
with the repository in $TEST_DIRECTORY.
While fixing it, modernize the style not to chdir around outside of
subshell. Otherwise a failed test will take us to an unexpected directory
and we need to chdir back to the test directory in each test, which is
ugly and error prone.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we look at a patch for adding hunks interactively, we
first split it into a header and a list of hunks. Some of
the header lines, such as mode changes and deletion, however,
become their own selectable hunks. Later when we reassemble
the patch, we simply concatenate the header and the selected
hunks. This leads to patches like this:
diff --git a/file b/file
index d95f3ad..0000000
--- a/file
+++ /dev/null
deleted file mode 100644
@@ -1 +0,0 @@
-content
Notice how the deletion comes _after_ the ---/+++ lines,
when it should come before.
In many cases, we can get away with this as git-apply
accepts the slightly bogus input. However, in the specific
case of a deletion line that is being applied via "apply
-R", this malformed patch triggers an assert in git-apply.
This comes up when discarding a deletion via "git checkout
-p".
Rather than try to make git-apply accept our odd input,
let's just reassemble the patch in the correct order.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to unnecessarily give the read permission to group and others,
regardless of the umask, which isn't serious because the objects are
still protected by their containing directory, but isn't necessary
either.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to create 0600 files, and then use chmod to set the group and
other permission bits to the umask. This usually has the same effect
as a normal file creation with a umask.
But in the presence of ACLs, the group permission plays the role of
the ACL mask: the "g" bits of newly created files are chosen according
to default ACL mask of the directory, not according to the umask, and
doing a chmod() on these "g" bits affect the ACL's mask instead of
actual group permission.
In other words, creating files with 0600 and then doing a chmod to the
umask creates files which are unreadable by users allowed in the
default ACL. To create the files without breaking ACLs, we let the
umask do it's job at the file's creation time, and get rid of the
later chmod.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right now, Git creates unreadable pack files on non-shared
repositories when the user has a umask of 077, even when the default
ACLs for the directory would give read/write access to a specific
user.
Loose object files are created world-readable, which doesn't break ACLs,
but isn't necessarily desirable.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pagers that do not consume their input are dangerous: for example,
$ GIT_PAGER=: git log
$ echo $?
141
$
The only reason these tests were able to work before was that
'git log' would write to the pipe (and not fill it) before the
pager had time to terminate and close the pipe.
Fix it by using a program that consumes its input, namely wc (as
suggested by Johannes).
Reported-by: Johannes Sixt <j.sixt@viscovery.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds two test cases for:
6977c25 git diff --quiet -w: check and report the status
Signed-off-by: Larry D'Anna <larry@elder-gods.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sp/push-sideband:
receive-pack: Send internal errors over side-band #2
t5401: Use a bare repository for the remote peer
receive-pack: Send hook output over side band #2
receive-pack: Wrap status reports inside side-band-64k
receive-pack: Refactor how capabilities are shown to the client
send-pack: demultiplex a sideband stream with status data
run-command: support custom fd-set in async
run-command: Allow stderr to be a caller supplied pipe
Testing pagination requires (fake or real) access to a terminal so we
can see whether the pagination automatically kicks in, which makes it
hard to get good coverage when running tests without --verbose. There
are a number of ways to work around that:
- Replace all isatty calls with calls to a custom xisatty wrapper
that usually checks for a terminal but can be overridden for tests.
This would be workable, but it would require implementing xisatty
separately in three languages (C, shell, and perl) and making sure
that any code that is to be tested always uses the wrapper.
- Redirect stdout to /dev/tty. This would be problematic because
there might be no terminal available, and even if a terminal is
available, it might not be appropriate to spew output to it.
- Create a new pseudo-terminal on the fly and capture its output.
This patch implements the third approach.
The new test-terminal.perl helper uses IO::Pty from Expect.pm to create
a terminal and executes the program specified by its arguments with
that terminal as stdout. If the IO::Pty module is missing or not
working on a system, the test script will maintain its old behavior
(skipping most of its tests unless GIT_TEST_OPTS includes --verbose).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-p4: fix bug in symlink handling
t1450: fix testcases that were wrongly expecting failure
Documentation: Fix indentation problem in git-commit(1)
Git’s automatic pagination support has some subtleties. Add some
tests to make sure we don’t break:
- when git will use a pager by default;
- the effect of the --paginate and --no-pager options;
- the effect of pagination on use of color;
- how the choice of pager is configured.
This does not yet test:
- use of pager by scripted commands (git svn and git am);
- effect of the pager.* configuration variables;
- setting of the LESS variable.
Some features involve checking whether stdout is a terminal, so many
of these tests are skipped unless output is passed through to the
terminal (i.e., unless $GIT_TEST_OPTS includes --verbose).
The immediate purpose for these tests was to avoid making things worse
after the breakage from my jn/editor-pager series (see commit 376f39,
2009-11-20). Thanks to Sebastian Celis <sebastian@sebastiancelis.com>
for the report.
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Almost exactly a year ago in 02a6552 (Test fsck a bit harder), I
introduced two testcases that were expecting failure.
However, the only bug was that the testcases wrote *blobs* because I
forgot to pass -t tag to hash-object. Fix this, and then adjust the
rest of the test to properly check the result.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we remove a path in a/deep/subdirectory, we should try to
remove as many trailing components as possible (i.e.,
subdirectory, then deep, then a). However, the test for the
return value of rmdir was reversed, so we only ever deleted
at most one level.
The fix is in remove_path, so "apply" and "merge-recursive"
also are fixed.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When invoking "git submodule summary" in an empty repo (which can be
indirectly done by setting status.submodulesummary = true), it currently
emits an error message (via "git diff-index") since HEAD points to an
unborn branch.
This patch adds handling of the HEAD-points-to-unborn-branch special case,
so that "git submodule summary" no longer emits this error message.
The patch also adds a test case that verifies the fix.
Suggested-by: Jeff King <peff@peff.net>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The configuration is meant to suppliment --decorate command line option
that can be used as a boolean to turn the feature on, so it is natural
to expect
[log]
decorate
decorate = yes
to work. The original commit would segfault with the first one, and
would not understand the second one.
Once a user has this configuration in ~/.gitconfig, there needs to be a
way to override it from the command line. Add --no-decorate option to
log family and also allow --decorate=no to mean the same thing. Since
we allow setting log.decorate to 'true', the command line also should
accept --decorate=yes and behave accordingly.
New tests in t4202 are designed to exercise the interaction between the
configuration variable and the command line option that overrides it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a test for 'git add -u pathspec' and 'git add pathspec' where
pathspec does not exist. The expected result is that git add exits with
an error message and an appropriate exit code.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Prepare 1.7.0.1 release notes
Fix use of mutex in threaded grep
dwim_ref: fix dangling symref warning
stash pop: remove 'apply' options during 'drop' invocation
diff: make sure --output=/bad/path is caught
Remove hyphen from "git-command" in two error messages
* maint-1.6.6:
dwim_ref: fix dangling symref warning
stash pop: remove 'apply' options during 'drop' invocation
diff: make sure --output=/bad/path is caught
Remove hyphen from "git-command" in two error messages
This kind of test requires a throw-away root filesystem so that it can
play on. If you have such a system, go ahead, "chmod 777 /" and run
this test manually. Because this is a dangerous test, you are required
to set an env variable, and not to use root to run it.
Script prepare-root.sh may help you set up a chroot environment with
Git test suite inside. You will need Linux, static linked busybox,
rsync and root permission to use it.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'git stash pop' option parsing used to remove the first argument
in --index mode. At the time this was implemented, this first
argument was always --index. However, since the invention of the -q
option in fcdd0e9 (stash: teach quiet option, 2009-06-17) you can
cause an internal invocation of
git stash drop --index
by running
git stash pop -q --index
which then of course fails because drop doesn't know --index.
To handle this, instead let 'git stash apply' decide what the future
argument to 'drop' should be.
Warning: this means that 'git stash apply' must parse all options that
'drop' can take, and deal with them in the same way. This is
currently true for its only option -q.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is useful for keeping notes to objects that are being rewritten by e.g.
'git commit --amend', 'git rebase', or 'git cherry-pick'.
"git notes copy <from> <to>" is in practice equivalent to
"git notes add -C $(git notes list <from>) <to>", although it is somewhat
more convenient for regular users.
"git notes copy" takes the same -f option as "git add", to overwrite existing
notes at the target (instead of aborting with an error message).
If the <from>-object has no notes, "git notes copy" will abort with an error
message.
The patch includes tests verifying correct behaviour of the new subcommand.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Inspired by the -c/-C options to "git commit", we teach these options to
"git notes add/append" to allow reuse of note objects.
With this patch in place, it is now easy to copy or move notes between
objects. For example, to copy object A's notes to object B:
git notes add [-f] -C $(git notes list A) B
To move instead of copying, you simply remove the notes from the source
object afterwards, e.g.:
git notes remove A
The patch includes tests verifying correct behaviour of the new functionality.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By moving the -F option handling into a separate function (parse_file_arg),
we can start allowing several -F options, and mixed usage of -m and -F
options. Each -m/-F given appends to the note message, in the order they are
given on the command-line.
The patch includes tests verifying correct behaviour of the new functionality.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The semantics for "git notes edit -m/-F" overlap with those for
"git notes add -f", and the behaviour (i.e. overwriting existing
notes with the given message/file) is more intuitively captured
by (and better documented with) "git notes add -f".
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git notes append" is equivalent to "git notes edit" except that instead
of editing existing notes contents, you can only append to it. This is
useful for quickly adding annotations like e.g.:
git notes append -m "Acked-by: A U Thor <author@example.com>"
"git notes append" takes the same -m/-F options as "git notes add".
If there is no existing note to append to, "git notes append" is identical
to "git notes add" (i.e. it adds a new note).
The patch includes tests verifying correct behaviour of the new subcommand.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git notes add" is identical to "git notes edit" except that instead of
editing existing notes for a given object, you can only add notes to an
object that currently has none. If "git notes add" finds existing notes
for the given object, the addition is aborted. However, if the new
-f/--force option is used, "git notes add" will _overwrite_ the existing
notes with the new notes contents.
If there is no existing notes for the given object. "git notes add" is
identical to "git notes edit" (i.e. it adds a new note).
The patch includes tests verifying correct behaviour of the new subcommand.
Suggested-by: Joey Hess <joey@kitenet.net>
Improved-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git notes list" will list all note objects in the current notes ref (in the
format "<note object> <annotated object>"). "git notes list <object>" will
list the note object associated with the given <object>, or fail loudly if
the given <object> has no associated notes.
If no arguments are given to "git notes", it defaults to the "list"
subcommand. This is for pseudo-compatibility with "git tag" and "git branch".
The patch includes tests verifying correct behaviour of the new subcommand.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git notes prune" will remove all notes that annotate unreachable/non-
existing objects.
The patch includes tests verifying correct behaviour of the new subcommand.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using "git notes remove" is equivalent to specifying an empty note message.
The patch includes tests verifying correct behaviour of the new subcommand.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the result of editing a note is an empty string, the associated note
entry should be deleted from the notes tree.
This allows deleting notes by invoking either "git notes -m ''" or
"git notes -F /dev/null".
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The note tree structure allows for non-note entries to coexist with note
entries in a notes tree. Although we certainly expect there to be very
few non-notes in a notes tree, we should still support them to a certain
degree.
This patch teaches the notes code to preserve non-notes when updating the
notes tree with write_notes_tree(). Non-notes are not affected by fanout
restructuring.
For non-notes to be handled correctly, we can no longer allow subtree
entries that do not match the fanout structure produced by the notes code
itself. This means that fanouts like 4/36, 6/34, 8/32, 4/4/32, etc. are
no longer recognized as note subtrees; only 2-based fanouts are allowed
(2/38, 2/2/36, 2/2/2/34, etc.). Since the notes code has never at any point
_produced_ non-2-based fanouts, it is highly unlikely that this change will
cause problems for anyone.
The patch also adds some tests verifying the correct handling of non-notes
in a notes tree.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a test verifying that the notes code automatically restructures the
notes tree into a deeper fanout level, when many notes are added with
"git notes".
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adds a testcase verifying that git-notes works successfully on
tree, blob, and tag objects.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The builtin-ification includes some minor behavioural changes to the
command-line interface: It is no longer allowed to mix the -m and -F
arguments, and it is not allowed to use multiple -F options.
As part of the builtin-ification, we add the commit_notes() function
to the builtin API. This function (together with the notes.h API) can
be easily used from other builtins to manipulate the notes tree.
Also includes needed changes to t3301.
This patch has been improved by the following contributions:
- Stephen Boyd: Use die() instead of fprintf(stderr, ...) followed by exit(1)
Cc: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Shell reports exit status only from the most downstream command
in a pipeline. In these tests, we want to make sure that the
command fails in a controlled way, and produces a correct error
message.
This issue was known by Jay who submitted the patch, and also was
pointed out by Hannes during the review process, but I forgot to
fix it up before applying. Sorry about that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-reflog-bad-timestamp:
t0101: use a fixed timestamp when searching in the reflog
Update @{bogus.timestamp} fix not to die()
approxidate_careful() reports errorneous date string
* sp/maint-push-sideband:
receive-pack: Send internal errors over side-band #2
t5401: Use a bare repository for the remote peer
Conflicts:
builtin-receive-pack.c
t/t5401-update-hooks.sh
If the client has requested side-band-64k capability, send any
of the internal error or warning messages in the muxed side-band
stream using the same band as our hook output, band #2. By putting
everything in one stream we ensure all messages are processed by
the side-band demuxer, avoiding interleaving between our own stderr
and the side-band demuxer's stderr buffers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We want to avoid the warnings (or later, test failures) about
updating the current branch. It was never my intention to have
this test deal with a repository with a working directory, and it
is a very old bug that the test even used a non-bare repository
for the remote side of the push operations.
This fixes the interleaved output error we were seeing as a test
failure by avoiding the giant warning message we were getting back
about updating the current branch being risky.
Its not a real fix, but is something we should do no matter what,
because the behavior will change in the future to reject, and the
test would break at that time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
8424981: "Fix invalid read in quote_c_style_counted" introduced a test
that used "caractère spécial" as a directory name.
Git creates it as "caract\303\250re sp\303\251cial"
OS X stores it as "caracte\314\200re spe\314\201cial"
To work around this problem, use the already introduced $FN as the
directory name.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
blame: prevent a segv when -L given start > EOF
git-push: document all the status flags used in the output
Fix parsing of imap.preformattedHTML and imap.sslverify
git-add documentation: Fix shell quoting example
blame would segv if given -L <lineno> with <lineno> past the end of the file.
While we're fixing the bug, add test cases for an invalid <start> when called
as -L <start>,<end> or -L<start>.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts most of commit a2430dde8c.
That commit made the situation better for repositories with relatively
small number of objects. However with many objects and a small pack size
limit, the time required to complete the repack tends towards O(n^2),
or even much worse with long delta chains.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently the only way to "quote" a grep pattern that might
begin with a dash is to use "git grep -e pattern". This
works just fine, and is also the way right way to do it on
many traditional grep implemenations.
Some people prefer to use "git grep -- pattern", however, as
"--" is the usual "end of options" marker, and at least GNU
grep and Solaris 10 grep support this. This patch makes that
syntax work.
There is a slight behavior change, in that "git grep -- $X"
used to be interpreted as "grep for -- in $X". However, that
usage is questionable. "--" is usually the end-of-options
marker, so "git grep" was unlike many other greps in
treating it as a literal pattern (e.g., both GNU grep and
Solaris 10 grep will treat "grep --" as missing a pattern).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code to guess an output archive's format consumed any --format
options and built a new one. Jonathan noticed that it does so in an
unsafe way, risking to overflow the static buffer fmt_opt.
Change the code to keep the existing --format options intact and to only
add a new one if a format could be guessed based on the output file name.
The new option is added as the first one, allowing the existing ones to
overrule it, i.e. explicit --format options given on the command line win
over format guesses, as before.
To simplify the code further, format_from_name() is changed to return the
full --format option, thus no potentially dangerous sprintf() calls are
needed any more.
Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This option causes the creation or updating of a file mapping CVS
(filename, revision number) pairs to Git commit IDs. This is expected
to be useful if you have CVS revision numbers stored in commit messages,
bug-tracking systems, email archives, and the like.
Signed-off-by: Aaron Crane <git@aaroncrane.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function did not work on strings that were not NUL-terminated. It
reads through a length-bounded string, searching for characters in need of
quoting. After we find one, we output the quoted character, then advance
our pointer to find the next one. However, we never decremented the
length, meaning we ended up looking at whatever random junk was stored
after the string.
This bug was not found by the existing tests because most code paths feed
a NUL-terminated string. The notable exception is a directory name being
fed by ls-tree.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Revert the previous attempt to skip this test on platforms where we
currently cannot determine the system load. We want to make sure that
the max-load-limit codepath produces results cleanly, when gitweb is
updated and becomes capable of reading the load average by some other
method.
The code to check for load returns 0 if it doesn't know how to find
load. It also checks to see if the current load is higher than the
max load. So to force the script to quit early by setting the maxload
variable negative which should work for systems where we can detect
load (which should be a positive number) and systems where we can't
(where detected load is 0)
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently gitweb only knows how to check for load using /proc/loadavg,
which isn't available on all systems. We shouldn't fail the test just
because we don't know how to check the system load.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sp/maint-push-sideband:
receive-pack: Send hook output over side band #2
receive-pack: Wrap status reports inside side-band-64k
receive-pack: Refactor how capabilities are shown to the client
send-pack: demultiplex a sideband stream with status data
run-command: support custom fd-set in async
run-command: Allow stderr to be a caller supplied pipe
Update git fsck --full short description to mention packs
Conflicts:
run-command.c
If the client requests to enable side-band-64k capability we can
safely send any hook stdout or stderr data down side band #2,
so the client can present it to the user.
If side-band-64k isn't enabled, hooks continue to inherit stderr
from the parent receive-pack process.
When the side band channel is being used the push client will wind up
prefixing all server messages with "remote: ", just like fetch does,
so our test vector has to be updated with the new expected output.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It seems that we have bad interaction with the code related to
GIT_WORK_TREE and "grep --no-index", and broke running grep inside
the .git directory. For now, just revert it and resurrect it after
1.7.0 ships.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The value passed to --max-pack-size used to count in MiB which was
inconsistent with the corresponding configuration variable as well as
other command arguments which are defined to count in bytes with an
optional unit suffix. This brings --max-pack-size in line with the
rest of Git.
Also, in order not to cause havoc with people used to the previous
megabyte scale, and because this is a sane thing to do anyway, a
minimum size of 1 MiB is enforced to avoid an explosion of pack files.
Adjust and extend test suite accordingly.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
First of all, trying to run 'git verify-pack' on packs produced by
the tests using pack.packSizeLimit always failed. After lots of digging
and head scratching, it turns out that the preceeding test simulating
a SHA1 collision did leave the repository quite confused, impacting
subsequent tests.
So let's move that destructive test last, and add tests to run
verify-pack on the output from those packSizeLimit tests to catch such
goofage.
Finally, group those packSizeLimit tests together.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ms/filter-branch-submodule:
filter-branch: Add tests for submodules in tree-filter
filter-branch: Fix to allow replacing submodules with another content
* 'jh/gitweb-caching' (early part):
gitweb: Add optional extra parameter to die_error, for extended explanation
gitweb: add a "string" variant of print_sort_th
gitweb: add a "string" variant of print_local_time
gitweb: Check that $site_header etc. are defined before using them
gitweb: Makefile improvements
gitweb: Load checking
gitweb: Make running t9501 test with '--debug' reliable and usable
* sp/maint-fast-import-large-blob:
fast-import: Stream very large blobs directly to pack
bash: don't offer remote transport helpers as subcommands
Conflicts:
fast-import.c
If a blob is larger than the configured big-file-threshold, instead
of reading it into a single buffer obtained from malloc, stream it
onto the end of the current pack file. Streaming the larger objects
into the pack avoids the 4+ GiB memory footprint that occurs when
fast-import is processing 2+ GiB blobs.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the same sprit as 4848509 (Fix permissions on test scripts,
2007-04-13), t/lib-patch-mode.sh should not be executable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* commit 'b319ef7': (8132 commits)
Add a small patch-mode testing library
git-apply--interactive: Refactor patch mode code
t8005: Nobody writes Russian in shift_jis
Fix severe breakage in "git-apply --whitespace=fix"
Update release notes for 1.6.4
After renaming a section, print any trailing variable definitions
Make section_name_match start on '[', and return the length on success
send-email: detect cycles in alias expansion
Show the presence of untracked files in the bash prompt.
SunOS grep does not understand -C<n> nor -e
Fix export_marks() error handling.
git repack: keep commits hidden by a graft
Add a test showing that 'git repack' throws away grafted-away parents
git branch: clean up detached branch handling
git branch: avoid unnecessary object lookups
git branch: fix performance problem
git svn: fix shallow clone when upstream revision is too new
do_one_ref(): null_sha1 check is not about broken ref
configure.ac: properly unset NEEDS_SSL_WITH_CRYPTO when sha1 func is missing
janitor: useless checks before free
...
4848509 (Fix permissions on test scripts, 2007-04-13) forgot to make
this included file non-executable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This changes slightly the behavior of gitweb, so that it verifies
that the box isn't inundated with before attempting to serve gitweb.
If the box is overloaded, it basically returns a 503 Server Unavailable
until the load falls below the defined threshold. This helps dramatically
if you have a box that's I/O bound, reaches a certain load and you
don't want gitweb, the I/O hog that it is, increasing the pain the
server is already undergoing.
This behavior is controlled by $maxload configuration variable.
Default is a load of 300, which for most cases should never be hit.
Unset it (set it to undefined value, i.e. undef) to turn off checking.
Currently it requires that '/proc/loadavg' file exists, otherwise the
load check is bypassed (load is taken to be 0). So platforms that do
not implement '/proc/loadavg' currently cannot use this feature
(provisions are included for additional checks to be added by others).
There is simple test in t/t9501-gitweb-standalone-http-status.sh to
check that it correctly returns "503 Service Unavailable" if load is
too high, and also if there are any Perl warnings or errors.
Signed-off-by: John 'Warthog9' Hawley <warthog9@kernel.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove test_debug lines after 'snapshots: tgz only default format
enabled' and 'snapshots: all enabled in default, use default disabled
value' tests. Those tests constitute of multiple gitweb_run
invocation, therefore outputting gitweb.output for the last gitweb_run
wouldn't help much in debugging test failure, and can only confuse.
For snapshot tests which check for "200 OK" status, change
test_debug 'cat gitweb.output'
to
test_debug 'cat gitweb.headers'
Otherwise when running this test with '--debug' option,
t/t9501-gitweb-standalone-http-status.sh would dump *binary data* (the
snapshot itself) to standard output, which can mess up state of terminal
due to term control characters which can be embedded in output.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old "advice" message explained how to create a branch after going into
a detached HEAD state but didn't make it clear why the user may want to do
so. Also "moving to ... which isn't a local branch" was unclear if it is
complaining, if it is describing the new state, or if it is explaining why
the HEAD is detached (the true reason is the last one).
Give the established phrase 'detached HEAD' first to make it easy for
users to look up the concept in documentation, and briefly describe what
can be done in the state (i.e. play around without having to clean up)
before telling the user how to keep what was done during the temporary
state.
Allow the long description to be hidden by setting advice.detachedHead
configuration to false.
We might want to customize the advice depending on how the commit to check
out was spelled (e.g. instead of "new-branch-name", we way want to say
"topic" when "git checkout origin/topic" triggered this message) in later
updates, but this encapsulates that into a separate function and it should
be a good first step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add tests to make sure that:
1) a submodule can be removed and its content replaced with regular files
('rewrite submodule with another content'). This test passes only with
the previous patch applied.
2) it is possible to replace submodule revision by direct index
manipulation ('replace submodule revision'). Although it would be
better to run such a filter in --index-filter, this test shows that
this functionality is not broken by the previous patch. This succeeds
both with and without the previous patch.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Something like foo@{-1} is nonsensical, as the @{-N} syntax
is reserved for "the Nth last branch", and is not an actual
reflog selector. We should not feed such nonsense to
approxidate at all.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously interpret_branch_name would see @{-1} and stop
parsing, leaving the @{u} as cruft that provoked an error.
Instead, we should recurse if there is more to parse.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that we have several different types of @{} syntax, it
is a good idea to test them together, which reveals some
failures.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original version used relative approxidates, which don't
reproduce as reliably as absolute ones. Commit 6c647a fixed
this for one case, but missed the "silly" case.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"diff --cc" output t4038 tests was fixed by b810cbb (diff --cc: a lost
line at the beginning of the file is shown incorrectly, 2009-07-22), which
was actually the commit that introduced this test..
An error in "git merge -s resolve" t6035 tests was fixed by 730f728
(unpack-trees.c: look ahead in the index, 2009-09-20).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-reflog-bad-timestamp:
t0101: use a fixed timestamp when searching in the reflog
Update @{bogus.timestamp} fix not to die()
approxidate_careful() reports errorneous date string
* jl/diff-submodule-ignore:
Teach diff --submodule that modified submodule directory is dirty
git diff: Don't test submodule dirtiness with --ignore-submodules
Make ce_uptodate() trustworthy again
Using a dollar sign in double quotes isn't portable. Escape them with
a backslash or replace the double quotes with single quotes.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For a long time, the time based reflog syntax (e.g. master@{yesterday})
didn't complain when the "human readable" timestamp was misspelled, as
the underlying mechanism tried to be as lenient as possible. The funny
thing was that parsing of "@{now}" even relied on the fact that anything
not recognized by the machinery returned the current timestamp.
Introduce approxidate_careful() that takes an optional pointer to an
integer, that gets assigned 1 when the input does not make sense as a
timestamp.
As I am too lazy to fix all the callers that use approxidate(), most of
the callers do not take advantage of the error checking, but convert the
code to parse reflog to use it as a demonstration.
Tests are mostly from Jeff King.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When your current directory is not at the root of the working tree, and you
use the "-f" option with a relative path, the current code tries to read
from a wrong file, since argv[2] is now beyond the end of the rearranged
argument list.
This patch replaces the incorrect argv[2] with the variable holding the
given config file name.
The bug was introduced by d64ec16 (git config: reorganize to use parseopt).
[jc: added test]
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Historically, any grep filter in "git log" family of commands were taken
as restricting to commits with any of the words in the commit log message.
However, the user almost always want to find commits "done by this person
on that topic". With "--all-match" option, a series of grep patterns can
be turned into a requirement that all of them must produce a match, but
that makes it impossible to ask for "done by me, on either this or that"
with:
log --author=me --committer=him --grep=this --grep=that
because it will require both "this" and "that" to appear.
Change the "header" parser of grep library to treat the headers specially,
and parse it as:
(all-match-OR (HEADER-AUTHOR me)
(HEADER-COMMITTER him)
(OR
(PATTERN this)
(PATTERN that) ) )
Even though the "log" command line parser doesn't give direct access to
the extended grep syntax to group terms with parentheses, this change will
cover the majority of the case the users would want.
This incidentally revealed that one test in t7002 was bogus. It ran:
log --author=Thor --grep=Thu --format='%s'
and expected (wrongly) "Thu" to match "Thursday" in the author/committer
date, but that would never match, as the timestamp in raw commit buffer
does not have the name of the day-of-the-week.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The patch detection wants to inspect all the headers of a rfc2822 message
and ensure that they look like header fields. The headers are always
separated from the message body with a blank line. When Thunderbird saves
the message the blank line separating the headers from the body includes a
CR. The patch detection is failing because a CRLF doesn't match /^$/. Fix
this by allowing a CR to exist on the separating line.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We shouldn't have literal CR's in tests as they aren't portable.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
append_cr(), remove_cr(), q_to_nul() and q_to_cr() are defined in multiple
tests. Consolidate them into test-lib.sh so we can stop redefining them.
The use of remove_cr() in t0020 to test for a CR is replaced with a new
function has_cr() to accurately reflect what is intended (the output of
remove_cr() was being thrown away).
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't feed a multiple-line pattern to grep and expect the them to match
with lines in order.
Simplify the grep expressions in the non-fast-forward tests to check
only for the first line of the non-fast-forward warning - having that
line should be enough assurance that the full warning is printed.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit 8e08b4 git diff does append "-dirty" to the work tree side
if the working directory of a submodule contains new or modified files.
Lets do the same when the --submodule option is used.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This shows that with the "--keep" option, changes that are both in
the work tree and the index are kept in the work tree after the
reset (but discarded in the index).
In the case of unmerged entries, we can see that "git reset --keep"
works only when the target state is the same as HEAD. And then the
work tree is not reset.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/fix-tree-walk:
read-tree --debug-unpack
unpack-trees.c: look ahead in the index
unpack-trees.c: prepare for looking ahead in the index
Aggressive three-way merge: fix D/F case
traverse_trees(): handle D/F conflict case sanely
more D/F conflict tests
tests: move convenience regexp to match object names to test-lib.sh
Conflicts:
builtin-read-tree.c
unpack-trees.c
unpack-trees.h
14e5d40 (pull: Fix parsing of -X<option>, 2010-01-17) forgot that
merge_name needs to stay as a single non-interpolated string.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
git-svn: allow subset of branches/tags to be specified in glob spec
git-svn: allow UUID to be manually remapped via rewriteUUID
git-svn: update svn mergeinfo test suite
git-svn: document --username/commit-url for branch/tag
git-svn: add --username/commit-url options for branch/tag
git-svn: respect commiturl option for branch/tag
git-svn: fix mismatched src/dst errors for branch/tag
git-svn: handle merge-base failures
git-svn: ignore changeless commits when checking for a cherry-pick
For very large projects it is useful to be able to clone a subset of the
upstream SVN repo's branches. Allow for this by letting the left-side of
the branches and tags glob specs contain a brace-delineated comma-separated
list of names. e.g.:
branches = branches/{red,green}/src:refs/remotes/branches/*
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
In certain situations it may be necessary to manually remap an svn
repostitory UUID. For example:
o--- [git-svn clone]
/
[origin svn repo]
\
o--- [svnsync clone]
Imagine that only "git-svn clone" and "svnsync clone" are made available
to external users. Furthur, "git-svn clone" contains only trunk, and for
reasons unknown, "svnsync clone" is missing the revision properties that
normally provide the origin svn repo's UUID.
A git user who has cloned the "git-svn clone" repo now wishes to use
git-svn to pull in the missing branches from the "synsync clone" repo.
In order for git-svn to get the history correct for those branches,
it needs to know the origin svn repo's UUID. Hence rewriteUUID.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Add a partial branch (e.g., a branch from a project subdirectory) to the
git-svn mergeinfo test repository.
Add a tag and a branch from that tag to the git-svn mergeinfo test repository.
Update the test script to expect a known failure in git-svn exposed by these
additions where merge info for partial branches is not preserved.
Signed-off-by: Andrew Myrick <amyrick@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
4cacc621 made difftool fall back to mergetool.prompt
when difftool.prompt is unconfigured. This adds a test.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jl/submodule-diff:
Performance optimization for detection of modified submodules
git status: Show uncommitted submodule changes too when enabled
Teach diff that modified submodule directory is dirty
Show submodules as modified when they contain a dirty work tree
The function takes two paths, an early part of abs is supposed to match
base; otherwise abs is not a path under base and the function returns the
full path of abs. The caller can easily confuse the implementation by
giving duplicated and needless slashes in these path arguments.
Credit for test script, motivation and initial patch goes to Thomas Rast.
A follow-up fix (squashed) is by Hannes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code used as if return value from basename(3) were stable, but
often the function is implemented to return a pointer to a static
storage internal to it.
Because basename(3) is also allowed to modify its input parameter in
place, casting constness away from the strings we obtained from the
caller and giving them to basename is a no-no.
Reported, and initial fix and test supplied by David Rydh.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reported by: Johannes Sixt <j.sixt@viscovery.net>
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It forgot to apply the prefix to the paths given on the command line.
[jc: added test]
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ap/merge-backend-opts:
Document that merge strategies can now take their own options
Extend merge-subtree tests to test -Xsubtree=dir.
Make "subtree" part more orthogonal to the rest of merge-recursive.
pull: Fix parsing of -X<option>
Teach git-pull to pass -X<option> to git-merge
git merge -X<option>
git-merge-file --ours, --theirs
Conflicts:
git-compat-util.h
* 'jh/notes' (early part):
Add more testcases to test fast-import of notes
Rename t9301 to t9350, to make room for more fast-import tests
fast-import: Proper notes tree manipulation
Giving "Notes" information in the default output format of "log" and
"show" is a sensible progress (the user has asked for it by having the
notes), but for some commands (e.g. "format-patch") spewing notes into the
formatted commit log message without being asked is too aggressive.
Enable notes output only for "log", "show", "whatchanged" by default and
only when the user didn't ask any specific --pretty/--format from the
command line; users can explicitly override this default with --show-notes
and --no-notes option.
Parts of tests are taken from Jeff King's fix.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/cache-unmerge:
rerere forget path: forget recorded resolution
rerere: refactor rerere logic to make it independent from I/O
rerere: remove silly 1024-byte line limit
resolve-undo: teach "update-index --unresolve" to use resolve-undo info
resolve-undo: "checkout -m path" uses resolve-undo information
resolve-undo: allow plumbing to clear the information
resolve-undo: basic tests
resolve-undo: record resolved conflicts in a new index extension section
builtin-merge.c: use standard active_cache macros
Conflicts:
builtin-ls-files.c
builtin-merge.c
builtin-rerere.c
* js/exec-error-report:
Improve error message when a transport helper was not found
start_command: detect execvp failures early
run-command: move wait_or_whine earlier
start_command: report child process setup errors to the parent's stderr
Conflicts:
Makefile
* jc/ls-files-ignored-pathspec:
ls-files: fix overeager pathspec optimization
read_directory(): further split treat_path()
read_directory_recursive(): refactor handling of a single path into a separate function
t3001: test ls-files -o ignored/dir
* jc/grep-lookahead:
grep --no-index: allow use of "git grep" outside a git repository
grep: prepare to run outside of a work tree
grep: rip out pessimization to use fixmatch()
grep: rip out support for external grep
grep: optimize built-in grep by skipping lines that do not hit
Conflicts:
builtin-grep.c
t/t7002-grep.sh
* da/difftool:
difftool: Update copyright notices to list each year separately
difftool: Use eval to expand '--extcmd' expressions
difftool: Add '-x' and as an alias for '--extcmd'
t7800-difftool.sh: Simplify the --extcmd test
git-diff.txt: Link to git-difftool
difftool: Allow specifying unconfigured commands with --extcmd
difftool--helper: Remove use of the GIT_MERGE_TOOL variable
difftool--helper: Update copyright and remove distracting comments
git-difftool: Add '--gui' for selecting a GUI tool
t7800-difftool: Set a bogus tool for use by tests
* mh/rebase-fixup:
rebase -i: Retain user-edited commit messages after squash/fixup conflicts
t3404: Set up more of the test repo in the "setup" step
rebase -i: For fixup commands without squashes, do not start editor
rebase -i: Change function make_squash_message into update_squash_message
rebase -i: Extract function do_with_author
rebase -i: Handle the author script all in one place in do_next
rebase -i: Extract a function "commit_message"
rebase -i: Simplify commit counting for generated commit messages
rebase -i: Improve consistency of commit count in generated commit messages
t3404: Test the commit count in commit messages generated by "rebase -i"
rebase -i: Introduce a constant AMEND
rebase -i: Introduce a constant AUTHOR_SCRIPT
rebase -i: Document how temporary files are used
rebase -i: Use symbolic constant $MSG consistently
rebase -i: Use "test -n" instead of "test ! -z"
rebase -i: Inline expression
rebase -i: Remove dead code
rebase -i: Make the condition for an "if" more transparent
* 'mh/rebase-fixup' (early part):
rebase-i: Ignore comments and blank lines in peek_next_command
lib-rebase: Allow comments and blank lines to be added to the rebase script
lib-rebase: Provide clearer debugging info about what the editor did
Add a command "fixup" to rebase --interactive
t3404: Use test_commit to set up test repository
* jk/warn-author-committer-after-commit:
user_ident_sufficiently_given(): refactor the logic to be usable from elsewhere
commit.c::print_summary: do not release the format string too early
commit: allow suppression of implicit identity advice
commit: show interesting ident information in summary
strbuf: add strbuf_addbuf_percentquote
strbuf_expand: convert "%%" to "%"
Conflicts:
builtin-commit.c
ident.c
* tr/http-push-ref-status:
transport-helper.c::push_refs(): emit "no refs" error message
transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
transport.c::transport_push(): make ref status affect return value
refactor ref status logic for pushing
t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
t5541-http-push.sh: add tests for non-fast-forward pushes
Conflicts:
transport-helper.c
* sb/maint-octopus:
octopus: remove dead code
octopus: reenable fast-forward merges
octopus: make merge process simpler to follow
Conflicts:
git-merge-octopus.sh
* maint-1.6.5:
Git 1.6.5.8
Fix mis-backport of t7002
bash completion: factor submodules into dirty state
reset: unbreak hard resets with GIT_WORK_TREE
Conflicts:
Documentation/git.txt
GIT-VERSION-GEN
RelNotes
Since local branch, tags and remote tracking branch namespaces are
most often used, add shortcut notations for globbing those in
manner similar to --glob option.
With this, one can express the "what I have but origin doesn't?"
as:
'git log --branches --not --remotes=origin'
Original-idea-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add --glob=<glob-pattern> option to rev-parse and everything that
accepts its options. This option matches all refs that match given
shell glob pattern (complete with some DWIM logic).
Example:
'git log --branches --not --glob=remotes/origin'
To show what you have that origin doesn't.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches @{upstream} syntax to interpret_branch_name(), instead
of dwim_ref() machinery.
There are places in git UI that behaves differently when you give a local
branch name and when you give an extended SHA-1 expression that evaluates
to the commit object name at the tip of the branch. The intent is that
the special syntax such as @{-1} can stand in as if the user spelled the
name of the branch in such places.
The name of the branch "frotz" to switch to ("git checkout frotz"), and
the name of the branch "nitfol" to fork a new branch "frotz" from ("git
checkout -b frotz nitfol"), are examples of such places. These places
take only the name of the branch (e.g. "frotz"), and they are supposed to
act differently to an equivalent refname (e.g. "refs/heads/frotz"), so
hooking the @{upstream} and @{-N} syntax to dwim_ref() is insufficient
when we want to deal with cases a local branch is forked from another
local branch and use "forked@{upstream}" to name the forkee branch.
The "upstream" syntax "forked@{u}" is to specify the ref that "forked" is
configured to merge with, and most often the forkee is a remote tracking
branch, not a local branch. We cannot simply return a local branch name,
but that does not necessarily mean we have to returns the full refname
(e.g. refs/remotes/origin/frotz, when returning origin/frotz is enough).
This update calls shorten_unambiguous_ref() to do so.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds a few more tests that exercises @{upstream} syntax by commands
that operate differently when they are given branch name as opposed to a
refname (i.e. where "master" and "refs/heads/master" makes a difference).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.4:
Fix mis-backport of t7002
base85: Make the code more obvious instead of explaining the non-obvious
base85: encode_85() does not use the decode table
base85 debug code: Fix length byte calculation
checkout -m: do not try to fall back to --merge from an unborn branch
branch: die explicitly why when calling "git branch [-a|-r] branchname".
textconv: stop leaking file descriptors
commit: --cleanup is a message option
git count-objects: handle packs bigger than 4G
t7102: make the test fail if one of its check fails
* maint-1.6.3:
base85: Make the code more obvious instead of explaining the non-obvious
base85: encode_85() does not use the decode table
base85 debug code: Fix length byte calculation
checkout -m: do not try to fall back to --merge from an unborn branch
branch: die explicitly why when calling "git branch [-a|-r] branchname".
textconv: stop leaking file descriptors
commit: --cleanup is a message option
git count-objects: handle packs bigger than 4G
t7102: make the test fail if one of its check fails
Conflicts:
builtin-commit.c
* maint-1.6.2:
base85: Make the code more obvious instead of explaining the non-obvious
base85: encode_85() does not use the decode table
base85 debug code: Fix length byte calculation
checkout -m: do not try to fall back to --merge from an unborn branch
branch: die explicitly why when calling "git branch [-a|-r] branchname".
textconv: stop leaking file descriptors
commit: --cleanup is a message option
git count-objects: handle packs bigger than 4G
t7102: make the test fail if one of its check fails
Conflicts:
diff.c
The original patch that became cfe370c (grep: do not segfault when -f is
used, 2009-10-16), was made against "maint" or newer branch back then, but
the fix addressed the issue that was present as far as in 1.6.4 series.
The maintainer backported the patch to the 1.6.4 maintenance branch, but
failed to notice that the new tests assumed the setup done by the script
in "maint", which did quite a lot more than the same test script in 1.6.4
series, and the output didn't match the expected result.
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add --set-upstream option to branch that works like --track, except that
when branch exists already, its upstream info is changed without changing
the ref value.
Based-on-patch-from: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitdiff_verify_name() only did a filename prefix check because of an
off-by-one error.
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add 'git remote set-url' for changing URL of remote repository with
one "porcelain-level" command.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
find_name() wrongly returned the whole filename for filenames without
enough leading pathname components (e.g., when applying a patch to a
top-level file with -p2).
Include the -p value used in the error message when no filenames can be
found.
[jc: squashed a test from Nanako Shiraishi]
Signed-off-by: Andreas Gruenbacher <agruen@suse.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This tests the configurable -Xsubtree feature of merge-recursive.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This needs the usual sq then eval trick to allow IFS characters
in the option.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach "-X <option>" command line argument to "git merge" that is passed to
strategy implementations. "ours" and "theirs" autoresolution introduced
by the previous commit can be asked to the recursive strategy.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jh/commit-status:
t7502: test commit.status, --status and --no-status
commit: support commit.status, --status, and --no-status
Conflicts:
Documentation/git-commit.txt
builtin-commit.c
* tc/clone-v-progress:
clone: use --progress to force progress reporting
clone: set transport->verbose when -v/--verbose is used
git-clone.txt: reword description of progress behaviour
check stderr with isatty() instead of stdout when deciding to show progress
Conflicts:
transport.c
* tc/smart-http-restrict:
Test t5560: Fix test when run with dash
Smart-http tests: Test http-backend without curl or a webserver
Smart-http tests: Break test t5560-http-backend into pieces
Smart-http tests: Improve coverage in test t5560
Smart-http: check if repository is OK to export before serving it
* jk/run-command-use-shell:
t4030, t4031: work around bogus MSYS bash path conversion
diff: run external diff helper with shell
textconv: use shell to run helper
editor: use run_command's shell feature
run-command: optimize out useless shell calls
run-command: convert simple callsites to use_shell
t0021: use $SHELL_PATH for the filter script
run-command: add "use shell" option
* sr/gfi-options:
fast-import: add (non-)relative-marks feature
fast-import: allow for multiple --import-marks= arguments
fast-import: test the new option command
fast-import: add option command
fast-import: add feature command
fast-import: put marks reading in its own function
fast-import: put option parsing code in separate functions
When the configuration variable status.submodulesummary is not 0 or
false, "git status" shows the submodule summary of the staged submodule
commits. But it did not show the summary of those commits not yet
staged in the supermodule, making it hard to see what will not be
committed.
The output of "submodule summary --for-status" has been changed from
"# Modified submodules:" to "# Submodule changes to be committed:" for
the already staged changes. "# Submodules changed but not updated:" has
been added for changes that will not be committed. This is much clearer
and consistent with the output for regular files.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A diff run in superproject only compares the name of the commit object
bound at the submodule paths. When we compare with a work tree and the
checked out submodule directory is dirty (e.g. has either staged or
unstaged changes, or has new files the user forgot to add to the index),
show the work tree side as "dirty".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Until now a submodule only then showed up as modified in the supermodule
when the last commit in the submodule differed from the one in the index
or the diffed against commit of the superproject. A dirty work tree
containing new untracked or modified files in a submodule was
undetectable when looking at it from the superproject.
Now git status and git diff (against the work tree) in the superproject
will also display submodules as modified when they contain untracked or
modified files, even if the compared ref matches the HEAD of the
submodule.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Frequent complaint is lack of easy way to set up upstream (tracking)
references for git pull to work as part of push command. So add switch
--set-upstream (-u) to do just that.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When testing what happens on unmerged entries, the HEAD is the
commit we are starting from before the merge that fails and create
the unmerged entries. It is not the commit before.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A command invocation preceded by variable assignments, i.e.
VAR1=VAL1 VAR2=VAL2 ... command args
are implemented by dash and ksh in such a way not to export these
variables, and keep the values after the command finishes, when the
command is a shell function. POSIX.1 "2.9.5 Function Definition Command"
specifies this behaviour.
Many shells however treat this construct the same way as they are calling
external commands. They export the variables during the duration of
command, and resets their values after command returns.
The test relied on the behaviour of the latter kind.
Reported-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was not possible to pass quoted commands to '--extcmd'.
By using 'eval' we ensure that expressions with spaces and
quotes are supported.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds '-x' as a shorthand for the '--extcmd' option.
Arguments to '--extcmd' can be specified separately, which
was not originally possible.
This also fixes the brief help text so that it mentions
both '-x' and '--extcmd'.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of running 'grep', 'echo', and 'wc' we simply compare
git-difftool's output against a known good value.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Just like some people wanted diff features that are not found in
other people's diff implementations outside of a git repository
and added --no-index mode to the command, this adds --no-index mode
to the "git grep" command.
Also, inside a git repository, --no-index mode allows you to grep
in untracked (but not ignored) files.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are a few cases of user identity information that we consider
interesting:
(1) When the author and committer identities do not match.
(2) When the committer identity was picked automatically from the
username, hostname and GECOS information.
In these cases, we already show the information in the commit
message template. However, users do not always see that template
because they might use "-m" or "-F". With this patch, we show these
interesting cases after the commit, along with the subject and
change summary. The new output looks like:
$ git commit \
-m "federalist papers" \
--author='Publius <alexander@hamilton.com>'
[master 3d226a7] federalist papers
Author: Publius <alexander@hamilton.com>
1 files changed, 1 insertions(+), 0 deletions(-)
for case (1), and:
$ git config --global --unset user.name
$ git config --global --unset user.email
$ git commit -m foo
[master 7c2a927] foo
Committer: Jeff King <peff@c-71-185-130-222.hsd1.va.comcast.net>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:
git config --global user.name Your Name
git config --global user.email you@example.com
If the identity used for this commit is wrong, you can fix it with:
git commit --amend --author='Your Name <you@example.com>'
1 files changed, 1 insertions(+), 0 deletions(-)
for case (2).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The only way to safely quote arbitrary text in a pretty-print user
format is to replace instances of "%" with "%x25". This is slightly
unreadable, and many users would expect "%%" to produce a single
"%", as that is what printf format specifiers do.
This patch converts "%%" to "%" for all users of strbuf_expand():
(1) git-daemon interpolated paths
(2) pretty-print user formats
(3) merge driver command lines
Case (1) was already doing the conversion itself outside of
strbuf_expand(). Case (2) is the intended beneficiary of this patch.
Case (3) users probably won't notice, but as this is user-facing
behavior, consistently providing the quoting mechanism makes sense.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a squash/fixup fails due to a conflict, the user is required to
edit the commit message. Previously, if further squash/fixup commands
followed the conflicting squash/fixup, this user-edited message was
discarded and a new automatically-generated commit message was
suggested.
Change the handling of conflicts within squash/fixup command series:
Whenever the user is required to intervene, consider the resulting
commit to be a new basis for the following squash/fixups and use its
commit message in later suggested combined commit messages.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
...and reuse these pre-created branches in tests rather than creating
duplicates.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the "rebase -i" commands include a series of fixup commands without
any squash commands, then commit the combined commit using the commit
message of the corresponding "pick" without starting up the
commit-message editor.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the numeral "2" instead of the word "two" when two commits are
being interactively squashed. This makes the treatment consistent
with that for higher numbers of commits.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The first line of commit messages generated for "rebase -i"
squash/fixup commits includes a count of the number of commits that
are being combined. Add machinery to check that this count is
correct, and add such a check to some test cases.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/checkout-merge-base:
rebase -i: teach --onto A...B syntax
rebase: fix --onto A...B parsing and add tests
"rebase --onto A...B" replays history on the merge base between A and B
"checkout A...B" switches to the merge base between A and B
* cc/reset-more:
t7111: check that reset options work as described in the tables
Documentation: reset: add some missing tables
Fix bit assignment for CE_CONFLICTED
"reset --merge": fix unmerged case
reset: use "unpack_trees()" directly instead of "git read-tree"
reset: add a few tests for "git reset --merge"
Documentation: reset: add some tables to describe the different options
reset: improve mixed reset error message when in a bare repo
* nd/sparse: (25 commits)
t7002: test for not using external grep on skip-worktree paths
t7002: set test prerequisite "external-grep" if supported
grep: do not do external grep on skip-worktree entries
commit: correctly respect skip-worktree bit
ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
tests: rename duplicate t1009
sparse checkout: inhibit empty worktree
Add tests for sparse checkout
read-tree: add --no-sparse-checkout to disable sparse checkout support
unpack-trees(): ignore worktree check outside checkout area
unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
unpack-trees.c: generalize verify_* functions
unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
Introduce "sparse checkout"
dir.c: export excluded_1() and add_excludes_from_file_1()
excluded_1(): support exclude files in index
unpack-trees(): carry skip-worktree bit over in merged_entry()
Read .gitignore from index if it is skip-worktree
Avoid writing to buffer in add_excludes_from_file_1()
...
Conflicts:
.gitignore
Documentation/config.txt
Documentation/git-update-index.txt
Makefile
entry.c
t/t7002-grep.sh
Make sure that the status information:
- is shown as before without configuration nor command line option;
- is shown if commit.status is set to true and no command line option
is given, or --status is explicitly given;
- is not shown if commit.status is set to false and no command line
option is given, or --no-status is explicitly given.
Also make sure that the way lines taken from the custom --template appear
in the log message editor is not changed at all.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
remote-curl: Fix Accept header for smart HTTP connections
grep: -L should show empty files
rebase--interactive: Ignore comments and blank lines in peek_next_command
A new notation '<branch>@{upstream}' refers to the branch <branch> is set
to build on top of. Missing <branch> (i.e. '@{upstream}') defaults to the
current branch.
This allows you to run, for example,
for l in list of local branches
do
git log --oneline --left-right $l...$l@{upstream}
done
to inspect each of the local branches you are interested in for the
divergence from its upstream.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Various commands refuse to run in the presence of conflicts (commit,
merge, pull, cherry-pick/revert). They all used to provide rough, and
inconsistant error messages.
A new variable advice.resolveconflict is introduced, and allows more
verbose messages, pointing the user to the appropriate solution.
For commit, the error message used to look like this:
$ git commit
foo.txt: needs merge
foo.txt: unmerged (c34a92682e0394bc0d6f4d4a67a8e2d32395c169)
foo.txt: unmerged (3afcd75de8de0bb5076942fcb17446be50451030)
foo.txt: unmerged (c9785d77b76dfe4fb038bf927ee518f6ae45ede4)
error: Error building trees
The "need merge" line is given by refresh_cache. We add the IN_PORCELAIN
option to make the output more consistant with the other porcelain
commands, and catch the error in return, to stop with a clean error
message. The next lines were displayed by a call to cache_tree_update(),
which is not reached anymore if we noticed the conflict.
The new output looks like:
U foo.txt
fatal: 'commit' is not possible because you have unmerged files.
Please, fix them up in the work tree, and then use 'git add/rm <file>' as
appropriate to mark resolution and make a commit, or use 'git commit -a'.
Pull is slightly modified to abort immediately if $GIT_DIR/MERGE_HEAD
exists instead of waiting for merge to complain.
The behavior of merge and the test-case are slightly modified to reflect
the usual flow: start with conflicts, fix them, and afterwards get rid of
MERGE_HEAD, with different error messages at each stage.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We actually expect to see an application/x-git-upload-pack-result
but we lied and said we Accept *-response. This was a typo on my
part when I was writing the code.
Fortunately the wrong Accept header had no real impact, as the
deployed git-http-backend servers were not testing the Accept
header before they returned their content.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, blank lines and/or comments within a series of
squash/fixup commands would confuse "git rebase -i" into thinking that
the series was finished. It would therefore require the user to edit
the commit message for the squash/fixup commits seen so far. Then,
after continuing, it would ask the user to edit the commit message
again.
Ignore comments and blank lines within a group of squash/fixup
commands, allowing them to be processed in one go.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
(For testing "rebase -i"): Support new action types in $FAKE_LINES to
allow comments and blank lines to be added to the "rebase -i" command
list.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
(For testing "rebase -i"): Output the "rebase -i" command script
before and after the edits, to make it clearer what the editor did.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the unlink_entry function to use rmdir to remove submodule
directories. Currently we try to use unlink, which will never succeed.
Of course rmdir will only succeed for empty (i.e. not checked out)
submodule directories. Behaviour if a submodule is checked out stays
essentially the same: print a warning message and keep the submodule
directory.
Signed-off-by: Peter Collingbourne <peter@pcc.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After you find out an earlier resolution you told rerere to use was a
mismerge, there is no easy way to clear it. A new subcommand "forget" can
be used to tell git to forget a recorded resolution, so that you can redo
the merge from scratch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, failures during execvp could be detected only by
finish_command. However, in some situations it is beneficial for the
parent process to know earlier that the child process will not run.
The idea to use a pipe to signal failures to the parent process and
the test case were lifted from patches by Ilari Liusvaara.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.1:
base85: Make the code more obvious instead of explaining the non-obvious
base85: encode_85() does not use the decode table
base85 debug code: Fix length byte calculation
checkout -m: do not try to fall back to --merge from an unborn branch
branch: die explicitly why when calling "git branch [-a|-r] branchname".
textconv: stop leaking file descriptors
commit: --cleanup is a message option
git count-objects: handle packs bigger than 4G
t7102: make the test fail if one of its check fails
Conflicts:
diff.c
* maint-1.6.0:
base85: Make the code more obvious instead of explaining the non-obvious
base85: encode_85() does not use the decode table
base85 debug code: Fix length byte calculation
checkout -m: do not try to fall back to --merge from an unborn branch
branch: die explicitly why when calling "git branch [-a|-r] branchname".
Commit 842abf0 (Teach resolve_gitlink_ref() about the .git file, 2008-02-20)
taught resolve_gitlink_ref() to call read_gitfile_gently() to resolve .git
files. In this commit teach read_gitfile_gently() to interpret a relative
path in a .git file with respect to the file location.
This change allows update-index to recognize a submodule that uses a relative
path in its .git file. It previously failed because the relative path was
wrongly interpreted with respect to the superproject directory.
Signed-off-by: Brad King <brad.king@kitware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check that update-index recognizes a submodule that uses a .git file.
Currently it works when the .git file specifies an absolute path, but
not when it specifies a relative path.
Signed-off-by: Brad King <brad.king@kitware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some previous patches added some tables to the "git reset"
documentation. These tables describe the behavior of "git reset"
depending on the option it is passed and the state of the files
in the working tree, the index, HEAD and the target commit.
This patch adds some tests to make sure that the tables describe
the behavior of "git reset".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the status of a ref is REF_STATUS_NONE, the remote helper will not
be told to push the ref (via a 'push' command).
However, the remote helper may still act on these refs.
If the helper does act on the ref, and prints a status for it, ignore
the report (ie. don't overwrite the status of the ref with it, nor the
message in the remote_status member) if the reported status is 'no
match'.
This allows the user to be alerted to more "interesting" ref statuses,
like REF_STATUS_NONFASTFORWARD.
Cc: Jeff King <peff@peff.net>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use push_had_errors() to check the refs for errors and modify the
return value.
Mark the non-fast-forward push tests to succeed.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the logic that detects up-to-date and non-fast-forward refs to a
new function in remote.[ch], set_ref_status_for_push().
Make transport_push() invoke set_ref_status_for_push() before invoking
the push_refs() implementation. (As a side-effect, the push_refs()
implementation in transport-helper.c now knows of non-fast-forward
pushes.)
Removed logic for detecting up-to-date refs from the push_refs()
implementation in transport-helper.c, as transport_push() has already
done so for it.
Make cmd_send_pack() invoke set_ref_status_for_push() before invoking
send_pack(), as transport_push() can't do it for send_pack() here.
Mark the test on the return status of non-fast-forward push to fail.
Git now exits with success, as transport.c::transport_push() does not
check for refs with status REF_STATUS_REJECT_NONFASTFORWARD nor does it
indicate rejected pushes with its return value.
Mark the test for ref status to succeed. As mentioned earlier, refs
might be marked as non-fast-forwards, triggering the push status
printing mechanism in transport.c.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some refs can only be matched to a remote ref with an explicit refspec.
When such a ref is a non-fast-forward of its remote ref, test that
pushing them (with the explicit refspec specified) fails with a non-
fast-foward-type error (viz. printing of ref status and help message).
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-difftool requires difftool.<tool>.cmd configuration even when
tools use the standard "$diffcmd $from $to" form. This teaches
git-difftool to run these tools in lieu of configuration by
allowing the command to be specified on the command line.
Reference: http://article.gmane.org/gmane.comp.version-control.git/133377
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An undocumented mis-feature in git-difftool is that it allows you
to specify a default difftool by setting GIT_MERGE_TOOL.
This behavior was never documented and was included as an
oversight back when git-difftool was maintained outside of git.
git-mergetool never honored GIT_MERGE_TOOL so neither should
git-difftool.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Given pathspecs that share a common prefix, ls-files optimized its call
into recursive directory reader by starting at the common prefix
directory.
If you have a directory "t" with an untracked file "t/junk" in it, but the
top-level .gitignore file told us to ignore "t/", this resulted in:
$ git ls-files -o --exclude-standard
$ git ls-files -o --exclude-standard t/
t/junk
$ git ls-files -o --exclude-standard t/junk
t/junk
$ cd t && git ls-files -o --exclude-standard
junk
We could argue that you are overriding the ignore file by giving a
patchspec that matches or being in that directory, but it is somewhat
unexpected. Worse yet, these behave differently:
$ git ls-files -o --exclude-standard t/ .
$ git ls-files -o --exclude-standard t/
t/junk
This patch changes the optimization so that it notices when the common
prefix directory that it starts reading from is an ignored one.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you have "t" directory that is marked as ignored in the top-level
.gitignore file (or $GIT_DIR/info/exclude), running
$ git ls-files -o --exclude-standard
from the top-level correctly excludes files in "t" directory, but
any of the following:
$ git ls-files -o --exclude-standard t/
$ cd t && git ls-files -o --exclude-standard
would show untracked files in that directory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sb/maint-octopus:
octopus: remove dead code
octopus: reenable fast-forward merges
octopus: make merge process simpler to follow
Conflicts:
git-merge-octopus.sh
* mo/bin-wrappers:
INSTALL: document a simpler way to run uninstalled builds
run test suite without dashed git-commands in PATH
build dashless "bin-wrappers" directory similar to installed bindir
This makes the traversal of index be in sync with the tree traversal.
When unpack_callback() is fed a set of tree entries from trees, it
inspects the name of the entry and checks if the an index entry with
the same name could be hiding behind the current index entry, and
(1) if the name appears in the index as a leaf node, it is also
fed to the n_way_merge() callback function;
(2) if the name is a directory in the index, i.e. there are entries in
that are underneath it, then nothing is fed to the n_way_merge()
callback function;
(3) otherwise, if the name comes before the first eligible entry in the
index, the index entry is first unpacked alone.
When traverse_trees_recursive() descends into a subdirectory, the
cache_bottom pointer is moved to walk index entries within that directory.
All of these are omitted for diff-index, which does not even want to be
fed an index entry and a tree entry with D/F conflicts.
This fixes 3-way read-tree and exposes a bug in other parts of the system
in t6035, test #5. The test prepares these three trees:
O = HEAD^
100644 blob e69de29bb2 a/b-2/c/d
100644 blob e69de29bb2 a/b/c/d
100644 blob e69de29bb2 a/x
A = HEAD
100644 blob e69de29bb2 a/b-2/c/d
100644 blob e69de29bb2 a/b/c/d
100644 blob 587be6b4c3f93f93c489c0111bba5596147a26cb a/x
B = master
120000 blob a36b77384451ea1de7bd340ffca868249626bc52 a/b
100644 blob e69de29bb2 a/b-2/c/d
100644 blob e69de29bb2 a/x
With a clean index that matches HEAD, running
git read-tree -m -u --aggressive $O $A $B
now yields
120000 a36b77384451ea1de7bd340ffca868249626bc52 3 a/b
100644 e69de29bb2 0 a/b-2/c/d
100644 e69de29bb2 1 a/b/c/d
100644 e69de29bb2 2 a/b/c/d
100644 587be6b4c3f93f93c489c0111bba5596147a26cb 0 a/x
which is correct. "master" created "a/b" symlink that did not exist,
and removed "a/b/c/d" while HEAD did not do touch either path.
Before this series, read-tree did not notice the situation and resolved
addition of "a/b" and removal of "a/b/c/d" independently. If A = HEAD had
another path "a/b/c/e" added, this merge should conflict but instead it
silently resolved "a/b" and then immediately overwrote it to add
"a/b/c/e", which was quite bogus.
Tests in t1012 start to work with this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When rewriting commits on a topic branch, sometimes it is easier to
compare the version of commits before and after the rewrite if they are
based on the same commit that forked from the upstream. An earlier commit
by Junio (fixed up by the previous commit) gives "--onto A...B" syntax to
rebase command, and rebases on top of the merge base between A and B;
teach the same to the interactive version, too.
Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous patch didn't parse "rebase --onto A...B" correctly when A
isn't an empty string. It also tried to be careful to notice a case in
which there are more than one merge bases, but forgot to give --all option
to merge-base, making the test pointless.
Fix these problems and add a test script to verify. Improvements to the
script to parse A...B syntax was taken from review comments by Johannes
Schindelin.
Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add another test to set prerequisite EXTGREP if the current build supports
external grep. This can be used to skip external grep only tests on builds
that do not support this optimization.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach a new option, --autosquash, to the interactive rebase.
When the commit log message begins with "!fixup ...", and there
is a commit whose title begins with the same ..., automatically
modify the todo list of rebase -i so that the commit marked for
squashing come right after the commit to be modified, and change
the action of the moved commit from pick to squash.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We should tell ll_merge() that the 3-way merge between stages #2 and #3 is
an outermost merge, not a virtual-ancestor creation.
Back when this code was originally written, users couldn't write custom
merge drivers easily, so the bug didn't matter, but these days it does.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reuses many of the tests from the old t5560 but runs those tests
without curl or a webserver. This will hopefully increase the testing
coverage for http-backend because it does not require users to set
GIT_TEST_HTTPD.
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This should introduce no functional change in the tests or the amount
of test coverage.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 34b6cb8bb ("http-backend: Protect GIT_PROJECT_ROOT from /../
requests") added the path_info helper function to test t5560 but did
not use it. We should use it as it provides another level of error
checking.
The /etc/.../passwd case is one that is not special (and the test
fails for reasons other than being aliased), so we remove that test
case.
Also rename the function from 'path_info' to 'expect_aliased'.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Similar to how git-daemon checks whether a repository is OK to be
exported, smart-http should also check. This check can be satisfied
in two different ways: the environmental variable GIT_HTTP_EXPORT_ALL
may be set to export all repositories, or the individual repository
may have the file git-daemon-export-ok.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On CentOS 5, httpd is located at /usr/sbin/httpd, and the modules are
located at /usr/lib64/httpd/modules. To enable easy testing of httpd,
we would like those locations to be detected automatically.
uname might not be the best way to determine the default location for
httpd since different Linux distributions apparently put httpd in
different places, so we test a couple different locations for httpd,
and use the first one that we come across. We do the same for the
modules directory.
cc: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recall that MSYS bash converts POSIX style absolute paths to Windows style
absolute paths. Unfortunately, it converts a program argument that begins
with a double-quote and otherwise looks like an absolute POSIX path, but
in doing so, it strips everything past the second double-quote[*]. This
case is triggered in the two test scripts. The work-around is to place the
Windows style path returned by $(pwd) between the quotes to avoid the path
conversion.
[*] It is already bogus that a conversion is even considered when a program
argument begins with a double-quote because it cannot be an absolute POSIX
path.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently textconv helpers are run directly. Running through
the shell is useful because the user can provide a program
with command line arguments, like "antiword -f".
It also makes textconv more consistent with other parts of
git, most of which run their helpers using the shell.
The downside is that textconv helpers with shell
metacharacters (like space) in the filename will be broken.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows, we need the shbang line to correctly invoke shell scripts via
a POSIX shell, except when the script is invoked via 'sh -c' because sh (a
bash) does "the right thing". But the clean and smudge filters will not
always be invoked via 'sh -c'; to futureproof, we should mark the the one
in t0021-conversion with #!$SHELL_PATH.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the ancestor used to have a blob "P", your tree removed it, and the
tree you are merging with also removed it, the agressive three-way cleanly
merges to remove that blob. If the other tree added a new blob "P/Q"
while removing "P", it should also merge cleanly to remove "P" and create
"P/Q" (since neither the ancestor nor your tree could have had it, so it
is a typical "created in one").
The "aggressive" rule is not new anymore. Reword the stale comment.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
traverse_trees() is supposed to call its callback with all the matching
entries from the given trees. The current algorithm keeps a pointer to
each of the tree being traversed, and feeds the entry with the earliest
name to the callback.
This breaks down if the trees being traversed looks like this:
A B
t-1 t
t-2 u
t/a v
When we are currently looking at an entry "t-1" in tree A, and tree B has
returned "t", feeding "t" from the B and not feeding anything from A, only
because "t-1" sorts later than "t", will miss an entry for a subtree "t"
behind the current entry in tree A.
This introduces extended_entry_extract() helper function that gives what
name is expected from the tree, and implements a mechanism to look-ahead
in the tree object using it, to make sure such a case is handled sanely.
Traversal in tree A in the above example will first return "t" to match
that of B, and then the next request for an entry to A then returns "t-1".
This roughly corresponds to what Linus's "prepare for one-entry lookahead"
wanted to do, but because this does implement look ahead, t6035 and one more
test in t1012 reveal that the approach would not work without adjusting the
side that walks the index in unpack_trees() as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 9e8ecea (Add 'merge' mode to 'git reset', 2008-12-01) disallowed
"git reset --merge" when there was unmerged entries. But it wished if
unmerged entries were reset as if --hard (instead of --merge) has been
used. This makes sense because all "mergy" operations makes sure that
any path involved in the merge does not have local modifications before
starting, so resetting such a path away won't lose any information.
The previous commit changed the behavior of --merge to accept resetting
unmerged entries if they are reset to a different state than HEAD, but it
did not reset the changes in the work tree, leaving the conflict markers
in the resulting file in the work tree.
Fix it by doing three things:
- Update the documentation to match the wish of original "reset --merge"
better, namely, "An unmerged entry is a sign that the path didn't have
any local modification and can be safely resetted to whatever the new
HEAD records";
- Update read_index_unmerged(), which reads the index file into the cache
while dropping any higher-stage entries down to stage #0, not to copy
the object name from the higher stage entry. The code used to take the
object name from the a stage entry ("base" if you happened to have
stage #1, or "ours" if both sides added, etc.), which essentially meant
that you are getting random results depending on what the merge did.
The _only_ reason we want to keep a previously unmerged entry in the
index at stage #0 is so that we don't forget the fact that we have
corresponding file in the work tree in order to be able to remove it
when the tree we are resetting to does not have the path. In order to
differentiate such an entry from ordinary cache entry, the cache entry
added by read_index_unmerged() is marked as CE_CONFLICTED.
- Update merged_entry() and deleted_entry() so that they pay attention to
cache entries marked as CE_CONFLICTED. They are previously unmerged
entries, and the files in the work tree that correspond to them are
resetted away by oneway_merge() to the version from the tree we are
resetting to.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch makes "reset_index_file()" call "unpack_trees()" directly
instead of forking and execing "git read-tree". So the code is more
efficient.
And it's also easier to see which unpack_tree() options will be used,
as we don't need to follow "git read-tree"'s command line parsing
which is quite complex.
As Daniel Barkalow found, there is a difference between this new
version and the old one. The old version gives an error for
"git reset --merge" with unmerged entries, and the new version does
not when we reset the entries to some states that differ from HEAD.
Instead, it resets the index entry and succeeds, while leaving the
conflict markers in the corresponding file in the work tree (which
will be corrected by the next patch).
The code comes from the sequencer GSoC project:
git://repo.or.cz/git/sbeyer.git
(at commit 5a78908b70ceb5a4ea9fd4b82f07ceba1f019079)
Mentored-by: Daniel Barkalow <barkalow@iabervon.org>
Mentored-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Users might prefer to have git-difftool use a different
tool when run from a Git GUI.
This teaches git-difftool to honor 'diff.guitool' when
the '--gui' option is specified. This allows users to
configure their preferred command-line diff tool in
'diff.tool' and a GUI diff tool in 'diff.guitool'.
Reference: http://article.gmane.org/gmane.comp.version-control.git/133386
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a difftool test has an error then running the git test suite
may end up invoking a GUI diff tool. We now guard against this
by setting a difftool.bogus-tool.cmd variable.
The tests already used --tool=bogus-tool in various places so
this is simply ensuring that nothing ever falls back and
finds a real diff tool.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
branch: die explicitly why when calling "git branch [-a|-r] branchname".
fast-import: Document author/committer/tagger name is optional
SubmittingPatches: hints to know the status of a submitted patch.
The -a and -r options used to be silently ignored in such a command.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Starting from commit 8db35596, "git remote update" (with no
group name given) will fail with the following message if
remotes.default has been set in the config file:
fatal: 'default' does not appear to be a git repository
fatal: The remote end hung up unexpectedly
The problem is that the --multiple option is not passed to
"git fetch" if no remote or group name is given on the command
line. Fix the problem by always passing the --multiple
option to "git fetch" (which actually simplifies the code).
Reported-by: YONETANI Tomokazu
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
395de250 (Expand ~ and ~user in core.excludesfile, commit.template)
introduced a C function git_config_pathname, doing ~/ and ~user/
expansion. This patch makes the feature available to scripts with 'git
config --get --path'.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refspecs without a source side have been reported as confusing by many.
As an alternative, this adds support for commands like:
git push origin --delete somebranch
git push origin --delete tag sometag
Specifically, --delete will prepend a colon to all colon-less refspecs
given on the command line, and will refuse to accept refspecs with
colons to prevent undue confusion.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
textconv: stop leaking file descriptors
commit: --cleanup is a message option
git count-objects: handle packs bigger than 4G
t7102: make the test fail if one of its check fails
Documentation: always respect core.worktree if set
When a branch is marked to merge with another ref (e.g. local 'next' that
merges from and pushes back to origin's 'next', with 'branch.next.merge'
set to 'refs/heads/next'), it makes little sense to base the "branch -d"
safety, whose purpose is not to lose commits that are not merged to other
branches, on the current branch. It is much more sensible to check if it
is merged with the other branch it merges with.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.1:
textconv: stop leaking file descriptors
commit: --cleanup is a message option
git count-objects: handle packs bigger than 4G
t7102: make the test fail if one of its check fails
Conflicts:
builtin-commit.c
diff.c
Commit 9e8eceab ("Add 'merge' mode to 'git reset'", 2008-12-01),
added the --merge option to git reset, but there were no test cases
for it.
This was not a big problem because "git reset" was just forking and
execing "git read-tree", but this will change in a following patch.
So let's add a few test cases to make sure that there will be no
regression.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 952dfc6 tried to tighten the safety valves for doing
a "reset --hard" in a bare repository or outside the work
tree, but accidentally broke the case for GIT_WORK_TREE.
This patch unbreaks it.
Most git commands which need a work tree simply use
NEED_WORK_TREE in git.c to die before they get to their
cmd_* function. Reset, however, only needs a work tree in
some cases, and so must handle the work tree itself. The
error that 952dfc6 made was to simply forbid certain
operations if the work tree was not set up; instead, we need
to do the same thing that NEED_WORK_TREE does, which is to
call setup_work_tree(). We no longer have to worry about dying
in the non-worktree case, as setup_work_tree handles that
for us.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Follow the argument convention of git-pack-objects, such that a
separate option (--preogress) is used to force progress reporting
instead of -v/--verbose.
-v/--verbose now does not force progress reporting. Make git-clone.txt
say so.
This should cover all the bases in 21188b1 (Implement git clone -v),
which implemented the option to force progress reporting.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jk/1.7.0-status:
status/commit: do not suggest "reset HEAD <path>" while merging
commit/status: "git add <path>" is not necessarily how to resolve
commit/status: check $GIT_DIR/MERGE_HEAD only once
t7508-status: test all modes with color
t7508-status: status --porcelain ignores relative paths setting
status: reduce duplicated setup code
status: disable color for porcelain format
status -s: obey color.status
builtin-commit: refactor short-status code into wt-status.c
t7508-status.sh: Add tests for status -s
status -s: respect the status.relativePaths option
docs: note that status configuration affects only long format
commit: support alternate status formats
status: add --porcelain output format
status: refactor format option parsing
status: refactor short-mode printing to its own function
status: typo fix in usage
git status: not "commit --dry-run" anymore
git stat -s: short status output
git stat: the beginning of "status that is not a dry-run of commit"
Conflicts:
t/t4034-diff-words.sh
wt-status.c
* maint:
Makefile: FreeBSD (both 7 and 8) needs OLD_ICONV
Start 1.6.6.X maintenance track
Add git-http-backend to command-list.
t4019 "grep" portability fix
t1200: work around a bug in some implementations of "find"
Conflicts:
RelNotes
* jc/1.7.0-diff-whitespace-only-status:
diff.c: fix typoes in comments
Make test case number unique
diff: Rename QUIET internal option to QUICK
diff: change semantics of "ignore whitespace" options
Conflicts:
diff.h
* sr/vcs-helper:
tests: handle NO_PYTHON setting
builtin-push: don't access freed transport->url
Add Python support library for remote helpers
Basic build infrastructure for Python scripts
Allow helpers to report in "list" command that the ref is unchanged
Fix various memory leaks in transport-helper.c
Allow helper to map private ref names into normal names
Add support for "import" helper command
Allow specifying the remote helper in the url
Add a config option for remotes to specify a foreign vcs
Allow fetch to modify refs
Use a function to determine whether a remote is valid
Allow programs to not depend on remotes having urls
Fix memory leak in helper method for disconnect
Conflicts:
Documentation/git-remote-helpers.txt
Makefile
builtin-ls-remote.c
builtin-push.c
transport-helper.c
Input to "grep" is supposed to be "text", but we deliberately feed output
from "git diff --color" to sift it into two sets of lines (ones with
errors, the other without). Some implementations of "grep" only report
matches with the exit status, without showing the matched lines in their
output (e.g. OpenBSD 4.6, which says "Binary file .. matches").
Fortunately, "grep -a" is often a way to force the command to treat its
input as text.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"find path ..." command should exit with zero status only when all path
operands were traversed successfully. When a non-existent path is given,
however, some implementations of "find" (e.g. OpenBSD 4.6) exit with zero
status and break the last test in t1200.
Rewrite the test to check that there is no regular files in the objects
fan-out directories to work around this bug; it is closer to what we are
testing anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The update-index plumbing command had a hacky --unresolve implementation
that was written back in the days when merge was the only way for users to
end up with higher stages in the index, and assumed that stage #2 must
have come from HEAD, stage #3 from MERGE_HEAD and didn't bother to compute
the stage #1 information.
There were several issues with this approach:
- These days, merge is not the only command, and conflicts coming from
commands like cherry-pick, "am -3", etc. cannot be recreated by looking
at MERGE_HEAD;
- For a conflict that came from a merge that had renames, picking up the
same path from MERGE_HEAD and HEAD wouldn't help recreating it, either;
- It may have been Ok not to recreate stage #1 back when it was written,
because "diff --ours/--theirs" were the only availble ways to review
conflicts and they don't need stage #1 information. "diff --cc" that
was invented much later is a lot more useful way but it needs stage #1.
We can use resolve-undo information recorded in the index extension to
solve all of these issues.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once you resolved conflicts by "git add path", you cannot recreate the
conflicted state with "git checkout -m path", because you lost information
from higher stages in the index when you resolved them.
Since we record the necessary information in the resolve-undo index
extension these days, we can reproduce the unmerged state in the index and
check it out.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At the Porcelain level, operations such as merge that populate an
initially cleanly merged index with conflicted entries clear the
resolve-undo information upfront. Give scripted Porcelains a way
to do the same, by implementing "update-index --clear-resolve-info".
With this, a scripted Porcelain may "update-index --clear-resolve-info"
first and repeatedly run "update-index --cacheinfo" to stuff unmerged
entries to the index, to be resolved by the user with "git add" and
stuff.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make sure that resolving a failed merge with git add records
the conflicted state, committing the result keeps that state,
and checking out another commit clears the state.
"git ls-files" learns a new option --resolve-undo to show the
recorded information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git svn gc will compress the unhandled.log files that git svn mkdirs reads,
causing git svn mkdirs to skip directory creation.
[ew: trivial whitespace cleanups]
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Robert Zeh <robert.a.zeh@gmail.com>
The human-readable author and committer name can be missing from
commits imported from foreign SCM interfaces. Make sure we parse
the "author" and "committer" line a bit more leniently and avoid
segfaulting by assuming the name always exists.
Signed-off-by: David Reiss <dreiss@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old function was incorrect; in some instances it marks a cherry picked
range as a merged branch (because of an incorrect assumption that
'rev-list COMMIT --not RANGE' would work). This is replaced with a
function which should detect them correctly, memoized to limit the expense
of dealing with branches with many cherry picks to one 'merge-base' call
per merge, per branch which used cherry picking.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
SVN's list of commit ranges in mergeinfo tickets is inclusive, whereas
git commit ranges are exclusive on the left hand side. Also, the end
points of the commit ranges may not exist; they simply delineate
ranges of commits which may or may not exist. Fix these two mistakes.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
As shown, git-svn has some problems; not all svn merges are correctly
detected, and cherry picks may incorrectly be detected as real merges.
These test cases will be marked as _success once the relevant fixes are in.
Signed-off-by: Sam Vilain <sam@vilain.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
The "git svn gc" command creates and appends to unhandled.log.gz
files which should be parsed before the uncompressed
unhandled.log files.
Reported-by: Robert Zeh
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* maint:
Git 1.6.5.7
worktree: don't segfault with an absolute pathspec without a work tree
ignore unknown color configuration
help.autocorrect: do not run a command if the command given is junk
Illustrate "filter" attribute with an example
If a command is run with an absolute path as a pathspec inside a bare
repository, e.g. "rev-list HEAD -- /home", the code tried to run strlen()
on NULL, which is the result of get_git_work_tree(), and segfaulted. It
should just fail instead.
Currently the function returns NULL even inside .git/ in a repository
with a work tree, but that is a separate issue.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When parsing the config file, if there is a value that is
syntactically correct but unused, we generally ignore it.
This lets non-core porcelains store arbitrary information in
the config file, and it means that configuration files can
be shared between new and old versions of git (the old
versions might simply ignore certain configuration).
The one exception to this is color configuration; if we
encounter a color.{diff,branch,status}.$slot variable, we
die if it is not one of the recognized slots (presumably as
a safety valve for user misconfiguration). This behavior
has existed since 801235c (diff --color: use
$GIT_DIR/config, 2006-06-24), but hasn't yet caused a
problem. No porcelain has wanted to store extra colors, and
we once a color area (like color.diff) has been introduced,
we've never changed the set of color slots.
However, that changed recently with the addition of
color.diff.func. Now a user with color.diff.func in their
config can no longer freely switch between v1.6.6 and older
versions; the old versions will complain about the existence
of the variable.
This patch loosens the check to match the rest of
git-config; unknown color slots are simply ignored. This
doesn't fix this particular problem, as the older version
(without this patch) is the problem, but it at least
prevents it from happening again in the future.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit b4d1690 (Teach Git to respect skip-worktree bit (reading part))
fails to make "git commit -- a b c" respect skip-worktree
(i.e. not committing paths that are skip-worktree). This is because
when the index is reset back to HEAD, all skip-worktree information is
gone.
This patch saves skip-worktree information in the string list of
committed paths, then reuse it later on to skip skip-worktree paths.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fast-forward logic is never being triggered because $common and
$MRC are never equivalent. $common is initialized to a commit id by
merge-base and MRC is initialized to HEAD. Fix this by initializing
$MRC to the commit id for HEAD so that its possible for $MRC and
$common to be equal.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Its not very easy to understand what heads are being merged given
the current output of an octopus merge. Fix this by replacing the
sha1 with the (usually) better description in GITHEAD_<SHA1>.
Suggested-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Suggesting "'reset HEAD <path>' to unstage" is dead wrong if we are about
to record a merge commit. For either an unmerged path (i.e. with
unresolved conflicts), or an updated path, it would result in discarding
what the other branch did.
Note that we do not do anything special in a case where we are amending a
merge. The user is making an evil merge starting from an already
committed merge, and running "reset HEAD <path>" is the right way to get
rid of the local edit that has been added to the index.
Once "reset --unresolve <path>" becomes available, we might want to
suggest it for a merged path that has unresolve information, but until
then, just remove the incorrect advice.
We might also want to suggest "checkout --conflict <path>" to revert the
file in the work tree to the state of failed automerge for an unmerged
path, but we never did that, and this commit does not change that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the desired resolution is to remove the path, "git rm <path>" is the
command the user needs to use. Just like in "Changed but not updated"
section, suggest to use "git add/rm" as appropriate.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This hook runs after "git fetch" in the repository the objects are
fetched from as the user who fetched, and has security implications.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move a useful script function to decode colored output to
text form from t4034 and use it in this test as well.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 24ab81a fixed the deletion of empty files, but broke
deletion of non-empty files. The approach it took was to
factor out the "deleted" line from the patch header into its
own hunk, the same way we do for mode changes. However,
unlike mode changes, we only showed the special "delete this
file" hunk if there were no other hunks. Otherwise, the user
would annoyingly be presented with _two_ hunks: one for
deleting the file and one for deleting the content.
This meant that in the non-empty case, we forgot about the
deleted line entirely, and we submitted a bogus patch to
git-apply (with "/dev/null" as the destination file, but not
marked as a deletion).
Instead, this patch combines the file deletion hunk and the
content deletion hunk (if there is one) into a single
deletion hunk which is either staged or not.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also adds a test case for:
"git svn: Don't create empty directories whose parents were deleted"
which was the reason we found this bug in the first place.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This patch adds testcases verifying correct behaviour in several scenarios
regarding fast-import of notes:
- using a mixture of 'N' and 'M' commands
- updating existing notes
- concatenation of notes
- 'deleteall' also removes notes
- fanout schemes is added/removed when needed
- git-fast-import's branch unload/reload preserves notes
- non-notes are not clobbered in the presence of notes
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch teaches 'git fast-import' to automatically organize note objects
in a fast-import stream into an appropriate fanout structure. The notes API
in notes.h is NOT used to accomplish this, because trying to keep the
fast-import and notes data structures in sync would yield a significantly
larger patch with higher complexity.
Note objects are added with the 'N' command, and accounted for with a
per-branch counter, which is used to trigger fanout restructuring when
needed. Note that when restructuring the branch tree, _any_ entry whose
path consists of 40 hex chars (not including directory separators) will
be recognized as a note object. It is therefore not advisable to
manipulate note entries with M/D/R/C commands.
Since note objects are stored in the same tree structure as other objects,
the unloading and reloading of a fast-import branches handle note objects
transparently.
This patch has been improved by the following contributions:
- Shawn O. Pearce: Several style- and logic-related improvements
Cc: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command is like "squash", except that it discards the commit message
of the corresponding commit.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous error message was the same in many situations (unknown
revision or path not in the working tree). We try to help the user as
much as possible to understand the error, especially with the
sha1:filename notation. In this case, we say whether the sha1 or the
filename is problematic, and diagnose the confusion between
relative-to-root and relative-to-$PWD confusion precisely.
The 7 new error messages are tested.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, test-lib checks that the git_remote_helpers
directory has been built. However, if we are building
without python, we will not have done anything at all in
that directory, and test-lib's sanity check will fail.
We bump the inclusion of GIT-BUILD-OPTIONS further up in
test-lib; it contains configuration, and as such should be
read before we do any checks (and in this particular case,
we need its value to do our check properly).
Signed-off-by: Jeff King <peff@peff.net>
Looks-fine-to-me-by: Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil>
Acked-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also adjust "expected" text to reflect the file contents generated by
test_commit, which are slightly different than those generated by the
old code.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* master: (334 commits)
bash: update 'git commit' completion
Git 1.6.5.5
Fix diff -B/--dirstat miscounting of newly added contents
reset: improve worktree safety valves
Documentation: Avoid use of xmlto --stringparam
archive: clarify description of path parameter
rerere: don't segfault on failure to open rr-cache
Prepare for 1.6.5.5
gitweb: Describe (possible) gitweb.js minification in gitweb/README
Documentation: xmlto 0.0.18 does not know --stringparam
Fix crasher on encountering SHA1-like non-note in notes tree
t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
t4201: use ISO8859-1 rather than ISO-8859-1
Git 1.6.5.4
Unconditionally set man.base.url.for.relative.links
Documentation/Makefile: allow man.base.url.for.relative.link to be set from Make
Git 1.6.6-rc1
git-pull.sh: Fix call to git-merge for new command format
Prepare for 1.6.5.4
merge: do not add standard message when message is given with -m option
...
Conflicts:
Documentation/git-remote-helpers.txt
Makefile
builtin-ls-remote.c
builtin-push.c
transport-helper.c
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After specifying 'feature relative-marks' the paths specified with
'feature import-marks' and 'feature export-marks' are relative to an
internal directory in the current repository.
In git-fast-import this means that the paths are relative to the
'.git/info/fast-import' directory. However, other importers may use a
different location.
Add 'feature non-relative-marks' to disable this behavior, this way
it is possible to, for example, specify the import-marks location as
relative, and the export-marks location as non-relative.
Also add tests to verify this behavior.
Cc: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The existing code checked to make sure we were not in a bare
repository when doing a hard reset. However, we should take
this one step further, and make sure we are in a worktree.
Otherwise, we can end up munging files inside of '.git'.
Furthermore, we should do the same check for --merge resets,
which have the same properties. Actually, a merge reset of
HEAD^ would already complain, since further down in the code
we want a worktree. However, it is nicer to check up-front;
then we are sure we cover all cases ("git reset --merge"
would run, even though it wasn't doing anything) and we can
give a more specific message.
Add tests to t7103 to cover these cases and some missing ones.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --import-marks= option may be specified multiple times on the
commandline and should result in all marks being read in. Only one
import-marks feature may be specified in the stream, which is
overriden by any --import-marks= commandline options.
If one wishes to specify import-marks files in addition to the one
specified in the stream, it is easy to repeat the stream option as a
--import-marks= commandline option.
Also verify this behavior with tests.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test the quiet option and verify that the commandline options
override it.
Also make sure that an unknown option command is rejected and that
non-git options are ignored.
Lastly, show that unknown options are rejected when parsed on the
commandline.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows the fronted to require a specific feature to be supported
by the backend, or abort.
Also add support for four initial feature, date-format=, force=,
import-marks=, export-marks=.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a command line option to override rerere.autoupdate configuration
variable to make it more useful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is like --author: allow a user to specify a given date without
using the GIT_AUTHOR_DATE environment variable.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Only put bin-wrappers in the PATH (not GIT_EXEC_PATH), to emulate the
default installed user environment, and ensure all the programs run
correctly in such an environment. This is now the default, although
it can be overridden with a --with-dashes test option when running
tests.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When loading a notes tree, the code primarily looks for SHA1-like paths
whose total length (discounting directory separators) are 40 chars
(interpreted as valid note entries) or less (interpreted as subtree
entries that may in turn contain note entries when unpacked).
However, there is an additional condition that must hold for valid
subtree entries: They must be _tree_ objects (duh).
This patch adds an appropriate test for this condition, thereby fixing
the crash that occured when passing a non-tree object to the tree-walk
API.
The patch also adds another selftest verifying correct behaviour of
non-notes in note trees.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-chain-reply-to) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--nochain-reply-to'. More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some ancient platforms do not have an extensive list of alternate names for
character encodings. For example, Solaris 7 and IRIX 6.5 do not know that
ISO-8859-1 is the same as ISO8859-1. Modern platforms do know this, so use
the older name.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Prepare for 1.6.5.4
merge: do not add standard message when message is given with -m option
Do not misidentify "git merge foo HEAD" as an old-style invocation
Conflicts:
RelNotes
Even if the user explicitly gave her own message to "git merge", the
command still added its standard merge message. It resulted in a
useless repetition like this:
% git merge -m "Merge early part of side branch" `git rev-parse side~2`
% git show -s
commit 37217141e7519629353738d5e4e677a15096206f
Merge: e68e646 a1d2374
Author: しらいし ななこ <nanako3@lavabit.com>
Date: Wed Dec 2 14:33:20 2009 +0900
Merge early part of side branch
Merge commit 'a1d2374f8f52f4e8a53171601a920b538a6cec23'
The gave her own message because she didn't want git to add the
standard message (if she wanted to, she wouldn't have given one,
or she would have prepared it using git-fmt-merge-msg command).
Noticed by Nanako Shiraishi
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were added without documentation in 2009-03-16 (6720721).
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed to allow test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed to allow the test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Give a warning message when send-email uses chain-reply-to to thread the
messages because of the current default, not because the user explicitly
asked to, either from the command line or from the configuration.
This way, by the time 1.7.0 switches the default, everybody will be ready.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Inspired by the coloring of quilt.
Introduce a separate color and paint the hunk comment part, i.e. the name
of the function, in a separate color "diff.func" (defaults to plain).
Whitespace between hunk header and hunk comment is printed in plain color.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds the option to specify the envelope sender as "auto" which
would pick the 'from' address. This is good because now we can specify
the address only in one place in $HOME/.gitconfig and change it easily.
[jc: added tests]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When emit_line() is called with an empty line (but non-zero length, as we
send line terminating LF or CRLF to the function), it used to emit
<SET><RESET> followed by a newline. Stop the wastefulness.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new short status has been completely untested so far. Introduce
tests by duplicating all tests which are present for the long format.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The patch structure has def_name component that is used to validate the
sanity of a "diff --git" patch by checking pathnames that appear on the
patch header lines for consistency. The git_header_name() function is
used to compute this out of "diff --git a/... b/..." line, but the code
always stripped one level of prefix (i.e. "a/" and "b/"), without paying
attention to -p<n> option. Code in find_name() function that parses other
lines in the patch header (e.g. "--- a/..." and "+++ b/..." lines) however
did strip the correct number of leading paths prefixes, and the sanity
check between these computed values failed.
Teach git_header_name() to honor -p<n> option like find_name() function
does.
Found and reported by Steven J. Murdoch who also wrote tests.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We should avoid duplicate test numbers, since things like
GIT_SKIP_TESTS consider something like t1009.5 to be
unambiguous.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't take the author name information without re-encoding from the raw
commit object buffer.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The fourth test of show-branch in t1200 test was failing but only
sometimes. It only failed when two commits created in an earlier
test had different timestamps. When they were created within the
same second, the actual output matched the expected output.
Fix this by using test_tick to force reliable timestamps and update
the expected output so it does not to depend on the commits made in
the same sacond.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch introduces parts of a Python package called
"git_remote_helpers" containing the building blocks for
remote helpers written in Python.
No actual remote helpers are part of this patch, this patch only
includes the common basics needed to start writing such helpers.
The patch includes the necessary Makefile additions to build and
install the git_remote_helpers Python package along with the rest of
Git.
This patch is based on Johan Herland's git_remote_cvs patch and
has been improved by the following contributions:
- David Aguilar: Lots of Python coding style fixes
- David Aguilar: DESTDIR support in Makefile
Cc: David Aguilar <davvid@gmail.com>
Cc: Johan Herland <johan@herland.net>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/log-stdin:
Add trivial tests for --stdin option to log family
Make --stdin option to "log" family read also pathspecs
setup_revisions(): do not call get_pathspec() too early
Teach --stdin option to "log" family
read_revision_from_stdin(): use strbuf
Conflicts:
revision.c
* mr/gitweb-snapshot:
t/gitweb-lib: Split HTTP response with non-GNU sed
gitweb: Smarter snapshot names
gitweb: Document current snapshot rules via new tests
t/gitweb-lib.sh: Split gitweb output into headers and body
gitweb: check given hash before trying to create snapshot
Recognizing \r in a regex is something GNU sed will do, but other sed
implementation's won't (e.g. BSD sed on OS X). Instead of two sed
invocations, use a single Perl script to split output into headers
and body.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cc/replace:
Documentation: talk a little bit about GIT_NO_REPLACE_OBJECTS
Documentation: fix typos and spelling in replace documentation
replace: use a GIT_NO_REPLACE_OBJECTS env variable
One test case used 'xargs test', which assumes that 'test' is available
as external program. At least on MinGW it is not.
Moreover, 'git format-patch' was invoked in a pipeline, but not as the
last command. Rewrite the test case to catch breakage in 'git format-patch'
as well.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* bg/fetch-multi:
Re-implement 'git remote update' using 'git fetch'
builtin-fetch: add --dry-run option
builtin-fetch: add --prune option
teach warn_dangling_symref to take a FILE argument
remote: refactor some logic into get_stale_heads()
Add missing test for 'git remote update --prune'
Add the configuration option skipFetchAll
Teach the --multiple option to 'git fetch'
Teach the --all option to 'git fetch'
Since unhandled.log stores paths relative to the repository
root, we need to strip out leading path components if the
directories we're tracking are not the repository root.
Reported-by: Björn Steinbrink
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Add a new helper function, strbuf_add_indented_text(), to indent text
without a width limit, and call it from strbuf_add_wrapped_text(). It
respects both indent (applied to the first line) and indent2 (applied to
the rest of the lines); indent2 was ignored by the indent-only path of
strbuf_add_wrapped_text() before the patch.
Two simple test cases are added, one exercising strbuf_add_wrapped_text()
and the other strbuf_add_indented_text().
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While we're at it, also unset GREP_COLOR and GREP_COLORS in case colouring
is not enabled, to be on the safe side. The presence of these variables
alone is not sufficient to trigger coloured output with GNU grep, but
other implementations may behave differently.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'jh/notes' (early part):
Add selftests verifying concatenation of multiple notes for the same commit
Refactor notes code to concatenate multiple notes annotating the same object
Add selftests verifying that we can parse notes trees with various fanouts
Teach the notes lookup code to parse notes trees with various fanout schemes
Teach notes code to free its internal data structures on request
Add '%N'-format for pretty-printing commit notes
Add flags to get_commit_notes() to control the format of the note string
t3302-notes-index-expensive: Speed up create_repo()
fast-import: Add support for importing commit notes
Teach "-m <msg>" and "-F <file>" to "git notes edit"
Add an expensive test for git-notes
Speed up git notes lookup
Add a script to edit/inspect notes
Introduce commit notes
Conflicts:
.gitignore
Documentation/pretty-formats.txt
pretty.c
* sp/smart-http: (37 commits)
http-backend: Let gcc check the format of more printf-type functions.
http-backend: Fix access beyond end of string.
http-backend: Fix bad treatment of uintmax_t in Content-Length
t5551-http-fetch: Work around broken Accept header in libcurl
t5551-http-fetch: Work around some libcurl versions
http-backend: Protect GIT_PROJECT_ROOT from /../ requests
Git-aware CGI to provide dumb HTTP transport
http-backend: Test configuration options
http-backend: Use http.getanyfile to disable dumb HTTP serving
test smart http fetch and push
http tests: use /dumb/ URL prefix
set httpd port before sourcing lib-httpd
t5540-http-push: remove redundant fetches
Smart HTTP fetch: gzip requests
Smart fetch over HTTP: client side
Smart push over HTTP: client side
Discover refs via smart HTTP server when available
http-backend: more explict LocationMatch
http-backend: add example for gitweb on same URL
http-backend: use mod_alias instead of mod_rewrite
...
Conflicts:
.gitignore
remote-curl.c
* jn/editor-pager:
Provide a build time default-pager setting
Provide a build time default-editor setting
am -i, git-svn: use "git var GIT_PAGER"
add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
Teach git var about GIT_PAGER
Teach git var about GIT_EDITOR
Suppress warnings from "git var -l"
Do not use VISUAL editor on dumb terminals
Handle more shell metacharacters in editor names
* bg/format-patch-doc-update:
format-patch: Add "--no-stat" as a synonym for "-p"
format-patch documentation: Fix formatting
format-patch documentation: Remove diff options that are not useful
format-patch: Always generate a patch
* jp/fetch-cull-many-refs:
remote: fix use-after-free error detected by glibc in ref_remove_duplicates
fetch: Speed up fetch of large numbers of refs
remote: Make ref_remove_duplicates faster for large numbers of refs
When we are rebasing we know that the header lines in the
patch are good and that we don't need to pick up any headers
from the body of the patch.
This makes it possible to rebase commits whose commit message
start with "From" or "Date".
Test vectors by Jeff King.
Signed-off-by: Lukas Sandström <luksan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This has the same effect as --no-replace-objects option; git ignores the
replace refs. When --no-replace-objects option is passed to git, this
environment variable is set to "1" and exported to subprocesses in order
to propagate the same setting.
It is useful for example for scripts, as the git commands used in them can
now be aware that they must not read replace refs.
Tested-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change git-diff's whitespace-ignoring modes to generate
output only if a non-empty patch results, which git-apply
rejects.
Update the tests to look for the new behavior.
Signed-off-by: Greg Bacon <gbacon@dbresearch.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
4d23660 (describe: when failing, tell the user about options that
work, 2009-10-28) forgot to update the shortcut path where the code
detected and used a possible exact match. This means that an
unannotated tag on HEAD would be used by 'git describe'.
Guard this code path against the new circumstances, where unannotated
tags can be present in ->util even if we're not actually planning to
use them.
While there, also add some tests for --all.
Reported by 'yashi' on IRC.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The t/t9700/test.pl script uses method invocation syntax when
using the Cwd module to determine the current working directory.
This fails on cygwin, since cygwin perl specifically checks for
any arguments to the cwd() function and croak()'s with the message
"Usage: Cwd::cwd()". (In perl v5.8.8 distribution, see the file
perl-5.8.8/cygwin/cygwin.c lines 139-157)
In order to avoid the problem, we replace the method invocation
syntax with a simple function call.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sb/tutorial-test:
t1200: prepare for merging with Fast-forward bikeshedding
t1200: further modernize test script style
t1200: Make documentation and test agree
t1200: cleanup and modernize test style
This patch adds basic boilerplate support (based on corresponding Perl
sections) for enabling the building and installation Python scripts.
There are currently no Python scripts being built, and when Python
scripts are added in future patches, their building and installation
can be disabled by defining NO_PYTHON.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
Document git-svn's first-parent rule
git svn: attempt to create empty dirs on clone+rebase
git svn: add authorsfile test case for ~/.gitconfig
git svn: read global+system config for clone+init
git svn: handle SVN merges from revisions past the tip of the branch
Some test scripts run Perl scripts as if they were git-* scripts, and
thus need to use the same perl that will be put in the shebang line of
git*.perl commands. $PERL_PATH therefore needs to be used instead of
a bare "perl".
The tests can fail if another perl is found in $PATH before the one
defined in $PERL_PATH.
Example test failure caused by this: the perl defined in $PERL_PATH has
Error.pm installed, and therefore the Git.pm's Makefile.PL doesn't install
the private copy. The perl from $PATH doesn't have Error.pm installed, and
all git*.perl scripts invoked during the test will fail loading Error.pm.
Makefile patch by Jeff King <peff@peff.net>.
Signed-off-by: Philippe Bruhat (BooK) <book@cpan.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add tests for --full-name, --full-tree, --abbrev, and --name-only.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git grep" currently an error when you combine the -F and -i flags.
This isn't in line with how GNU grep handles it.
This patch allows the simultaneous use of those flags.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Brian Collins <bricollins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/maint-diff-color-words:
diff --color-words: bit of clean-up
diff --color-words -U0: fix the location of hunk headers
t4034-diff-words: add a test for word diff without context
Conflicts:
diff.c
* jc/maint-blank-at-eof:
diff -B: colour whitespace errors
diff.c: emit_add_line() takes only the rest of the line
diff.c: split emit_line() from the first char and the rest of the line
diff.c: shuffling code around
diff --whitespace: fix blank lines at end
core.whitespace: split trailing-space into blank-at-{eol,eof}
diff --color: color blank-at-eof
diff --whitespace=warn/error: fix blank-at-eof check
diff --whitespace=warn/error: obey blank-at-eof
diff.c: the builtin_diff() deals with only two-file comparison
apply --whitespace: warn blank but not necessarily empty lines at EOF
apply --whitespace=warn/error: diagnose blank at EOF
apply.c: split check_whitespace() into two
apply --whitespace=fix: detect new blank lines at eof correctly
apply --whitespace=fix: fix handling of blank lines at the eof
We parse unhandled.log files for empty_dir statements and make a
best effort attempt to recreate empty directories on fresh
clones and rebase. This should cover the majority of cases
where users work off a single branch or for projects where
branches do not differ in empty directories.
Since this cannot affect "normal" git commands like "checkout"
or "reset", so users switching between branches in a single
working directory should use the new "git svn mkdirs" command
after switching branches.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* js/maint-diff-color-words:
diff --color-words: bit of clean-up
diff --color-words -U0: fix the location of hunk headers
t4034-diff-words: add a test for word diff without context
Conflicts:
diff.c
In ref_remove_duplicates, when we encounter a duplicate and remove it
from the list we need to make sure that the prev pointer stays
pointing at the last entry and also skip over adding the just freed
entry to the string_list.
Previously fetch could crash with:
*** glibc detected *** git: corrupted double-linked list: ...
Also add a test to try and catch problems with duplicate removal in
the future.
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The commit for:
git svn: read global+system config for clone+init
Initially lacked a test case because the author was unable to
reproduce it under his test environment, this adds it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
When recording the revisions that it has merged, SVN sets the top
revision to be the latest revision in the repository, which is not
necessarily a revision on the branch that is being merged from. When
it is not on the branch, git-svn fails to add the extra parent to
represent the merge because it relies on finding the commit on the
branch that corresponds to the top of the SVN merge range.
In order to correctly handle this case, we look for the maximum
revision less than or equal to the top of the SVN merge range that is
actually on the branch being merged from.
[ew: This includes the following (squashed) commit to prevent
errors during bisect:]
Author: Toby Allsopp <toby.allsopp@navman.co.nz>
Date: Fri Nov 13 09:48:39 2009 +1300
git-svn: add (failing) test for SVN 1.5+ merge with intervening commit
This test exposes a bug in git-svn's handling of SVN 1.5+ mergeinfo
properties. The problematic case is when there is some commit on an
unrelated branch after the last commit on the merged-from branch.
When SVN records the mergeinfo property, it records the latest
revision in the whole repository, which, in the problematic case, is
not on the branch it is merging from.
To trigger the git-svn bug, we modify t9151 to include two SVN merges,
the second of which has an intervening commit. The SVN dump was
generated using SVN 1.6.6 (on Debian squeeze amd64).
Signed-off-by: Toby Allsopp <toby.allsopp@navman.co.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Provide a DEFAULT_EDITOR knob to allow setting the fallback
editor to use instead of vi (when VISUAL, EDITOR, and GIT_EDITOR
are unset). The value can be set at build time according to a
system’s policy. For example, on Debian systems, the default
editor should be the 'editor' command.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refuse to use $VISUAL and fall back to $EDITOR if TERM is unset
or set to "dumb". Traditionally, VISUAL is set to a screen
editor and EDITOR to a line-based editor, which should be more
useful in that situation.
vim, for example, is happy to assume a terminal supports ANSI
sequences even if TERM is dumb (e.g., when running from a text
editor like Acme). git already refuses to fall back to vi on a
dumb terminal if GIT_EDITOR, core.editor, VISUAL, and EDITOR are
unset, but without this patch, that check is suppressed by
VISUAL=vi.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since a0e4639 (filter-branch: fix ref rewriting with
--subdirectory-filter, 2008-08-12) git-filter-branch has done
nearest-ancestor rewriting when using a --subdirectory-filter.
However, that rewriting strategy is also a useful building block in
other tasks. For example, if you want to split out a subset of files
from your history, you would typically call
git filter-branch -- <refs> -- <files>
But this fails for all refs that do not point directly to a commit
that affects <files>, because their referenced commit will not be
rewritten and the ref remains untouched.
The code was already there for the --subdirectory-filter case, so just
introduce an option that enables it independently.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King recently reinstated -p to suppress the default diffstat
(as -p used to work before 68daa64, about 14 months ago).
However, -p is also needed in combination with certain options
(e.g. --stat or --numstat) in order to produce any patch at all.
The documentation does not mention this.
Since the purpose of format-patch is to produce a patch that
can be emailed, it does not make sense that certain combination
of options will suppress the generation of the patch itself.
Therefore:
* Update 'git format-patch' to always generate a patch.
* Since the --name-only, --name-status, and --check suppresses
the generation of the patch, disallow those options,
and remove the description of them in the documentation.
* Remove the reference to -p in the description of -U.
* Remove the descriptions of the options that are synonyms for -p
plus another option (--patch-with-raw and --patch-with-stat).
* While at it, slightly tweak the description of -p itself
to say that it generates "plain patches", so that you can
think of -p as "plain patch" as an mnemonic aid.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Implement the configuration skipFetchAll option to allow
certain remotes to be skipped when doing 'git fetch --all' and
'git remote update'. The existing skipDefaultUpdate variable
is still honored (by 'git fetch --all' and 'git remote update').
(If both are set in the configuration file with different values,
the value of the last occurrence will be used.)
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the --multiple option to specify that all arguments are either
groups or remotes. The primary reason for adding this option is
to allow us to re-implement 'git remote update' using fetch.
It would have been nice if this option was not needed, but since
the colon in a refspec is optional, it is in general not possible
to know whether a single, colon-less argument is a remote or a
refspec.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git remote' is meant for managing remotes and 'git fetch' is meant
for actually fetching data from remote repositories. Therefore, it is
not logical that you must use 'git remote update' to fetch from
more than one repository at once.
Add the --all option to 'git fetch', to tell it to attempt to fetch
from all remotes. Also, if --all is not given, the <repository>
argument is allowed to be the name of a group, to allow fetching
from all repositories in the group.
Other options except -v and -q are silently ignored.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unfortunately at least one version of libcurl has a bug causing
it to include "Accept: */*" in the same POST request where we have
already asked for "Accept: application/x-git-upload-pack-response".
This is a bug in libcurl, not Git, or our test vector. The
application has explicitly asked the server for a single content
type, but libcurl has mistakenly also told the server the client
application will accept */*, which is any content type.
Based on the libcurl change log, this "Accept: */*" header bug
may have been fixed in version 7.18.1 released March 30, 2008:
http://curl.haxx.se/changes.html#7_18_1
Rather than require users to upgrade libcurl we change the test
vector to trim this line out of the 2nd request.
Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some versions of libcurl report their output when GIT_CURL_VERBOSE
is set differently than other versions do. At least one variant
(version unknown but likely pre-7.18.1) reports the POST payload to
stderr, and omits the blank line after each HTTP request/response.
We clip these lines out of the stderr output now before doing the
compare, so we aren't surprised by this trivial difference.
Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Eons ago HPA taught git-daemon how to protect itself from /../
attacks, which Junio brought back into service in d79374c7b5
("daemon.c and path.enter_repo(): revamp path validation").
I did not carry this into git-http-backend as originally we relied
only upon PATH_TRANSLATED, and assumed the HTTP server had done
its access control checks to validate the resolved path was within
a directory permitting access from the remote client. This would
usually be sufficient to protect a server from requests for its
/etc/passwd file by http://host/smart/../etc/passwd sorts of URLs.
However in 917adc0360 Mark Lodato added GIT_PROJECT_ROOT as an
additional method of configuring the CGI. When this environment
variable is used the web server does not generate the final access
path and therefore may blindly pass through "/../etc/passwd"
in PATH_INFO under the assumption that "/../" might have special
meaning to the invoked CGI.
Instead of permitting these sorts of malformed path requests, we
now reject them back at the client, with an error message for the
server log. This matches git-daemon behavior.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Teach gitweb how to produce nicer snapshot names by only using the
short hash id. If clients make requests using a tree-ish that is not
a partial or full SHA-1 hash, then the short hash will also be appended
to whatever they asked for. If clients request snapshot of a tag
(which means that $hash ('h') parameter has 'refs/tags/' prefix),
use only tag name.
Update tests cases in t9502-gitweb-standalone-parse-output.
Gitweb uses the following format for snapshot filenames:
<sanitized project name>-<version info>.<snapshot suffix>
where <sanitized project name> is project name with '.git' or '/.git'
suffix stripped, unless '.git' is the whole project name. For
snapshot prefix it uses:
<sanitized project name>-<version info>/
as compared to <sanitized project name>/ before (without version info).
Current rules for <version info>:
* if 'h' / $hash parameter is SHA-1 or shortened SHA-1, use SHA-1
shortened to to 7 characters
* otherwise if 'h' / $hash parameter is tag name (it begins with
'refs/tags/' prefix, use tag name (with 'refs/tags/' stripped
* otherwise if 'h' / $hash parameter starts with 'refs/heads/' prefix,
strip this prefix, convert '/' into '.', and append shortened SHA-1
after '-', i.e. use <sanitized hash>-<shortened sha1>
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add t9502-gitweb-standalone-parse-output test script, which runs
gitweb as a CGI script from the commandline and checks that it
produces the correct output.
Currently this test script contains only tests of snapshot naming
(proposed name of snapshot file) and snapshot prefix (prefix of files
in the archive / snapshot). It defines and uses 'tar' snapshot
format, without compression, for easy checking of snapshot prefix.
Testing is done using check_snapshot function.
Gitweb uses the following format for snapshot filenames:
<sanitized project name>-<hash parameter><snapshot suffix>
where <sanitized project name> is project name with '.git' or '/.git'
suffix stripped, unless '.git' is the whole project name. For
snapshot prefix it uses simply:
<sanitized project name>/
Disadvantages of current snapshot rules:
* There exists convention that <basename>.<suffix> archive unpacks to
<basename>/ directory (<basename>/ is prefix of archive). Gitweb
does not respect it
* Snapshot links generated by gitweb use full SHA-1 id as a value of
'h' / $hash parameter. With current rules it leads to long file
names like e.g. repo-1005c80cc11c531d327b12195027cbbb4ff9e3cb.tgz
* For handcrafted URLs, where 'h' / $hash parameter is a symbolic
'volatile' revision name such as "HEAD" or "next" snapshot name
doesn't tell us what exact version it was created from
* Proposed filename in Content-Disposition header should not contain
any directory path information, which means that it should not
contain '/' (see RFC2183)... which means that snapshot naming is
broken for $hash being e.g. hirearchical branch name such as
'xx/test'
This would be improved in next commit.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Once upon a time, format-patch would use its default stat
plus patch format only when no diff format was given on the
command line. This meant that "format-patch -p" would
suppress the stat and show just the patch.
Commit 68daa64 changed this to keep the stat format when we
had an "implicit" patch format, like "-U5". As a side
effect, this meant that an explicit patch format was now
ignored (because cmd_format_patch didn't know the reason
that the format was set way down in diff_opt_parse).
This patch unbreaks what 68daa64 did (while still preserving
what 68daa64 was trying to do), reinstating "-p" to suppress
the default behavior. We do this by parsing "-p" ourselves
in format-patch, and noting whether it was used explicitly.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"commit -s" used to add an empty line before adding S-o-b line only when
the last line of the existing log message is not another S-o-b line, but
c1e01b0 (commit: More generous accepting of RFC-2822 footer lines.,
2009-10-28) introduced logic to omit this empty line when the message ends
with a run of "footer" lines, to cover S-o-b's friends, e.g. Acked-by.
However, the logic was overzealous and missed one corner case. A message
that consists of a single line that begins with Token + colon, it can be
mistaken as a S-o-b's friend. We do want an empty line in such a case.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A tree-wide bikeshedding to replace "fast forward" into "fast-forward" is
in 'master'. Since we want to keep this "test modernization" series
mergeable also to the maintenance track, we would need to tweak the test
to accept both old spellings and new spellings.
Sigh... This kind of headache is the primary reason we try not to allow
such a tree-wide bike-shedding, but the damage has already been done.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of using bare "cmp", use "test_cmp". Output when the test is run
with a -v option becomes easier to diagnose when something goes wrong
because on saner platforms test_cmp uses "diff -u".
There is no need to put an extra backslash to a line that ends with a '|'
(i.e. the upstream of a pipe).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were some differences between t1200 and the gitcore-tutorial. Add
missing tests for manually merging two branches, and use the same
commands in both files.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many parts of the tests in t1200 are run outside the test harness,
circumventing the usefulness of -v and spewing messages to stdout when
-v isn't used. Fix these problems by modernizing the test a bit.
An extra test_done has existed since commit 6a74642 (git-commit --amend:
two fixes., 2006-04-20) leading to the last 6 tests never being run.
Remove it and teach the resolve merge test about fast-forward merges.
Also fix the last test's incorrect find command and prune before
checking for unpacked objects so we remove the unreachable conflict-marked
blob.
Finally, we remove the TODO notes, because fetch, push, and clone have
their own tests since t1200 was introduced and we're not going to add
them here 4 years later.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test the major configuration settings which control access to
the repository:
http.getanyfile
http.uploadpack
http.receivepack
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The top level directory "/smart/" of the test Apache server is mapped
through our git-http-backend CGI, but uses the same underlying
repository space as the server's document root. This is the most
simple installation possible.
Server logs are checked to verify the client has accessed only the
smart URLs during the test. During fetch testing the headers are
also logged from libcurl to ensure we are making a reasonably sane
HTTP request, and getting back reasonably sane response headers
from the CGI.
When validating the request headers used during smart fetch we munge
away the actual Content-Length and replace it with the placeholder
"xxx". This avoids unnecessary varability in the test caused by
an unrelated change in the requested capabilities in the first want
line of the request. However, we still want to look for and verify
that Content-Length was used, because smaller payloads should be
using Content-Length and not "Transfer-Encoding: chunked".
When validating the server response headers we must discard both
Content-Length and Transfer-Encoding, as Apache2 can use either
format to return our response.
During development of this test I observed Apache returning both
forms, depending on when the processes got CPU time. If our CGI
returned the pack data quickly, Apache just buffered the whole
thing and returned a Content-Length. If our CGI took just a bit
too long to complete, Apache flushed its buffer and instead used
"Transfer-Encoding: chunked".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To clarify what part of the HTTP transprot is being tested we change
the URLs used by existing tests to include /dumb/ at the start,
indicating they use the non-Git aware code paths.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If LIB_HTTPD_PORT is not set already, lib-httpd will set it to the
default 8111.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we use -c, -C, or --amend, we are trying one of two things: using the
source as a template or modifying a commit with corrections.
When these options are used, the authorship and timestamp recorded in the
newly created commit are always taken from the original commit. This is
inconvenient when we just want to borrow the commit log message or when
our change to the code is so significant that we should take over the
authorship (with the blame for bugs we introduce, of course).
The new --reset-author option is meant to solve this need by regenerating
the timestamp and setting the committer as the new author.
Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The remote helper interface now supports the push capability,
which can be used to ask the implementation to push one or more
specs to the remote repository. For remote-curl we implement this
by calling the existing WebDAV based git-http-push executable.
Internally the helper interface uses the push_refs transport hook
so that the complexity of the refspec parsing and matching can be
reused between remote implementations. When possible however the
helper protocol uses source ref name rather than the source SHA-1,
thereby allowing the helper to access this name if it is useful.
>From Clemens Buchacher <drizzd@aon.at>:
update http tests according to remote-curl capabilities
o Pushing packed refs is now fixed.
o The transport helper fails if refs are already up-to-date. Add
a test for that.
o The transport helper will notice if refs are already
up-to-date. We therefore need to update server info in the
unpacked-refs test.
o The transport helper will purge deleted branches automatically.
o Use a variable ($ORIG_HEAD) instead of full SHA-1 name.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Daniel Barkalow <barkalow@iabervon.org>
CC: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Save HTTP headers into gitweb.headers, and the body of message into
gitweb.body in gitweb_run()
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For convenience in scripts and aliases, add the option
--ff-only to only allow fast-forwards (and up-to-date,
despite the name).
Disallow combining --ff-only and --no-ff, since they
flatly contradict each other.
Allow all other options to be combined with --ff-only
(i.e. do not add any code to handle them specially),
including the following options:
* --strategy (one or more): As long as the chosen merge
strategy results in up-to-date or fast-forward, the
command will succeed.
* --squash: I cannot imagine why anyone would want to
squash commits only if fast-forward is possible, but I
also see no reason why it should not be allowed.
* --message: The message will always be ignored, but I see
no need to explicitly disallow providing a redundant message.
Acknowledgements: I did look at Yuval Kogman's earlier
patch (107768 in gmane), mainly as shortcut to find my
way in the code, but I did not copy anything directly.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because --root can put our trash directories elsewhere,
using ".." may not always work.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
so that they can be run individually as
(cd t && ./t9150-svk-mergetickets.sh)
etc. just like all other test scripts.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit b5227d8 changed the behavior of "ls-files" with
respect to includes, but accidentally broke the "-i" option
The original behavior was:
1. if no "-i" is given, cull all results according to --exclude*
2. if "-i" is given, show the inverse of (1)
The broken behavior was:
1. if no "-i" is given:
a. for "-o", cull results according to --exclude*
b. for index files, always show all
2. if "-i" is given:
a. for "-o", shows the inverse of (1a)
b. for index files, always show all
The fixed behavior keeps the new (1b) behavior introduced
by b5227d8, but fixes the (2b) behavior to show only ignored
files, not all files.
This patch also tweaks the documentation. The original text
was somewhat obscure in the first place, but it is also now
inaccurate (the relationship between (1b) and (2b) is not
quite a "reverse").
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Colored word diff without context lines firstly printed all the hunk
headers among each other and then printed the diff.
This was due to the code relying on getting at least one context line at
the end of each hunk, where the colored words would be flushed (it is
done that way to be able to ignore rewrapped lines).
Noticed by Markus Heidelberg.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git commit -s' will insert a blank line before the Signed-off-by
line at the end of the message, unless this last line is a
Signed-off-by line itself. Common use has other trailing lines
at the ends of commit text, in the style of RFC2822 headers.
Be more generous in considering lines to be part of this footer.
If the last paragraph of the commit message reasonably resembles
RFC-2822 formatted lines, don't insert that blank line.
The new Signed-off-by line is still only suppressed when the
author's existing Signed-off-by is the last line of the message.
Signed-off-by: David Brown <davidb@quicinc.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Usually we show deletion as a big hunk deleting all of the
file's text. However, for files with no content, the diff
shows just the 'deleted file mode ...' line. This patch
cause "add -p" (and related commands) to recognize that line
and explicitly ask about deleting the file.
We only add the "stage this deletion" hunk for empty files,
since other files will already ask about the big content
deletion hunk. We could also change those files to simply
display "stage this deletion", but showing the actual
deleted content is probably what an interactive user wants.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the --dirty option, git describe works on HEAD but append s"-dirty"
iff the contents of the work tree differs from HEAD. E.g.
$ git describe --dirty
v1.6.5-15-gc274db7
$ echo >> Makefile
$ git describe --dirty
v1.6.5-15-gc274db7-dirty
The --dirty option can also be used to specify what is appended, instead
of the default string "-dirty".
$ git describe --dirty=.mod
v1.6.5-15-gc274db7.mod
Many build scripts use `git describe` to produce a version number based on
the description of HEAD (on which the work tree is based) + saying that if
the build contains uncommitted changes. This patch helps the writing of
such scripts since `git describe --dirty` does directly the intended thing.
Three possiblities were considered while discussing this new feature:
1. Describe the work tree by default and describe HEAD only if "HEAD" is
explicitly specified
Pro: does the right thing by default (both for users and for scripts)
Pro: other git commands that works on the work tree by default
Con: breaks existing scripts used by the Linux kernel and other projects
2. Use --worktree instead of --dirty
Pro: does what it says: "git describe --worktree" describes the work tree
Con: other commands do not require a --worktree option when working
on the work tree (it often is the default mode for them)
Con: unusable with an optional value: "git describe --worktree=.mod"
is quite unintuitive.
3. Use --dirty as in this patch
Pro: makes sense to specify an optional value (what the dirty mark is)
Pro: does not have any of the big cons of previous alternatives
* does not break scripts
* is not inconsistent with other git commands
This patch takes the third approach.
Signed-off-by: Jean Privat <jean@pryen.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This feature is long overdue; convert SVN's merge representation to git's
as revisions are imported. This works by converting the list of revisions
in each line of the svn:mergeinfo into git revision ranges, and then
checking the latest of each of these revision ranges for A) being new and
B) now being completely merged.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Dump generated with SVN 1.5.1 (on lenny amd64). This test
should hopefully cover all but a few intermediate versions of
the svnmerge.py script.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
SVK is a simple case to start with, as its idea of merge parents
matches git's one. When a svk:merge ticket is encountered, check each
of the listed merged revisions to see if they are in the history of
this commit; if not, then we have encountered a merge - record it.
[ew: minor formatting cleanups]
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Possibly the 'perl' in the PATH is not the one to be used for the tests;
let PERL set in the environment select it.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Dump generated with SVK 2.0.2 and SVN 1.5.1 (on lenny amd64).
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
GIT_DIFFTOOL_PROMPT doesn't have any effect if overridden with --prompt.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Copied from the submodule summary test and changed to reflect the
differences in the output of git diff --submodule.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes a regression introduce by d68dc34 (git-describe: Die early if
there are no possible descriptions, 2009-08-06).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This enables gitk to show the patch text with correct glyphs if the locale
is not UTF-8.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This mbox file must have been added by accident in e9fe804 (git-mailinfo:
Fix getting the subject from the in-body [PATCH] line, 2008-07-14).
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add three new --pretty=format escapes:
%gD long reflog descriptor (e.g. refs/stash@{0})
%gd short reflog descriptor (e.g. stash@{0})
%gs reflog message
This is achieved by passing down the reflog info, if any, inside the
pretty_print_context struct.
We use the newly refactored get_reflog_selector(), and give it some
extra functionality to extract a shortened ref. The shortening is
cached inside the commit_reflogs struct; the only allocation of it
happens in read_complete_reflog(), where it is initialised to 0. Also
add another helper get_reflog_message() for the message extraction.
Note that the --format="%h %gD: %gs" tests may not work in real
repositories, as the --pretty formatter doesn't know to leave away the
": " on the last commit in an incomplete (because git-gc removed the
old part) reflog. This equivalence is nevertheless the main goal of
this patch.
Thanks to Jeff King for reviews, the %gd testcase and documentation.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also verify that multiple references to the _same_ note blob are _not_
concatenated.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Creating repos with 10/100/1000/10000 commits and notes takes a lot of time.
However, using git-fast-import to do the job is a lot more efficient than
using plumbing commands to do the same.
This patch decreases the overall run-time of this test on my machine from
~3 to ~1 minutes.
Signed-off-by: Johan Herland <johan@herland.net>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce a 'notemodify' subcommand of the 'commit' command. This subcommand
is similar to 'filemodify', except that no mode is supplied (all notes have
mode 0644), and the path is set to the hex SHA1 of the given "comittish".
This enables fast import of note objects along with their associated commits,
since the notes can now be named using the mark references of their
corresponding commits.
The patch also includes a test case of the added functionality.
Signed-off-by: Johan Herland <johan@herland.net>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "-m" and "-F" options are already the established method
(in both git-commit and git-tag) to specify a commit/tag message
without invoking the editor. This patch teaches "git notes edit"
to respect the same options for specifying a notes message without
invoking the editor.
Multiple "-m" and/or "-F" options are concatenated as separate
paragraphs.
The patch also updates the "git notes" documentation and adds
selftests for the new functionality. Unfortunately, the added
selftests include a couple of lines with trailing whitespace
(without these the test will fail). This may cause git to warn
about "whitespace errors".
This patch has been improved by the following contributions:
- Thomas Rast: fix trailing whitespace in t3301
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-notes have the potential of being pretty expensive, so test with
a lot of commits. A lot. So to make things cheaper, you have to
opt-in explicitely, by setting the environment variable
GIT_NOTES_TIMING_TESTS.
This patch has been improved by the following contributions:
- Junio C Hamano: tests: fix "export var=val"
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The script 'git notes' allows you to edit and show commit notes, by
calling either
git notes show <commit>
or
git notes edit <commit>
This patch has been improved by the following contributions:
- Tor Arne Vestbø: fix printing of multi-line notes
- Michael J Gruber: test and handle empty notes gracefully
- Thomas Rast:
- only clean up message file when editing
- use GIT_EDITOR and core.editor over VISUAL/EDITOR
- t3301: fix confusing quoting in test for valid notes ref
- t3301: use test_must_fail instead of !
- refuse to edit notes outside refs/notes/
- Junio C Hamano: tests: fix "export var=val"
- Christian Couder: documentation: fix 'linkgit' macro in "git-notes.txt"
- Johan Herland: minor cleanup and bugfixing in git-notes.sh (v2)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Tor Arne Vestbø <tavestbo@trolltech.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When flipping commits around on topic branches, I often end up doing
this sequence:
* Run "log --oneline next..jc/frotz" to find out the first commit
on 'jc/frotz' branch not yet merged to 'next';
* Run "checkout $that_commit^" to detach HEAD to the parent of it;
* Rebuild the series on top of that commit; and
* "show-branch jc/frotz HEAD" and "diff jc/frotz HEAD" to verify.
Introduce a new syntax to "git checkout" to name the commit to switch to,
to make the first two steps easier. When the branch to switch to is
specified as A...B (you can omit either A or B but not both, and HEAD
is used instead of the omitted side), the merge base between these two
commits are computed, and if there is one unique one, we detach the HEAD
at that commit.
With this, I can say "checkout next...jc/frotz".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/maint-blank-at-eof:
diff -B: colour whitespace errors
diff.c: emit_add_line() takes only the rest of the line
diff.c: split emit_line() from the first char and the rest of the line
diff.c: shuffling code around
diff --whitespace: fix blank lines at end
core.whitespace: split trailing-space into blank-at-{eol,eof}
diff --color: color blank-at-eof
diff --whitespace=warn/error: fix blank-at-eof check
diff --whitespace=warn/error: obey blank-at-eof
diff.c: the builtin_diff() deals with only two-file comparison
apply --whitespace: warn blank but not necessarily empty lines at EOF
apply --whitespace=warn/error: diagnose blank at EOF
apply.c: split check_whitespace() into two
apply --whitespace=fix: detect new blank lines at eof correctly
apply --whitespace=fix: fix handling of blank lines at the eof
"git grep" would segfault if its -f option was used because it would
try to use an uninitialized strbuf, so initialize the strbuf.
Thanks to Johannes Sixt <j.sixt@viscovery.net> for the help with the
test cases.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some types of corruption to a pack may confuse the deflate stream
which stores an object. In Andy's reported case a 36 byte region
of the pack was overwritten, leading to what appeared to be a valid
deflate stream that was trying to produce a result larger than our
allocated output buffer could accept.
Z_BUF_ERROR is returned from inflate() if either the input buffer
needs more input bytes, or the output buffer has run out of space.
Previously we only considered the former case, as it meant we needed
to move the stream's input buffer to the next window in the pack.
We now abort the loop if inflate() returns Z_BUF_ERROR without
consuming the entire input buffer it was given, or has filled
the entire output buffer but has not yet returned Z_STREAM_END.
Either state is a clear indicator that this loop is not working
as expected, and should not continue.
This problem cannot occur with loose objects as we open the entire
loose object as a single buffer and treat Z_BUF_ERROR as an error.
Reported-by: Andy Isaacson <adi@hexapodia.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit dae556b (environment: add global variable to disable replacement)
adds a variable to enable/disable replacement, and it is enabled by
default for most commands.
So there is no way to disable it for some commands, which is annoying
when we want to get information about a commit that has been replaced.
For example:
$ git cat-file -p N
would output information about the replacement commit if commit N is
replaced.
With the "--no-replace-objects" option that this patch adds it is
possible to get information about the original commit using:
$ git --no-replace-objects cat-file -p N
While at it, let's add some documentation about this new option in the
"git replace" man page too.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tolerating empty path components in ref names means each ref does
not have a unique name. This creates difficulty for porcelains
that want to see if two branches are equal. Add a helper associating
to each ref a canonical name.
If a user asks a porcelain to create a ref "refs/heads//master",
the porcelain can run "git check-ref-format --print refs/heads//master"
and only deal with "refs/heads/master" from then on.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "git check-ref-format" command is a basic command various
porcelains rely on. Test its functionality to make sure it does
not unintentionally change.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git log --graph --oneline --decorate --all' is a useful way to get a
general overview of the repository state, similar to 'gitk --all'.
Let it indicate the position of HEAD by loading that ref too, so that
the --decorate code can see it.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In all parts of git, .gitignore and other exclude files
impact only how we treat untracked files; they should have
no effect on files listed in the index.
This behavior was originally implemented very early on in
9ff768e, but only for --exclude-from. Later, commit 63d285c
accidentally caused us to trigger the behavior for
--exclude-per-directory.
This patch totally ignores excludes for files found in the
index. This means we are reversing the original intent of
9ff768e, while at the same time fixing the accidental
behavior of 63d285c. This is a good thing, though, as the
way that 9ff768e behaved does not really make sense with the
way exclusions are used in modern git.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make "git add -p" to not skip files that are in index even if they are
excluded (by .gitignore etc.). This fixes the contradictory behavior
that "git status" and "git commit -a" listed such files as modified, but
"git add -p FILENAME" ignored them.
Signed-off-by: Pauli Virtanen <pav@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some MTAs reject Cc: lines longer than 78 chars.
Avoid this by using the same join as "To:" ",\n\t"
so each subsequent Cc entry is on a new line.
RCPT TO: should have a single entry per line.
see: http://www.ietf.org/rfc/rfc2821.txt
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With --prefix=string that does not end with a slash, the top-level entries
are written out with the specified prefix as expected, but no paths in the
directories are added.
Fix this by adding the prefix in write_archive_entry() instead of letting
get_pathspec() and read_tree_recursive() pair; they are designed to only
handle prefixes that are path components.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it easier to edit just the commit message for a commit
using 'git rebase -i' by introducing the "reword" command.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches the "pretty" machinery to expand '%+x' to a LF followed by
the expansion of '%x' if and only if '%x' expands to a non-empty string,
and to remove LFs before '%-x' if '%x' expands to an empty string. This
works for any supported expansion placeholder 'x'.
This is expected to be immediately useful to reproduce the commit log
message with "%s%+b%n"; "%s%n%b%n" adds one extra LF if the log message is
a one-liner.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When running "git show-branch" without any parameter in a repository that
has showbranch.default defined, we used to rely on the fact that our
handcrafted option parsing loop never looked at av[0].
The array of default strings had the first real command line argument in
default_arg[0], but the option parser wanted to look at the array starting
at av[1], so we assigned the address of -1th element to av to force the
loop start working from default_arg[0].
This no longer worked since 5734365 (show-branch: migrate to parse-options
API, 2009-05-21), as parse_options_start() saved the incoming &av[0] in
its ctx->out and later in parse_options_end() it did memmove to ctx->out
(with ctx->cpidx == 0), overwriting the memory before default_arg[] array.
I am not sure if this is a bug in parse_options(), or a bug in the caller,
and tonight I do not have enough concentration to figure out which. In
any case, this patch works the issue around.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes '--relative-date' so that it does not give '0
year, 12 months', for the interval 360 <= diff < 365.
Signed-off-by: Johan Sageryd <j416@1616.se>
Signed-off-by: Jeff King <peff@peff.net>
Makes things nicer in cases when you hand craft the snapshot URL but
make a typo in defining the hash variable (e.g. netx instead of next);
you will now get an error message instead of a broken tarball.
Tests for t9501 are included to demonstrate added functionality.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
parse_long_opt always matches both --opt and --no-opt for any option
"opt", and only get_value checks whether --no-opt is actually valid.
Since the options for git branch contains both "no-merged" and "merged"
there are two matches for --no-merge, but no exact match. With this
patch the negation of a NONEG option is rejected earlier, but it changes
the error message from "option `no-opt' isn't available" to "unknown
option `no-opt'".
[jk: added test]
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When <path> is not given, use the "humanish" part of the source repository
instead.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'jc/maint-1.6.0-blank-at-eof' (early part):
diff --whitespace: fix blank lines at end
core.whitespace: split trailing-space into blank-at-{eol,eof}
diff --color: color blank-at-eof
diff --whitespace=warn/error: fix blank-at-eof check
diff --whitespace=warn/error: obey blank-at-eof
diff.c: the builtin_diff() deals with only two-file comparison
apply --whitespace: warn blank but not necessarily empty lines at EOF
apply --whitespace=warn/error: diagnose blank at EOF
apply.c: split check_whitespace() into two
apply --whitespace=fix: detect new blank lines at eof correctly
apply --whitespace=fix: fix handling of blank lines at the eof
The earlier logic tried to colour any and all blank lines that were added
beyond the last blank line in the original, but this was very wrong. If
you added 96 blank lines, a non-blank line, and then 3 blank lines at the
end, only the last 3 lines should trigger the error, not the earlier 96
blank lines.
We need to also make sure that the lines are after the last non-blank line
in the postimage as well before deciding to paint them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test the effect of an earlier change by f7835a2 (preserve mtime of local
clone, 2009-09-12) to keep stale loose object files stale in the new
repository when a local clone is made by copying files in .git/
directory.
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, the call to authors-prog was not properly escaped, so any
special characters in the Subversion username, such as spaces and
semi-colons, would be interpreted by the shell rather than being passed
in as the first argument. Now all unsafe characters are escaped using
"git rev-parse --sq-quote"
[ew: switched from "\Q..\E" to "rev-parse --sq-quote"]
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cb/maint-1.6.3-grep-relative-up:
grep: accept relative paths outside current working directory
grep: fix exit status if external_grep() punts
Conflicts:
t/t7002-grep.sh
This configuration option allows systematically rewriting fetch-only URLs
to push-capable URLs when used with push. For instance:
[url "ssh://example.org/"]
pushInsteadOf = "git://example.org/"
This will allow clones of "git://example.org/path/to/repo" to subsequently
push to "ssh://example.org/path/to/repo", without manually configuring
pushurl for that remote.
Includes documentation for the new option, bash completion updates, and
test cases (both that pushInsteadOf applies to push, that it does not
apply to fetch, and that it is ignored when pushURL is already defined).
Signed-off-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/mailinfo-scissors:
mailinfo.scissors: new configuration
am/mailinfo: Disable scissors processing by default
Documentation: describe the scissors mark support of "git am"
Teach mailinfo to ignore everything before -- >8 -- mark
builtin-mailinfo.c: fix confusing internal API to mailinfo()
* tr/reset-checkout-patch:
stash: simplify defaulting to "save" and reject unknown options
Make test case number unique
tests: disable interactive hunk selection tests if perl is not available
DWIM 'git stash save -p' for 'git stash -p'
Implement 'git stash save --patch'
Implement 'git checkout --patch'
Implement 'git reset --patch'
builtin-add: refactor the meat of interactive_add()
Add a small patch-mode testing library
git-apply--interactive: Refactor patch mode code
Make 'git stash -k' a short form for 'git stash save --keep-index'
"git grep" would barf at relative paths pointing outside the current
working directory (or subdirectories thereof). Use quote_path_relative(),
which can handle such cases just fine.
[jc: added tests.]
Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the coloring logic processed the patch output one line at a time, we
couldn't easily color code the new blank lines at the end of file.
Reuse the adds_blank_at_eof() function to find where the runs of such
blank lines start, keep track of the line number in the preimage while
processing the patch output one line at a time, and paint the new blank
lines that appear after that line to implement this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "diff --check" logic used to share the same issue as the one fixed for
"git apply" earlier in this series, in that a patch that adds new blank
lines at end could appear as
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
+$
+$
+$
_$
_$
where _ stands for SP and $ shows a end-of-line. Instead of looking at
each line in the patch in the callback, simply count the blank lines from
the end in two versions, and notice the presence of new ones.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "diff --check" code used to conflate trailing-space whitespace error
class with this, but now we have a proper separate error class, we should
check it under blank-at-eof, not trailing-space.
The whitespace error is not about _having_ blank lines at end, but about
adding _new_ blank lines. To keep the message consistent with what is
given by "git apply", call whitespace_error_string() to generate it,
instead of using a hardcoded custom message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The whitespace error of adding blank lines at the end of file should
trigger if you added a non-empty line at the end, if the contents of the
line is full of whitespaces.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git apply" strips new blank lines at EOF under --whitespace=fix option,
but neigher --whitespace=warn nor --whitespace=error paid any attention to
these errors.
Introduce a new whitespace error class, blank-at-eof, to make the
whitespace error handling more consistent.
The patch adds a new "linenr" field to the struct fragment in order to
record which line the hunk started in the input file, but this is needed
solely for reporting purposes. The detection of this class of whitespace
errors cannot be done while parsing a patch like we do for all the other
classes of whitespace errors. It instead has to wait until we find where
to apply the hunk, but at that point, we do not have an access to the
original line number in the input file anymore, hence the new field.
Depending on your point of view, this may be a bugfix that makes warn and
error in line with fix. Or you could call it a new feature. The line
between them is somewhat fuzzy in this case.
Strictly speaking, triggering more errors than before is a change in
behaviour that is not backward compatible, even though the reason for the
change is because the code was not checking for an error that it should
have. People who do not want added blank lines at EOF to trigger an error
can disable the new error class.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command tries to strip blank lines at the end of the file added by a
patch. It is done by first detecting if a hunk in patch has additional
blank lines at the end of itself, and if so checking if such a hunk
applies at the end of file. This patch addresses a bug in the logic to
implement the former (the previous one addressed a bug in the latter).
If the original ends with blank lines, often the patch hunk ends like
this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
+$
+$
+$
_$
_$
where _ stands for SP and $ shows a end-of-line. This example patch adds
three trailing blank lines, but the code fails to notice it, because it
only pays attention to added blank lines at the very end of the hunk. In
this example, the three added blank lines do not appear textually at the
end in the patch, even though you can see that they are indeed added at
the end, if you rearrange the diff like this:
@@ -l,5 +m,7 @@$
_context$
_context$
-deleted$
_$
_$
+$
+$
+$
The fix is not to reset the number of (candidate) added blank lines at the
end when the loop sees a context line that is empty.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
b94f2ed (builtin-apply.c: make it more line oriented, 2008-01-26) broke
the logic used to detect if a hunk adds blank lines at the end of the
file. With the new code after that commit:
- img holds the contents of the file that the hunk is being applied to;
- preimage has the lines the hunk expects to be in img; and
- postimage has the lines the hunk wants to update the part in img that
corresponds to preimage with.
and we need to compare if the last line of preimage (not postimage)
matches the last line of img to see if the hunk applies at the end of the
file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.3:
git-clone: add missing comma in --reference documentation
git-cvsserver: no longer use deprecated 'git-subcommand' commands
clone: disconnect transport after fetching
The current code just leaves the transport in whatever state
it was in after performing the fetch. For a non-empty clone
over the git protocol, the transport code already
disconnects at the end of the fetch.
But for an empty clone, we leave the connection hanging, and
eventually close the socket when clone exits. This causes
the remote upload-pack to complain "the remote end hung up
unexpectedly". While this message is harmless to the clone
itself, it is unnecessarily scary for a user to see and may
pollute git-daemon logs.
This patch just explicitly calls disconnect after we are
done with the remote end, which sends a flush packet to
upload-pack and cleanly disconnects, avoiding the error
message.
Other transports are unaffected or slightly improved:
- for a non-empty repo over the git protocol, the second
disconnect is a no-op (since we are no longer connected)
- for "walker" transports (like HTTP or FTP), we actually
free some used memory (which previously just sat until
the clone process exits)
- for "rsync", disconnect is always a no-op anyway
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the earlier DWIM patches, certain combination of options defaulted
to the "save" command correctly while certain equally valid combination
did not. For example, "git stash -k" were Ok but "git stash -q -k" did
not work.
This makes the logic of defaulting to "save" much simpler. If there are no
non-flag arguments, it is clear that there is no command word, and we
default to "save" subcommand. This rule prevents "git stash -q apply"
from quietly creating a stash with "apply" as the message.
This also teaches "git stash save" to reject an unknown option. This is
to keep a mistyped "git stash save --quite" from creating a stash with a
message "--quite", and this safety is more important with the new logic
to default to "save" with any option-looking argument without an explicit
comand word.
[jc: this is based on Matthieu's 3-patch series, and a follow-up
discussion, and he and Peff take all the credit; if I have introduced bugs
while reworking, they are mine.]
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lt/approxidate:
fix approxidate parsing of relative months and years
tests: add date printing and parsing tests
refactor test-date interface
Add date formatting and parsing functions relative to a given time
Further 'approxidate' improvements
Improve on 'approxidate'
Conflicts:
date.c
* mr/gitweb-snapshot:
gitweb: add t9501 tests for checking HTTP status codes
gitweb: split test suite into library and tests
gitweb: improve snapshot error handling
These were broken by b5373e9. The problem is that the code
marks the month and year with "-1" for "we don't know it
yet", but the month and year code paths were not adjusted to
fill in the current time before doing their calculations
(whereas other units follow a different code path and are
fine).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Until now, there was no coverage of relative date printing
or approxidate parsing routines (mainly because we had no
way of faking the "now" time for relative date calculations,
which made consistent testing impossible).
This new script tries to exercise the basic features of
show_date and approxidate. Most of the tests are just "this
obvious thing works" to prevent future regressions, with a
few exceptions:
- We confirm the fix in 607a9e8 that relative year/month
dates in the latter half of a year round correctly.
- We confirm that the improvements in b5373e9 and 1bddb25
work.
- A few tests are marked to expect failure, which are
regressions recently introduced by the two commits
above.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This file is no longer used since 54bc13c (t8005: Nobody writes Russian in
shift_jis, 2009-06-18).
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A request to clone the repository does not give any "have" but asks for
all the refs we offer with "want". When a request does not ask to clone
the repository fully, but asks to fetch some refs into an empty
repository, it will not give any "have" but its "want" won't ask for all
the refs we offer.
If we suppose (and I would say this is a rather big if) that it makes
sense to distinguish these two cases, a hook cannot reliably do this
alone. The hook can detect lack of "have" and bunch of "want", but there
is no direct way to tell if the other end asked for all refs we offered,
or merely most of them.
Between the time we talked with the other end and the time the hook got
called, we may have acquired more refs or lost some refs in the repository
by concurrent operations. Given that we plan to introduce selective
advertisement of refs with a protocol extension, it would become even more
difficult for hooks to guess between these two cases.
This adds "kind [clone|fetch]" to hook's input, as a stable interface to
allow the hooks to tell these cases apart.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After upload-pack successfully finishes its operation, post-upload-pack
hook can be called for logging purposes.
The hook is passed various pieces of information, one per line, from its
standard input. Currently the following items can be fed to the hook, but
more types of information may be added in the future:
want SHA-1::
40-byte hexadecimal object name the client asked to include in the
resulting pack. Can occur one or more times in the input.
have SHA-1::
40-byte hexadecimal object name the client asked to exclude from
the resulting pack, claiming to have them already. Can occur zero
or more times in the input.
time float::
Number of seconds spent for creating the packfile.
size decimal::
Size of the resulting packfile in bytes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/shortstatus:
git commit --dry-run -v: show diff in color when asked
Documentation/git-commit.txt: describe --dry-run
wt-status: collect untracked files in a separate "collect" phase
Make git_status_config() file scope static to builtin-commit.c
wt-status: move wt_status_colors[] into wt_status structure
wt-status: move many global settings to wt_status structure
commit: --dry-run
status: show worktree status of conflicted paths separately
wt-status.c: rework the way changes to the index and work tree are summarized
diff-index: keep the original index intact
diff-index: report unmerged new entries
Some platforms (IRIX 6.5, Solaris 7) do not provide the 'yes' utility.
Currently, some tests, including t7610 and t9001, try to call this program.
Due to the way the tests are structured, the tests still pass even though
this program is missing. Rather than succeeding by chance, let's provide
an implementation of the simple 'yes' utility in shell for all platforms to
use.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Adds a new test file, t9501, that checks HTTP status codes and messages
from gitweb.
Currently, the only tests are for the snapshot feature.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To accommodate additions to the test cases for gitweb, the preamble
from t9500 is now in its own library so that new sets of tests for
gitweb can use the same setup without copying the code.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jh/submodule-foreach:
git clone: Add --recursive to automatically checkout (nested) submodules
t7407: Use 'rev-parse --short' rather than bash's substring expansion notation
git submodule status: Add --recursive to recurse into nested submodules
git submodule update: Introduce --recursive to update nested submodules
git submodule foreach: Add --recursive to recurse into nested submodules
git submodule foreach: test access to submodule name as '$name'
Add selftest for 'git submodule foreach'
git submodule: Cleanup usage string and add option parsing to cmd_foreach()
git submodule foreach: Provide access to submodule name, as '$name'
Conflicts:
Documentation/git-submodule.txt
git-submodule.sh
This teaches mailinfo the scissors -- >8 -- mark; the command ignores
everything before it in the message body.
For lefties among us, we also support -- 8< -- ;-)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We currently point the HEAD of a newly cloned repo to the
same ref as the parent repo's HEAD. While a user can then
"git checkout -b foo origin/foo" whichever branch they
choose, it is more convenient and more efficient to tell
clone which branch you want in the first place.
Based on a patch by Kirill A. Korinskiy.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-log: allow --decorate[=short|full]
Minor improvement to the write-tree documentation
git-bisect: call the found commit "*the* first bad commit"
Commit de435ac0 changed the behavior of --decorate from printing the
full ref (e.g., "refs/heads/master") to a shorter, more human-readable
version (e.g., just "master"). While this is nice for human readers,
external tools using the output from "git log" may prefer the full
version.
This patch introduces an extension to --decorate to allow the caller to
specify either the short or the full versions.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jp/symlink-dirs:
t6035-merge-dir-to-symlink depends on SYMLINKS prerequisite
git-checkout: be careful about untracked symlinks
lstat_cache: guard against full match of length of 'name' parameter
Demonstrate bugs when a directory is replaced with a symlink
When checkout sees that HEAD points to a non-existent ref,
it currently acts as if "-f" was given; this behavior dates
back to 5a03e7f, which enabled checkout from unborn branches
in the shell version of "git-checkout". The reasoning given
is to avoid the code path which tries to merge the tree
contents. When checkout was converted to C, this code
remained intact.
The unfortunate side effect of this strategy is that the
"force" code path will overwrite working tree and index
state that may be precious to the user. Instead of enabling
"force", this patch uses the normal "merge" codepath for an
unborn branch, but substitutes the empty tree for the "old"
commit.
This means that in the absence of an index, any files in the
working tree will be treated as untracked files, and a
checkout which would overwrite them is aborted. Similarly,
any paths in the index will be merged with an empty entry
as the base, meaning that unless the new branch's content is
identical to what's in the index, there will be a conflict
and the checkout will be aborted.
The user is then free to correct the situation or proceed
with "-f" as appropriate.
This patch also removes the "warning: you are on a branch
yet to be born" message. Its function was to warn the user
that we were enabling the "-f" option. Since we are no
longer doing that, there is no reason for the user to care
whether we are switching away from an unborn branch.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If all refs sent by the remote repo during a fetch are reachable
locally, then no further conversation is performed with the remote. This
check is skipped when the --depth argument is provided to allow the
deepening of a shallow clone which corresponding remote repo has no
changed.
However, some additional filtering was added in commit c29727d5 to
remove those refs which are equal on both sides. If the remote repo has
not changed, then the list of refs to give the remote process becomes
empty and simply attempting to deepen a shallow repo always fails.
Let's stop being smart in that case and simply send the whole list over
when that condition is met. The remote will do the right thing anyways.
Test cases for this issue are also provided.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests help make sure graph_is_interesting() is doing the right
thing.
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The way sparse checkout works, users may empty their worktree
completely, because of non-matching sparse-checkout spec, or empty
spec. I believe this is not desired. This patch makes Git refuse to
produce such worktree.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds index as a prerequisite for directory listing (with
exclude). At the moment directory listing is used by "git clean",
"git add", "git ls-files" and "git status"/"git commit" and
unpack_trees()-related commands. These commands have been
checked/modified to populate index before doing directory listing.
add_excludes_from_file() does not enable this feature, because it
is used to read .git/info/exclude and some explicit files specified
by "git ls-files".
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This part is mainly to remove CE_VALID shortcuts (and as a
consequence, ce_uptodate() shortcuts as it may be turned on by
CE_VALID) in writing code path if skip-worktree is used. Various tests
are added to avoid future breakages.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
grep: turn on --cached for files that is marked skip-worktree
ls-files: do not check for deleted file that is marked skip-worktree
update-index: ignore update request if it's skip-worktree, while still allows removing
diff*: skip worktree version
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Detail about this bit is in Documentation/git-update-index.txt.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This removes tentative "git stat" and make it take over "git status".
There are some tests that expect "git status" to exit with non-zero status
when there is something staged. Some tests expect "git status path..." to
show the status for a partial commit.
For these, replace "git status" with "git commit --dry-run". For the
ones that do not attempt a dry-run of a partial commit that check the
output from the command, check the output from "git status" as well, as
they should be identical.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git reset without argument displays a summary of the local modification,
like this:
$ git reset
Makefile: locally modified
Some people have problems with this; they look like an error message.
This patch makes its output mimic how "git checkout $another_branch"
reports the paths with local modifications. "git add --refresh --verbose"
is changed in the same way.
It also adds a header to make it clear that the output is informative,
and not an error.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
* cc/replace:
t6050: check pushing something based on a replaced commit
Documentation: add documentation for "git replace"
Add git-replace to .gitignore
builtin-replace: use "usage_msg_opt" to give better error messages
parse-options: add new function "usage_msg_opt"
builtin-replace: teach "git replace" to actually replace
Add new "git replace" command
environment: add global variable to disable replacement
mktag: call "check_sha1_signature" with the replacement sha1
replace_object: add a test case
object: call "check_sha1_signature" with the replacement sha1
sha1_file: add a "read_sha1_file_repl" function
replace_object: add mechanism to replace objects found in "refs/replace/"
refs: add a "for_each_replace_ref" function
* bc/mailsplit-cr-at-eol:
Allow mailsplit (and hence git-am) to handle mails with CRLF line-endings
builtin-mailsplit.c: remove read_line_with_nul() since it is no longer used
builtin-mailinfo,builtin-mailsplit: use strbufs
strbuf: add new function strbuf_getwholeline()
Previously, graph_is_interesting() did not behave quite the same way as
the code in get_revision(). As a result, it would sometimes think
commits were uninteresting, even though get_revision() would return
them. This resulted in incorrect lines in the graph output.
This change creates a get_commit_action() function, which
graph_is_interesting() and simplify_commit() both now use to determine
if a commit will be shown. It is identical to the old simplify_commit()
behavior, except that it never calls rewrite_parents().
This problem was reported by Santi Béjar. The following command
would exhibit the problem before, but now works correctly:
git log --graph --simplify-by-decoration --oneline v1.6.3.3
Previously git graph did not display the output for this command
correctly between f29ac4f and 66996ec, among other places.
Signed-off-by: Adam Simpkins <simpkins@facebook.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We skip t7407 because a patch series is cooking that uses is.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many projects using submodules expect all submodules to be checked out
in order to build/work correctly. A common command sequence for
developers on such projects is:
git clone url/to/project
cd project
git submodule update --init (--recursive)
This patch introduces the --recursive option to git-clone. The new
option causes git-clone to recursively clone and checkout all
submodules of the cloned project. Hence, the above command sequence
can be reduced to:
git clone --recursive url/to/project
--recursive is ignored if no checkout is done by the git-clone.
The patch also includes documentation and a selftest.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The substring expansion notation is a bashism that we have not so far
adopted. Use 'git rev-parse --short' instead, as this also handles
the case where the unique abbreviation is longer than 7 characters.
Also fix the typo; the object name for submodule #2 was copied from
submodule #1's by mistake.
Suggested-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only show
status for all the submodules in the current repo (which is what is
currently done by 'git submodule status'), but also to show status for
all submodules at all levels (i.e. recursing into nested submodules as
well).
This patch teaches the new --recursive option to the 'git submodule status'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only update
the submodules in the current repo (which is what is currently done by
'git submodule update'), but also to operate on all submodules at all
levels (i.e. recursing into nested submodules as well).
This patch teaches the new --recursive option to the 'git submodule update'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In very large and hierarchically structured projects, one may encounter
nested submodules. In these situations, it is valuable to not only operate
on all the submodules in the current repo (which is what is currently done
by 'git submodule foreach'), but also to operate on all submodules at all
levels (i.e. recursing into nested submodules as well).
This patch teaches the new --recursive option to the 'git submodule foreach'
command. The patch also includes documentation and selftests.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add verification of the behaviour of '$name' to the git submodule
foreach selftest.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The selftest verifies that:
- only checked out submodules are visited by 'git submodule foreach'
- the $path, and $sha1 variables are set correctly for each submodule
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
And then unescape them when writing to $GIT_CONFIG.
SVN has different rules for repository URLs (usually the root)
and for paths within that repository (below the HTTP layer).
Thus, for the request URI path at the HTTP level, the URI needs
to be encoded. However, in the body of the HTTP request (the
with underlying SVN XML protocol), those paths should not be
URI-encoded[1]. For non-HTTP(S) requests, SVN appears to be
more flexible and will except weird characters in the URL as
well as URI-encoded ones.
Since users are used to using URLs being entirely URI-encoded,
git svn will now attempt to unescape the path portion of URLs
while leaving the actual repository URL untouched.
This change will be reflected in newly-created $GIT_CONFIG files
only. This allows users to switch between svn(+ssh)://, file://
and http(s):// urls without changing the fetch/branches/tags
config keys. This won't affect existing imports at all (since
things didn't work before this commit anyways), and will allow
users to force escaping into repository paths that look like
they're escaped (but are not).
Thanks to Mike Smullin for the original bug report and Björn
Steinbrink for summarizing it into testable cases for me.
[1] Except when committing copies/renames, see
commit 29633bb91c
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Commit de435ac0 changed the behavior of --decorate from printing the
full ref (e.g., "refs/heads/master") to a shorter, more human-readable
version (e.g., just "master"). While this is nice for human readers,
external tools using the output from "git log" may prefer the full
version.
This patch introduces an extension to --decorate to allow the caller to
specify either the short or the full versions.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are all backed by git-add--interactive.perl under the hood.
Signed-off-by: Jeff King <peff@peff.net>
Acked-By: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merlyn noticed that Documentation/install-doc-quick.sh no longer correctly
removes old installed documents when the target directory has a leading
path that is a symlink. It turns out that "checkout-index --prefix" was
broken by recent b6986d8 (git-checkout: be careful about untracked
symlinks, 2009-07-29).
I suspect has_symlink_leading_path() could learn the third parameter
(prefix that is allowed to be symlinked directories) to allow us to retire
a similar function has_dirs_only_path().
Another avenue of fixing this I considered was to get rid of base_dir and
base_dir_len from "struct checkout", and instead make "git checkout-index"
when run with --prefix mkdir the leading path and chdir in there. It
might be the best longer term solution to this issue, as the base_dir
feature is used only by that rather obscure codepath as far as I know.
But at least this patch should fix this breakage.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reading the index into an empty file has been broken by
5a56da5806, since it causes the existing
index to always be loaded first, and dies if it's an empty file:
$ GIT_INDEX_FILE=`mktemp` git read-tree master
fatal: index file smaller than expected
It breaks for instance committing from git.el. This patch reverts to the
previous behavior of only loading the index when merging it.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
