The previous text was not exactly accurate; it is OK to
change space and minus lines, but only in certain ways. This
patch attempts to cover explicitly what can be done at the
individual line level, and cautions the user that
conceptually larger changes (like modifying a line) require
some understanding of the patch format.
Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: handle lines containing only whitespace and tabs better
When a line contains nothing but whitespace with at least one tab
and the core.whitespace config option contains blank-at-eol, the
whitespace on the line is being printed twice, once unhighlighted
(unless otherwise matched by one of the other core.whitespace values),
and a second time highlighted for blank-at-eol.
Update the leading indentation check to stop checking when it reaches
the trailing whitespace.
Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-lib: extend test_decode_color to handle more color codes
Enhance the test_decode_color function to handle all common color codes,
including background colors and escapes that contain multiple codes.
This change necessitates changing <WHITE> to <BOLD>, so update t4034
as well.
This change is necessary for the next commit in order to test
background colors properly.
Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Encode.pm started updating the string to decode in-place when a second
argument is passed in version 2.40.
This causes 'decode_utf8("", Encode::FB_CROAK)' to die with a message
like:
Modification of a read-only value attempted at .../Encode.pm line 216.
Work around this by passing an empty variable instead of a constant
string.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Acked-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t4203: do not let "git shortlog" DWIM based on tty
The "shortlog" command defaults to HEAD only when its standard input is
connected to a terminal; otherwise it acts in the traditional "filter"
mode to read and summarize the "git log" output.
Two new tests added to t4203 assumed that the command always default to
HEAD, but when the standard input is closed (or connected to /dev/null),
it output empty, which is a summary of its empty input, causing the test
to break.
Change push.default's description to add hyphens between values and
descriptions to make the manpage easier to read. The html version is
readable either way.
Change status.showUntrackedFiles to make item descriptions be
sentences and to use the same asciidoc format as push.default. The
only visual change is the additions of "."
Signed-off-by: Cliff Frey <cliff@meraki.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update test script annotate-tests.sh to handle missing/extra authors
The current script used by annotate-tests.sh (used by t8001 and t8002) fails
to emit a warning if any of the expected authors never show up in the output
or if authors that show up in the output were never specified as expected.
Update the script to fail in both of these scenarios.
Helped-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Kevin Ballard <kevin@sb.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
repack: place temporary packs under .git/objects/pack/
git-pack-objects is already careful to start out its temporary packs
under .git/objects/pack/ (cf. 8b4eb6b, Do not perform cross-directory
renames when creating packs, 2008-09-22), but git-repack did not
respond in kind so the effort was lost when the filesystem boundary is
exactly at that directory.
Let git-repack pass a path under .git/objects/pack/ as the base for
its temporary packs.
This means we might need the $PACKDIR sooner (before the pack-objects
invocation), so move the mkdir up just to be safe.
Also note that the only use of *.pack is in the find invocation way
before the pack-objects call, so the temporary packs will not suddenly
show up in any wildcards because of the directory change.
Reported-by: Marat Radchenko <marat@slonopotamus.org> Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-pack: avoid redundant "pack-objects died with strange error"
Saying "pack-objects died with strange error" after "pack-objects died
of signal 13" seems kind of redundant. The latter message was
introduced when the run-command API changed to report abnormal exits
on behalf of the caller (v1.6.5-rc0~86^2~5, 2009-07-04).
Similarly, after a controlled pack-objects failure (detectable as a
normal exit with nonzero status), a "died with strange error" message
would be redundant next to the message from pack-objects itself.
So leave off the "strange error" messages.
The result should look something like this:
$ git push sf master
Counting objects: 21542, done.
Compressing objects: 100% (4179/4179), done.
fatal: Unable to create temporary file: Permission denied
error: pack-objects died of signal 13
error: failed to push some refs to 'ssh://sf.net/gitroot/project/project'
$
Or in the "controlled exit" case (contrived example):
[...]
fatal: delta size changed
error: failed to push some refs to 'ssh://example.com/foo/bar'
$
Improved-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-file: correctly find files when called in subdir
Since b541248 (merge.conflictstyle: choose between "merge" and "diff3
-m" styles, 2008-08-29), git-merge-file uses setup_directory_gently(),
thus cd'ing around to find any possible config files to use.
This broke merge-file when it is called from within a subdirectory of
a repository, and the arguments are all relative paths.
Fix by prepending the prefix, as passed down from the main git
setup code, if there is any.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
prefix_filename(): safely handle the case where pfx_len=0
Current prefix_filename() is proofed against the case where the prefix
'pfx' is NULL or a 0-length string, _except on Windows_.
Change the behaviour to work the same on both platforms, and only
check pfx_len so that callers passing a NULL prefix with a nonzero
pfx_len segfault early on both.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t4203 (mailmap): stop hardcoding commit ids and dates
A seemingly innocuous change like adding test_tick somewhere can
completely upset the final mailmap test, since it checks commit
hashes and dates. Make the test less fragile by fuzzing away the
unpredictable parts and leaving in the authors (which is what the
test is about, anyway).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --check: correct line numbers of new blank lines at EOF
The whitespace check printed the value of the wrong variable, i.e. the
beginning of the block of blank lines at the EOF (possibly absent) in the
old file.
As "git diff --check" is used by users to check their changes before
making a commit, we should point at the line number in the file after
the change.
Signed-off-by: Christoph Mallon <christoph.mallon@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some .mailmap entry is of the <email1> <email2> form,
while a subsequent one looks like "User Name <Email2>,
and the two email addresses on the right are not identical
but are "equal" when using a case-insensitive comparator.
Then, when add_mapping is processing the latter line, new_email is NULL
and we free me->email, yet do not replace it with a new strdup'd string.
Thus, when later we attempt to use the buffer behind that ->email pointer,
we reference freed memory.
The solution is to free ->email and ->name only if we're about to replace them.
[jc: squashed in the tests from Jonathan]
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Better advice on using topic branches for kernel development
Linus Torvalds wrote:
> The real problem is that maintainers often pick random - and not at
> all stable - points for their development to begin with. They just
> pick some random "this is where Linus -git tree is today", and do
> their development on top of that. THAT is the problem - they are
> unaware that there's some nasty bug in that version.
Maybe they do this because they read it in the Git user-manual.
Fix the manual to give them better guidance.
Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: update implicit "--no-index" behavior in "git diff"
Originally "--no-index" mode triggered for untracked files within the
tracked tree, but with v1.5.6-rc1~41 (Merge branch 'jc/diff-no-no-index,
2008-05-26) the command was fixed to only implicitly trigger when paths
outside the tracked tree are mentioned.
Reported-by: Yann Dirson <dirson@bertin.fr> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Point in many directions in the hope of helping the reader find what
is needed more quickly.
This commit also removes the summary attached to the SEE ALSO entry
for difftool, to avoid making the SEE ALSO list too verbose. If the
reader wants a summary of the commands referred to, she can always
look to the top of the named pages or to the table of contents on the
main git(1) page.
Suggested-by: Goswin von Brederlow <goswin-v-b@web.de> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code paths for showing commits in "git log" and "git
rev-list --graph" correctly handle embedded NULs by looking
only at the resulting strbuf's length, and never treating it
as a C string. The code path for regular rev-list, however,
used printf("%s"), which resulted in truncated output. This
patch uses fwrite instead, like the --graph code path.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule sync: Update "submodule.<name>.url" for empty directories
If a submodule directory has not been filled by "git submodule update"
yet, then "git submodule sync" must still update the super-project's
configuration for submodule.<name>.url.
This situation occurs when switching between branches with a module from
different urls and other branches without the submodule.
Signed-off-by: Andreas Köhler <andi5.py@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply: Recognize epoch timestamps with : in the timezone
Some patches have a timezone formatted like ‘-08:00’ instead of
‘-0800’ (e.g. http://lwn.net/Articles/131729/), so git apply would
fail to recognize the epoch timestamp of deleted files and would
create empty files instead. Teach it to support both formats, and add
a test case.
Signed-off-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Group entries related to parameter substitutions together and avoid
using the word "regexp" to refer to the ${parameter/pattern/string}
substitution (banned), as the pattern there is a shell glob and not
a regular expression.
Documentation: No argument of ALLOC_GROW should have side-effects
The explanatory comment before the definition of ALLOC_GROW carefully
lists arguments that will be used more than once and thus cannot have
side-effects; a lazy reader might conclude that the arguments not
listed are used only once and side effects safe.
Correct it to list all three arguments, avoiding this confusion.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Put a space between `<' and argument in pack-objects usage string
This makes it cosistent with other places (including the
git-pack-objects(1) manpage itself) and avoids possible confusion (I,
for one, mistook `<object-list' for a `<object-list>' typo at first when
preparing this series).
Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of using the regex-like bracket expression, use grouping to make
it more consistent with other similar places. The brackets now have the
same meaning as in other documentation (i.e., the argument is optional).
Signed-off-by: Štěpán Němec <stepnem@gmail.com> Mentored-and-Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
SubmittingPatches: Document some extra tags used in commit messages
Document the meanings of the tags "Reported-by:", "Acked-by:",
"Reviewed-by:" and "Tested-by:" clearly. Also mention that the user is
free to use any custom tags.
Helped-by: Jonathan Nieder <jrnieder@gmail.com> Liked-by: Sverre Rabbelier <srabbelier@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-clone: describe --mirror more verbosely
Some people in #linux-rt noticed that describing what "--mirror" option does
with "it mirrors" is way insufficient.
Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Darren 'Some People' Hart <darren@dvhart.com> Cc: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed integer overflow is not defined in C, so do not depend on it.
This fixes a problem with GCC 4.4.0 and -O3 where the optimizer would
consider "consumed_bytes > consumed_bytes + bytes" as a constant
expression, and never execute the die()-call.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are buggy implementations of S_ISxxx(m) macros on some platforms
(e.g. NetBSD). The issue is that NetBSD doesn't take care to wrap its
macro arguments in parentheses, so on Linux and sane systems we have
S_ISREG(m) defined as something like:
(((m) & S_IFMT) == S_IFREG)
But on NetBSD:
((m & _S_IFMT) == _S_IFREG)
Since a caller in builtin/diff.c called our macro as `S_IFREG | 0644'
this bug introduced a logic error on NetBSD, since the precedence of
bit-wise & is higher than | in C.
[jc: took change description from Ævar Arnfjörð Bjarmason's patch]
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
xdiff: cast arguments for ctype functions to unsigned char
The ctype functions isspace(), isalnum(), et al take an integer
argument representing an unsigned character, or -1 for EOF. On
platforms with a signed char, it is unsafe to pass a char to them
without casting it to unsigned char first.
Most of git is already shielded against this by the ctype
implementation in git-compat-util.h, but xdiff, which uses libc
ctype.h, ought to be fixed.
Noticed-by: der Mouse <mouse@Rodents-Montreal.ORG> Reported-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The buffer used to construct paths like ".git/objects/info" and
".git/objects/pack" is allocated on the heap and never freed.
So free it. While at it, factor out the relevant code into its own
function and rename the sha1_dir variable to object_directory (to
match the change in everyday usage after the renaming of
SHA1_FILE_DIRECTORY in v0.99~603^2~7, 2005).
Noticed by valgrind while setting up tests (in test-lib).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
setup: make sure git dir path is in a permanent buffer
If setup_git_env() is run before the usual repository discovery
sequence and .git is a file with the text
gitdir: <path>
(with <path> any string) then the in-core git_dir variable is set to
the result of converting <path> to an absolute path using
make_absolute_path().
Unfortunately make_absolute_path() returns its result in a static
buffer that is overwritten by later calls. Such a call could cause
later accesses to git_dir (from git_pathdup(), for example) to read
the wrong path, leaving git very confused.
It is not obvious whether any existing code in git will trigger the
problem, but in any case, it is worth a few dozen bytes to copy the
return value from make_absolute_path() for some added peace of mind.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The result of git_getpass() is used without checking for NULL, so let's
just die() instead of returning NULL.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: avoid repeated scanning while looking for funcname
For each hunk, xdl_find_func searches the preimage for a function name
until the beginning of the file. If the file does not contain any
function names, this search has complexity O(n^2) in the number of
hunks n.
Instead, inline xdl_find_func() and keep track of up to which line we
have scanned already and the contents of the last funcname line that
we have found.
Noticed and a different approach proposed by Clemens Buchacher.
This alternative solution was done by René Scharfe.
... normal test script ...
status=$?
... cleanup ...
(exit $status)
set up cleanup commands with test_when_finished. This makes the
test script a little shorter, and more importantly, it ensures errors
during cleanup are reported.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
blame,cat-file --textconv: Don't assume mode is ``S_IFREF | 0664''
We need to get the correct mode when blame reads the source from the
working tree, the index, or trees. This allows us to omit running
textconv filters on symbolic links.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru> Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
blame,cat-file: Demonstrate --textconv is wrongly running converter on symlinks
git blame --textconv is wrongly calling the textconv filter on
symlinks: symlinks are stored as blobs whose content is the target of
the link, and blame calls the textconv filter on a temporary file
filled-in with the content of this blob.
For example:
$ git blame -C -C regular-file.pdf
Error: May not be a PDF file (continuing anyway)
Error: PDF file is damaged - attempting to reconstruct xref table...
Error: Couldn't find trailer dictionary
Error: Couldn't read xref table
Warning: program returned non-zero exit code #1
fatal: unable to read files to diff
That errors come from pdftotext run on symlink.pdf being extracted to
/tmp/ with one-line plain-text content pointing to link destination.
So several failures are demonstrated here:
- git cat-file --textconv :symlink.bin # also HEAD:symlink.bin
- git blame --textconv symlink.bin
- git blame -C -C --textconv regular-file # but also looks on symlink.bin
At present they all fail with something like.
E: /tmp/j3ELEs_symlink.bin is not "binary" file
NOTE: git diff doesn't try to textconv the pathnames, it runs the
textual diff without textconv, which is the expected behavior.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru> Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
blame,cat-file: Prepare --textconv tests for correctly-failing conversion program
The textconv filter is sometimes incorrectly ran on a temporary file
whose content is the target of a symbolic link, instead of actual file
content. Prepare to test this by marking the content of the file to
convert with "bin:", and let the helper die if "bin:" is not found in
the file content.
NOTE: I've changed $@ to $1 in helper becase textconv program "should
take a single argument" (see Documentation/gitattributes.txt), so
making this more explicit makes sense and also helps to avoid
problems with feeding arguments to echo.
Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru> Reviewed-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On case insensitive filesystems, "tags" and "TAGS" target will try to
overwrite the same file. Allow MinGW to use "ETAGS" instead.
These two targets do produce real files; do not put them on .PHONY target
list.
Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch simplifies Brian's fix for the recent regression by:
* eliminating the extra loop
* eliminating use of git rev-parse for parsing flags
* making use of the for opt idiom for the retained loop
* eliminating the redundant -- case
The patch has been tested with the tests in current maint.
Signed-off-by: Jon Seymour <jon.seymour@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
repack: add -F flag to let user choose between --no-reuse-delta/object
In 479b56ba ('make "repack -f" imply "pack-objects --no-reuse-object"'),
git repack -f was changed to include recompressing all objects on the
zlib level on the assumption that if the user wants to spend that much
time already, some more time won't hurt (and recompressing is useful if
the user changed the zlib compression level).
However, "some more time" can be quite long with very big repositories,
so some users are going to appreciate being able to choose. If we are
going to give them the choice, --no-reuse-object will probably be
interesting a lot less frequently than --no-reuse-delta. Hence, this
reverts -f to the old behaviour (--no-reuse-delta) and adds a new -F
option that replaces the current -f.
Measurements taken using this patch on a current clone of git.git
indicate a 17% decrease in time being made available to users:
git repack -Adf 34.84s user 0.56s system 145% cpu 24.388 total
git repack -AdF 38.79s user 0.56s system 133% cpu 29.394 total
Signed-off-by: Jan Krüger <jk@jk.gs> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
perl: bump the required Perl version to 5.8 from 5.6.[21]
Formalize our dependency on perl 5.8, bumped from 5.6.[12]. We already
used the three-arg form of open() which was introduced in 5.6.1, but
t/t9700/test.pl explicitly depended on 5.6.2.
However git-add--interactive.pl has been failing on the 5.6 line since
it was introduced in v1.5.0-rc0~12^2~2 back in 2006 due to this open
syntax:
sub run_cmd_pipe {
my $fh = undef;
open($fh, '-|', @_) or die;
return <$fh>;
}
Which when executed dies on "Can't use an undefined value as
filehandle reference". Several of our tests also fail on 5.6 (even
more when compiled with NO_PERL_MAKEMAKER=1):
Our code is bitrotting on 5.6 with no-one interested in fixing it, and
pinning us to such an ancient release of Perl is keeping us from using
useful features introduced in the 5.8 release.
The 5.6 series is now over 10 years old, and the 5.6.2 maintenance
release almost 7. 5.8 on the other hand is more than 8 years old.
All the modern Unix-like operating systems have now upgraded to it or
a later version, and 5.8 packages are available for old IRIX, AIX
Solaris and Tru64 systems.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Acked-by: Tor Arntsen <tor@spacetec.no> Acked-by: Randal L. Schwartz <merlyn@stonehenge.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change the git make process so that everything's rebuilt if the CC is
changed. Before we wouldn't rebuilt if e.g. the CC variable was
changed from gcc to clang.
Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-send-email.perl: ensure $domain is defined before using it
valid_fqdn() may attempt to operate on an undefined value if
Net::Domain::domainname fails to determine the domain name. This causes
perl to emit unpleasant warnings.
So, add a check for whether $domain has been defined before using it.
Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
wt-status.c: don't leak directory entries when processing untracked,ignored
When iterating through the list of directory entries, searching for
untracked entries, only the entries added to the string_list were free'd.
The rest (tracked or not matching the pathspec) were leaked.
Ditto for the "ignored" loop.
Rearrange the loops so that all entries are free'd.
Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6050 (replace): fix bogus "fetch branch with replacement" test
The test was missing some "&&" at the end of some lines and it
was wrong because, as the replacement refs were not fetched,
the commits from the parallel branch should not show up. This
was found by Elijah Newren.
This is fixed by checking that after the branch from HASH6 is
fetched, the commits from the parallel branch don't show up,
and then by fetching the replacement refs and checking that
they do show up afterwards.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: Refer to git-commit-tree in git-filter-branch help
Currently, the help for git filter-branch refers users of --env-filter
to git-commit for information about environment variables affecting
commits. However, this information is not contained in the git-commit
help, but is very explicitly detailed in git-commit-tree.
Signed-off-by: Wesley J. Landaker <wjl@icecavern.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
smart-http: Don't change POST to GET when following redirect
For a long time (29508e1 "Isolate shared HTTP request functionality", Fri
Nov 18 11:02:58 2005), we've followed HTTP redirects with
CURLOPT_FOLLOWLOCATION.
However, when the remote HTTP server returns a redirect the default
libcurl action is to change a POST request into a GET request while
following the redirect, but the remote http backend does not expect
that.
Fix this by telling libcurl to always keep the request as type POST with
CURLOPT_POSTREDIR.
For users of libcurl older than 7.19.1, use CURLOPT_POST301 instead,
which only follows 301s instead of both 301s and 302s.
Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
be a little more verbose about what each option does
Signed-off-by: Daniel Knittl-Frank <knittl89+git@googlemail.com> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command 's/'\''/'\''\'\'\''/g' only triples single quotes:
$ echo "What's up?" | sed 's/'\''/'\''\'\'\''/g'
What'''s up?
This doesn't hurt as compared to a single single quote it only adds an
empty string, but it makes the script needlessly complicated and hard to
understand. The useful quoting is done by s/'\''/'\''\\'\'\''/g at the
beginning of the script and only once for all three variables.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
CodingGuidelines: spell Arithmetic Expansion with $(($var))
POSIX wants shells to support both "N" and "$N" and requires them to yield
the same answer to $((N)) and $(($N)), but we should aim for portability
in a case like this, especially when the price we pay to do so is so
small, i.e. a few extra dollars.
t1503: Fix arithmetic expansion syntax error when using dash
On systems which have dash as /bin/sh, such as Ubuntu, the final
test (master@{n} for various n) fails with a syntax error while
processing an arithmetic expansion. The syntax error is caused by
using a bare name ('N') as a variable reference in the expression.
In order to avoid the syntax error, we spell the variable reference
as '$N' rather than simply 'N'.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-helpers: build in platform independent directory
The build directory which is used by distutils depends on the platform
(e.g. build/lib on Fedora 13, build/lib.linux-i686-2.6 on Ubuntu 9.04).
But test-lib.sh expects to find the build in build/lib which can cause
t5800-remote-helpers.sh to fail early.
Override distutils' choice so that the build is always in build/lib.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/revert.c: don't dereference a NULL pointer
cherry-pick will segfault when transplanting a root commit if the --ff
option is used. This happens because the "parent" pointer is set to NULL
when the commit being cherry-picked has no parents. Later, when "parent"
is dereferenced, the cherry-pick segfaults.
Fix this by checking whether "parent" is NULL before dereferencing it and
add a test for this case of cherry-picking a root commit with --ff.
Reported-by: Zbyszek Szmek <zbyszek@in.waw.pl> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently git-stash uses `git rev-parse --no-revs -- "$@"` to set its
FLAGS variable. This is the same as `FLAGS="-- $@"`. It should use
`git rev-parse --no-revs --flags "$@"`, but that eats any "-q" or
"--quiet" argument. So move the check for quiet before rev-parse.
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recently, the 'stash show' functionality was broken for the case when a
stash-like argument was supplied. Since, commit 9bf09e, 'stash show' when
supplied a stash-like argument prints nothing and still exists with a zero
status. Unfortunately, the flaw slipped through the test suite cracks
since the output of 'stash show' was not verified to be correct.
Improve and expand on the existing tests so that this flaws is detected.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: fix processing of decorated commit hashes
The function working_head_info() fails to parse commit hashes if they
are decorated (i.e. log.decorate is true), causing dcommit, rebase, and
other vital git-svn commands to malfunction.
This patch disables decorated log output with --no-decorate.
[ew: wrapped long line]
Signed-off-by: Mathias Lafeldt <misfire@debugon.org> Acked-by: Eric Wong <normalperson@yhbt.net>
git-svn: check_cherry_pick should exclude commits already in our history
The merge-base between @$parents and $merge_tip may have been reached
through a merge commit. This means that some commits that are ancestors
of @$parents will not be ancestors of $merge_base. The mergeinfo
property will not list commits that are ancestors of @$parents, so we
need to explicitly exclude them.
[ew: squashed and cleaned up test case from Steven]
Signed-off-by: Steven Walter <stevenrwalter@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net>
diff: don't use pathname-based diff drivers for symlinks
When we're diffing symlinks, we consider the contents to be
the pathname that the symlink points to. When a user sets up
a userdiff driver like "*.pdf diff=pdf", their "diff.pdf.*"
config generally tells us what to do with the content of
pdf files.
With the current code, we will actually process a symlink
like "link.pdf" using a configured pdf driver, meaning we
are using contents which consist of a pathname with
configuration that is expecting contents that consist of an
actual pdf file.
The most noticeable example of this would have been
textconv; however, it was already protected in its own
textconv-specific code path. We can still see the breakage
with something like "diff.*.binary", though. You could
also see it with diff.*.funcname, though it is a bit harder
to trigger accidentally there.
This patch adds a check for S_ISREG lower in the callstack
than the textconv-specific check, which should block use of
any userdiff config for non-regular files. We can drop the
check in the textconv code, which is now redundant.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-reset.txt: make modes description more consistent
Currently, the structure of the individual mode entries is different
which makes it difficult to grasp the differences between the modes.
Also, the same items are named differently (e.g. <commit>, "the named
commit", "the given commit", "the commit being switched to").
Structure and word all mode entries consistently.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it clearer that git reset --soft actually does something (changing
HEAD). While it is mentioned in the previous paragraph already it can
be easily overlooked otherwise.
Also, git reset --soft does not look at the index nor the worktree, so
there is no "good order" requirement.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-reset.txt: reset does not change files in target
git-reset obviously cannot change files in an existing commit. Make it
not sound as if it could: reset can change HEAD and, in that sense, can
change which state a file in HEAD is in.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"Change the branch" can be misunderstood to mean "change which branch is
checked out". Make it clearer that git-reset changes the branch head of
the currently checked out branch.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>