Test the correct functionning of textconv with cat-file <sha1:blob>
and cat-file HEAD^ <file>. Test the case when no driver is specified
Signed-off-by: Clément Poulain <clement.poulain@ensimag.imag.fr>
Signed-off-by: Diane Gasselin <diane.gasselin@ensimag.imag.fr>
Signed-off-by: Axel Bonnet <axel.bonnet@ensimag.imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test the correct functionning of textconv with blame <file> and blame HEAD^ <file>.
Test the case when no driver is specified.
Signed-off-by: Axel Bonnet <axel.bonnet@ensimag.imag.fr>
Signed-off-by: Clément Poulain <clement.poulain@ensimag.imag.fr>
Signed-off-by: Diane Gasselin <diane.gasselin@ensimag.imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-send-email passes on an 8bit mail as-is even if it does not
declare a content-type. Because the user can edit email between
format-patch and send-email, such invalid mails are unfortunately not
very hard to come by.
Make git-send-email stop and ask about the encoding to use if it
encounters any such mail. Also provide a configuration setting to
permanently configure an encoding.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have the '+' modifiier which helps combine format specifiers which
may possibly be empty, e.g. '%s%+b%n'.
Introduce an analogous ' ' (space) modifier which adds a space before
non-empty items. This helps assemble "one line type" format specifiers.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default, git uses the version string as the signature for all
patches output by format-patch. Many employers (mine included)
require the use of a signature on all outgoing mails. In a
format-patch | send-email workflow there isn't an easy way to modify
the signature without breaking the pipe and manually replacing the
version string with the signature required. Instead of doing all that
work, add an option (--signature) and a config variable
(format.signature) to replace the default git version signature when
formatting patches.
This does modify the original behavior of format-patch a bit. First
off the version string is now placed in the cover letter by default.
Secondly, once the configuration variable format.signature is added
to the .config file there is no way to revert back to the default
git version signature. Instead, specifying the --no-signature option
will remove the signature from the patches entirely.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In certain situations, commit authorship can consist of an invalid
e-mail address. For example, this is the case when working with git svn
repos where the author email has had the svn repo UUID appended such as:
author@example.com <author@example.com@deadbeef-dead-beef-dead-beefdeadbeef>
Given such an address, mailinfo extracts the authorship incorrectly as
it assumes a valid domain. However, when rebasing the original
authorship should be preserved irrespective of its validity as an email
address.
Using get_author_ident_from_commit instead of mailinfo when rebasing
preserves the original authorship.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Each of the tests in t3508 begins by navigating to a sane state:
git checkout master &&
git reset --hard $commit
If a previous test left unmerged files around, they are untouched and
the checkout fails, causing later tests to fail, too. This is not a
problem in practice because no test except the final one produces
unmerged files.
But as a futureproofing measure, it is still best to avoid the problem
with 'checkout -f'. In particular, this is needed for new tests to be
added to the end of the script.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The following python 2.5 features were worked around:
* the sha module is used as a fallback when the hashlib module is
not available
* the 'any' built-in method was replaced with a 'for' loop
* a conditional expression was replaced with an 'if' statement
* the subprocess.check_call method was replaced by a call to
subprocess.Popen followed by a call to subprocess.wait with a
check of its return status
These changes allow the python infrastructure to be used with python 2.4
which is distributed with RedHat's RHEL 5, for example.
t5800 was updated to check for python >= 2.4 to reflect these changes.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The environment variable GIT_REFLOG_ACTION was used by git-commit.sh,
but when it was converted to a builtin
(f5bbc3225c, Port git commit to C,
Nov 8 2007) this was lost.
Let's use it again as it is more user friendly when reverting or
cherry-picking to see "revert" or "cherry-pick" in the reflog rather
than to just see "commit".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Acked-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
Clément Poulain