* pb/prepare-commit-msg:
git-commit: add a prepare-commit-msg hook
git-commit: Refactor creation of log message.
git-commit: set GIT_EDITOR=: if editor will not be launched
git-commit: support variable number of hook arguments
* maint:
commit: discard index after setting up partial commit
filter-branch: handle filenames that need quoting
diff: Fix miscounting of --check output
hg-to-git: fix parent analysis
mailinfo: feed only one line to handle_filter() for QP input
diff.c: add "const" qualifier to "char *cmd" member of "struct ll_diff_driver"
Add "const" qualifier to "char *excludes_file".
Add "const" qualifier to "char *editor_program".
Add "const" qualifier to "char *pager_program".
config: add 'git_config_string' to refactor string config variables.
diff.c: remove useless check for value != NULL
fast-import: check return value from unpack_entry()
Validate nicknames of remote branches to prohibit confusing ones
diff.c: replace a 'strdup' with 'xstrdup'.
diff.c: fixup garding of config parser from value=NULL
There may still be some entries from the original index that
should be discarded before we show the status. In
particular, if a file was added in the index but not
included in the partial commit, it would still show up in
the status listing as staged for commit.
Ultimately the correct fix is to keep the two states in
separate index_state variables. Then we can avoid having
to reload the cache from the temporary file altogether, and
just point wt_status_print at the correct index.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command used a very old fashioned construct to extract
filenames out of diff-index and ended up corrupting the output.
We can simply use --name-only and pipe into --stdin mode of
update-index. It's been like that for the past 2 years or so
since a94d994 (update-index: work with c-quoted name).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
c1795bb (Unify whitespace checking) incorrectly made the
checking function return without incrementing the line numbers
when there is no whitespace problem is found on a '+' line.
This resurrects the earlier behaviour.
Noticed and reported by Jay Soffian. The test script was stolen
from Jay's independent fix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function is intended to be fed one logical line at a time to
inspect, but a QP encoded raw input line can have more than one
lines, just like BASE64 encoded one.
Quoting LF as =0A may be unusual but RFC2045 allows it.
The issue was noticed and fixed by Jay Soffian. JC added a test
to protect the fix from regressing later.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
config: add test cases for empty value and no value config variables.
cvsimport: have default merge regex also match beginning of commit message
git clone -s documentation: force a new paragraph for the NOTE
status: suggest "git rm --cached" to unstage for initial commit
Protect get_author_ident_from_commit() from filenames in work tree
upload-pack: Initialize the exec-path.
bisect: use verbatim commit subject in the bisect log
git-cvsimport.txt: fix '-M' description.
Revert "pack-objects: only throw away data during memory pressure"
The tests in 't1300-repo-config.sh' did not check what happens when
an empty value like the following is used in the config file:
[emptyvalue]
variable =
Also it was not checked that a variable with no value like the
following:
[novalue]
variable
gives a boolean "true" value, while an ampty value gives a boolean
"false" value.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It makes no sense to suggest "git reset HEAD" since we have
no HEAD commit. This actually used to work but regressed in
f26a0012.
wt_status_print_cached_header was updated to take the whole
wt_status struct rather than just the reference field.
Previously the various code paths were sometimes sending in
s->reference and sometimes sending in NULL, making the
decision on whether this was an initial commit before we
even got to this function. Now we must check the initial
flag here.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to use "cat-file commit $commit" to extract the original
author information from existing commit, but an earlier commit
5ac2715 (Consistent message encoding while reusing log from an
existing commit) changed it to use "git show -s $commit". If
you have a file in your work tree that can be interpreted as a
valid object name (e.g. "HEAD"), this conversion will not work.
Disambiguate by marking the end of revision parameter on the
comand line with an explicit "--" to fix this.
This breakage is most visible with rebase when a file called
"HEAD" exists in the worktree.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When using the '-w $cvsdir' option to cvsexportcommit, it will chdir into
$cvsdir before executing several other git commands. If $GIT_DIR is set to
a relative path (e.g. '.'), the git commands executed by cvsexportcommit
will naturally fail.
Therefore, ensure that $GIT_DIR is absolute before the chdir to $cvsdir.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The testcase verifies that 'git cvsexportcommit' functions correctly when
the '-w' option is used, and GIT_DIR is set to a relative path (e.g. '.').
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lt/in-core-index:
lazy index hashing
Create pathname-based hash-table lookup into index
read-cache.c: introduce is_racy_timestamp() helper
read-cache.c: fix a couple more CE_REMOVE conversion
Also use unpack_trees() in do_diff_cache()
Make run_diff_index() use unpack_trees(), not read_tree()
Avoid running lstat(2) on the same cache entry.
index: be careful when handling long names
Make on-disk index representation separate from in-core one
This establishes what the "bad" whitespaces are for this
project.
The rules are:
- Unless otherwise specified, indent with SP that could be
replaced with HT are not "bad". But SP before HT in the
indent is "bad", and trailing whitespaces are "bad".
- For C source files, initial indent by SP that can be replaced
with HT is also "bad".
- Test scripts in t/ and test vectors in its subdirectories can
contain anything, so we make it unrestricted for now.
Anything "bad" will be shown in WHITESPACE error indicator in
diff output, and "apply --whitespace=warn" will warn about it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Write errors when repacking (eg, due to out-of-space conditions)
can leave temporary packs (and possibly other files beginning
with "tmp_") lying around which no existing
codepath removes and which aren't obvious to the casual user.
These can also be multi-megabyte files wasting noticeable space.
Unfortunately there's no way to definitely tell in builtin-prune
that a tmp_ file is not being used by a concurrent process,
such as a fetch. However, it is documented that pruning should
only be done on a quiet repository and --expire is honoured
(using code from Johannes Schindelin, along with a test case
he wrote) so that its safety is the same as that of loose
object pruning.
Since they might be signs of a problem (unlike orphaned loose
objects) the names of any removed files are printed.
Signed-off-by: David Tweed (david.tweed@gmail.com)
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of insisting on a symbolic ref, bisect now accepts detached
HEADs, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
find_beginning_of_line didn't take into account that the
previous line might have ended with \ in which case it shouldn't
stop but continue its search.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git pack-objects" has the option --max-pack-size to limit the file
size of the packs to a certain amount of bytes. On platforms where
the pack file size is limited by filesystem constraints, it is easy
to forget this option, and this option does not exist for "git gc"
to begin with.
So introduce a config variable to set the default maximum, but make
this overrideable by the command line.
Suggested by Tor Arvid Lund.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There was an embarrassing pair of off-by-one miscounting that
failed to match path "a/b/c" when "a/.gitattributes" tried to
name it with relative path "b/c".
This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tests in 't1300-repo-config.sh' did not check what happens when
an empty value like the following is used in the config file:
[emptyvalue]
variable =
Also it was not checked that a variable with no value like the
following:
[novalue]
variable
gives a boolean "true" value, while an ampty value gives a boolean
"false" value.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, we set the GIT_CONFIG environment variable in
our tests so that only that file was read. However, setting
it to a static value is not correct, since we are not
necessarily always in the same directory; instead, we want
the usual git config file lookup to happen.
To do this, we stop setting GIT_CONFIG, which means that we
must now suppress the reading of the system-wide and user
configs.
This exposes an incorrect test in t1500, which is also
fixed (the incorrect test worked because we were failing to
read the core.bare value from the config file, since the
GIT_CONFIG variable was pointing us to the wrong file).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Numeric color only worked if it was at end of line.
Noticed by Chris Larson <clarson@kergoth.com>.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The prepare-commit-msg hook is run whenever a "fresh" commit message
is prepared, just before it is shown in the editor (if it is).
Its purpose is to modify the commit message in-place.
It takes one to three parameters. The first is the name of the file that
the commit log message. The second is the source of the commit message,
and can be: "message" (if a -m or -F option was given); "template" (if a
-t option was given or the configuration option commit.template is set);
"merge" (if the commit is a merge or a .git/MERGE_MSG file exists);
"squash" (if a .git/SQUASH_MSG file exists); or "commit", followed by
a commit SHA1 as the third parameter (if a -c, -C or --amend option
was given).
If its exit status is non-zero, git-commit will abort. The hook is
not suppressed by the --no-verify option, so it should not be used
as a replacement for the pre-commit hook.
The sample prepare-commit-msg comments out the `Conflicts:` part of
a merge's commit message; other examples are commented out, including
adding a Signed-off-by line at the bottom of the commit messsage,
that the user can then edit or discard altogether.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch moves the code of run_commit, up to writing the trees, editing
the message and running the commit-msg hook to prepare_log_message. It also
renames the latter to prepare_to_commit.
This simplifies a little the code for the next patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The scripted version might not have handled this correctly
either, but the version rewritten in C definitely does not grok
this and complains $tag is not a commit object.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is the absolute minimum (and reliable) reproduction recipe
to demonstrate that revision range in a history with clock skew
sometimes fails to mark UNINTERESTING commit in topologically
early parts of the history.
The history looks like this:
o---o---o---o
one four
but one has the largest timestamp. "git rev-list four..one"
fails to notice that "one" should not be emitted.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we have known breakages, we still said "passed all N
test(s)", which was a bit funny.
This rewords it to read "passed all remaining N test(s)" in such
a case.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally, test_expect_failure was designed to be the opposite
of test_expect_success, but this was a bad decision. Most tests
run a series of commands that leads to the single command that
needs to be tested, like this:
test_expect_{success,failure} 'test title' '
setup1 &&
setup2 &&
setup3 &&
what is to be tested
'
And expecting a failure exit from the whole sequence misses the
point of writing tests. Your setup$N that are supposed to
succeed may have failed without even reaching what you are
trying to test. The only valid use of test_expect_failure is to
check a trivial single command that is expected to fail, which
is a minority in tests of Porcelain-ish commands.
This large-ish patch rewrites all uses of test_expect_failure to
use test_expect_success and rewrites the condition of what is
tested, like this:
test_expect_success 'test title' '
setup1 &&
setup2 &&
setup3 &&
! this command should fail
'
test_expect_failure is redefined to serve as a reminder that
that test *should* succeed but due to a known breakage in git it
currently does not pass. So if git-foo command should create a
file 'bar' but you discovered a bug that it doesn't, you can
write a test like this:
test_expect_failure 'git-foo should create bar' '
rm -f bar &&
git foo &&
test -f bar
'
This construct acts similar to test_expect_success, but instead
of reporting "ok/FAIL" like test_expect_success does, the
outcome is reported as "FIXED/still broken".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We only care about getting what should be an empty string and
sending it to a file, without a trailing LF, so the empty string
translates into a 0 byte file. Earlier when I originally wrote
these lines Mac OS X allowed the format string of printf to be
the empty string, but more recent versions appear to have been
'improved' with error messages if the format is not given.
This may cause problems if we ever wind up with changes to the hook
tests. A minor cleanup makes the test more safe on all systems,
by conforming to accepted printf conventions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This accompanies c5b09feb78 (Avoid
update hook during git-rebase --interactive) to make sure that
any regression to make Debian's Bug#458782 (git-core: git-rebase
doesn't work when trying to squash changes into commits created
with --no-verify) resurface will be caught.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The exit value of some commands was not being used for the
test output.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the upstream branch is tracked, we can detect if that branch
was rebased since it was last fetched. Teach git to use that
information to rebase from the old remote head onto the new remote head.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git histories may have multiple roots, which can cause
git merge-base to fail and this caused git cvsserver to die.
This commit teaches git cvsserver to handle a failing git
merge-base gracefully, and modifies the test case to verify this.
All the test cases now use a history with two roots.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
git-cvsserver.perl | 9 ++++++++-
t/t9400-git-cvsserver-server.sh | 10 +++++++++-
2 files changed, 17 insertions(+), 2 deletions(-)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is preferable to have the test setup in a test case. The
setup itself may fail and having it as a test case handles this
situation more gracefully.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If options are aggregated, and that the whole token is an exact
prefix of a long option that is longer than 2 letters, reject
it. This is to prevent a common typo:
$ git commit -amend
to get interpreted as "commit all with message 'end'".
The typo check isn't performed if there is no aggregation,
because the stuck form is the recommended one. If we have `-o`
being a valid short option that takes an argument, and --option
a long one, then we _MUST_ accept -option as "'o' option with
argument 'ption'", which is our official recommended form.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test 'creating too deep nesting' can fail even when cloning the repos,
but is not its main purpose (it has to prepare nested repos and ensure
the last one is invalid). So split the test into the creation and
invalidity checking parts.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We currently use lower 12-bit (masked with CE_NAMEMASK) in the
ce_flags field to store the length of the name in cache_entry,
without checking the length parameter given to
create_ce_flags(). This can make us store incorrect length.
Currently we are mostly protected by the fact that many
codepaths first copy the path in a variable of size PATH_MAX,
which typically is 4096 that happens to match the limit, but
that feels like a bug waiting to happen. Besides, that would
not allow us to shorten the width of CE_NAMEMASK to use the bits
for new flags.
This redefines the meaning of the name length stored in the
cache_entry. A name that does not fit is represented by storing
CE_NAMEMASK in the field, and the actual length needs to be
computed by actually counting the bytes in the name[] field.
This way, only the unusually long paths need to suffer.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This modifies the existing t7400 test to use 'init' as the
pathname that a submodule is bound to. Without the earlier
subcommand parser fix, this fails.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since we are now sanity-checking the contents of patches and
refusing to send ones with long lines, this knob provides a
way for the user to override the new behavior (if, e.g., he
knows his SMTP path will handle it).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We try to catch errors early so that we don't end up sending
half of a broken patch series. Right now the only validation
is checking that line-lengths are under the SMTP-mandated
limit of 998.
The validation parsing is very crude (it just checks each
line length without understanding the mailbox format) but
should work fine for this simple check.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes write_ref_sha1() more careful: it actually checks the SHA1 of
the ref it is updating, and refuses to update a ref with an object that it
cannot find.
Perhaps more importantly, it also refuses to update a branch head with a
non-commit object. I don't quite know *how* the stable series maintainers
were able to corrupt their repository to have a HEAD that pointed to a tag
rather than a commit object, but they did. Which results in a totally
broken repository that cannot be cloned or committed on.
So make it harder for people to shoot themselves in the foot like that.
The test t1400-update-ref.sh is fixed at the same time, as it
assumed that the commands involved in the particular test would
not care about corrupted repositories whose refs point at
nonexistant bogus objects. That assumption does not hold true
anymore.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We truncate hunk-header line at 80 bytes, but that 80th byte
could be in the middle of a character, which is bad. This uses
pick_one_utf8_char() function to make sure we do not cut a character
in the middle.
This assumes that the internal representation of the text is
UTF-8. This needs to be extended in the future but the optimal
direction has not been decided yet.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
