git-commit: fix double close(2) that can close a wrong file descriptor
The codepath to prepare index files for the temporary and next
index file was closing file descriptor it obtained from the
lockfile API by hand, without letting the API know that the fd
should not be doubly closed.
This is not usually a problem (except it may get EBADFD) but if
we opened another fd for an entirely unrelated purpose (say, an
fd used to mmap a packfile) between the time we close the fd to
the index file and the time we commit or rollback the lockfile
(causing it to also try closing the recorded fd), the lockfile
API will close an incorrect file descriptor that is still used
for an entirely unrelated purpose.
There's four close(fd) calls in prepare_index() and they're all
incorrect. The open fd's are cleaned up in rollback_index_files() and
shouldn't be closed manually. The patch below gets rid of the extra
close() calls and should fix the problem.
This patch improves all of the popen calls in hg-to-git.py by specifying the
template 'hg log' should use instead of calling 'hg log' and grepping for the
desired data.
Signed-off-by: Mark Drago <markdrago@gmail.com> Acked-by: Stelian Pop <stelian@popies.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Squelch bogus progress output from git-rebase--interactive
The command repeats "Rebasing (1/1)" many times even when
there is only one task remaining, because mark_action_done() is
called to skip comment and empty lines in the TODO file.
rerere.enabled is _not_ on by default. The command is enabled if rr-cache
exists even when rerere.enabled is missing, and enabled or disabled by
explicitly setting the rerere.enabled variable.
We are calling overlay_tree_on_cache() which does use CE_UPDATE
flag to mark duplicated entries, which is the same as the
codepath in git-ls-files with its --with-tree option.
Because the pathname ce->name is given to path_list_insert()
which does not allow duplicates, there is no breakage either way
from the correctness point of view in this codepath, unlike the
one in ls-files. But avoiding unnecessary processing with a
single bit check is certainly better.
This hook thought to have found a conflict marker any time it saw
a 7-character combination of any of the characters '<>=' at the
beginning of a line, whereas it should only look for the *same*
character to appear repeatedly.
Also, restrict it to match exactly 7 times, to avoid matching the
underlining with '='-characters often used in documentation.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin-commit.c: remove useless check added by faulty cut and paste
2888605c649ccd423232161186d72c0e6c458a48 (builtin-commit: fix
partial-commit support) mindlessly cut and pasted from
builtin-ls-files.c, and included a part that was meant to
exclude redundant path after "ls-files --with-tree" overlayed
the HEAD commit on top of the index. This logic does not apply
to what git-commit does and should not have been copied, even
though it would not hurt.
[PATCH] gitk: make Ctrl "+" really increase the font size
Only Ctrl "=" was bound to increase the font size, probably because
English keyboards have the plus on the same key as the equal sign.
However, not the whole world is English, and at least with some
other keyboard layouts, Ctrl "+" did not work as documented.
Noticed by Stephan Hennig.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Paul Mackerras <paulus@samba.org>
When running "git commit paths" to create a partial commit, we
used to carefully build the temporary index so that we do not
lose the cached stat information. The rewrite of the command in
C lost it by carelessly using read_tree().
This resurrects the earlier behaviour to keep the cached stat
information as much as possible by using one-tree merge logic.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clean: fix off-by-one memory access when given no arguments
The "seen" variable is used by match_pathspec, and must have
as many elements as there are in the given pathspec. We
create the pathspec either from the command line arguments
_or_ from just the current prefix.
Thus allocating "seen" based upon just argc is wrong, since
if argc == 0, then we still have one pathspec, the prefix,
but we don't allocate any space in "seen".
Signed-off-by: Jeff King <peff@peff.net> Tested-by: İsmail Dönmez <ismail@pardus.org.tr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: handle leading/trailing whitespace from svnsync revprops
Repositories generated by svnsync cannot be relied on to have
properly set revprops without newlines in UUIDs and URLs. There
may be broken versions of svnsync out there that append extra
newlines to UUIDs, or the revprops could've been changed by
repository administrators at any time, too.
At least one repository we've come across has an embedded
newline erroneously set in the svnsync-uuid prop. This is bad
because the trailing newline is taken as another record by the
Git.pm library, and the wantarray detection causes tmp_config()
to return an array with an empty-but-existing second element.
We will now strip leading and trailing whitespace both before
setting and after reading the uuid and url for svnsync values.
We will also force tmp_config to return a single scalar when
reading existing values.
SVN UUIDs should never have whitespace in them, and SVN
repository URLs should be URI-escaped, so neither of those
values we ever see in git-svn should actually have whitespace
in them.
Thanks to Dennis Schridde for the bug report and Junio for
helping diagnose this.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk: Fix the Makefile to cope with systems lacking msgfmt
The po2msg.sh script and the .gitignore in the po directory have been
shamelessly copied from the current git-gui. This enables the top
level "make NO_MSGFMT" to work consistently for git across the git-gui
and gitk sub-projects.
This is the same effective patch that has previously been posted as a
git.git patch which more succinctly described the copying of
po/.gitignore and po/po2msg.sh from git-gui.
Signed-off-by: Charles Bailey <charles@hashpling.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
prop_walk adds a leading / to all subdirectory paths. Unfortunately
this causes a problem when the remote repo lives in a subdirectory itself,
as the leading / causes subsequent PROPFIND calls to be executed on
the wrong path. Trimming the / before calling the PROPFIND fixes this problem.
Signed-off-by: Kevin Ballard <kevin@sb.org> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Change git-gc documentation to reflect gc.packrefs implementation.
56752391a8c0c591853b276e4fa0b45c34ced181 (Make "git gc" pack all
refs by default) changed the default of gc.packrefs to true, to
pack all refs by default in any repository. IOW, the users need
to disable it explicitly if they want to by setting the config
variable, since 1.5.3.
However, we forgot to update the documentation. This fixes it.
Signed-off-by: Florian La Roche <laroche@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
recv_sideband: Do not use ANSI escape sequence on dumb terminals.
The "clear to end of line" sequence is used to nicely output the progress
indicator without leaving garbage on the terminal. However, this works
only on ANSI capable terminals. We use the same check as in color.c to
find out whether the terminal supports this feature and use a workaround
(a few spaces in a row) if it does not.
[jc: as an old fashoned git myself, and given the fact that the
possible prefix and suffix are small number of short constant strings,
I actually prefer a simpler-and-more-stupid approach. This is with
Nico's clean-up.]
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
[PATCH] gitk: use user-configured background in view definition dialog
[PATCH] gitk: Update German translation
[PATCH] gitk: Update and fix Makefile
gitk: Restore some widget options whose defaults changed in Tk 8.5
gitk: Recode de.po to UTF-8
[PATCH] gitk i18n: Recode gitk from latin1 to utf8 so that the (c) copyright character is valid utf8.
[PATCH] gitk i18n: More markup -- various options menus
[PATCH] gitk i18n: Initial German translation
[PATCH] gitk i18n: Markup several strings for translation
[PATCH] gitk i18n: Import msgcat for message string translation; load translation catalogs
[PATCH] gitk i18n: Add Makefile with rules for po file creation and installation
[PATCH] gitk: use user-configured background in view definition dialog
Have the text fields in the view definition dialog (View->New view...)
use the background color as configured through the preferences, instead
of hard-coded 'white'.
This was suggested by Paul Wise through http://bugs.debian.org/457124
Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Paul Mackerras <paulus@samba.org>
When running "git apply --check" while --whitespace=fix is
enabled (either from the command line or via the configuration),
we reported that "N line(s) applied after _fixing_", but --check
by itself does not apply and this message was alarming.
We could even reword the message to say "N line(s) would have
been applied after fixing...", but this patch does not go that
far. Instead, we just make it use the "N lines add whitespace
errors" warning, which happens to be a good diagnostic message a
user would expect from the --check option.
git-svn: support for funky branch and project names over HTTP(S)
SVN requires that paths be URI-escaped for HTTP(S) repositories.
file:// and svn:// repositories do not need these rules.
Additionally, accessing individual paths inside repositories
(check_path() and get_log() do NOT require escapes to function
and in fact it breaks things).
Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com> Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: do not chomp hunk-header in the middle of a character
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.
utf8_width() function was doing two different things. To pick a
valid character from UTF-8 stream, and compute the display width of
that character. This splits the former to a separate function
pick_one_utf8_char().
Handle the T status from git-diff-index to display type changes
between file/symlink/subproject. Also always show the file type for
symlink and subprojects to indicate that they are not normal files.
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git.el: Retrieve the permissions for up-to-date files.
This allows displaying correctly the executable flag for the initial
commit, and will make it possible to show the file type for up-to-date
symlinks and subprojects.
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the git metapackage require the same version of the subpackages.
Without explicit version deps in the rpm spec file, 'yum update git'
effectively does nothing. Require explicit versions of the subpackages,
so that they get pulled in on an update.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are two possible confusions with the color.interactive
description:
1. the short name "interactive" implies that it covers all
interactive commands; let's explicitly make it so, even
though there are no other interactive commands which
currently use it
2. Not all parts of "git add --interactive" are controlled
by color.interactive (specifically, the diffs require
tweaking color.diff). So let's clarify that it applies
only to displays and prompts.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
add--interactive: allow diff colors without interactive colors
Users with color.diff set to true/auto will not see color in
"git add -i" unless they also set color.interactive.
This changes the semantics of color.interactive to control only the
coloring of the interaction aspect of the command and let color.diff
to control the color of hunk picker, which would arguably be more
convenient.
Old $use_color variable is now renamed to $menu_use_color to make it
clear that it is about coloring the interaction.
The "colored" subroutine now checks if the passed color is defined,
instead of checking $use_color variable, to decide if the lines should
be colored. The various variables that define colors for different
parts of the output are set or unset depending on the setting of
color.interactive and color.diff configuration variables.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When color support was added, we colored the diffs ourselves.
However, 4af756f3 changed this to simply run "git diff-files"
twice, keeping the colored output separately.
This makes the internal diff color variables obsolete with
one exception: when splitting hunks, we have to manually
recreate the fragment for each part of the split. Thus we
keep $fraginfo_color around to do that correctly.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock
Asciidoc configuration:
@@ -149,7 +153,10 @@
# Inline macros.
# Backslash prefix required for escape processing.
# (?s) re flag for line spanning.
-(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
+# Explicit so they can be nested.
+(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
# Anchor: [[[id]]]. Bibliographic anchor.
(?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3
# Anchor: [[id,xreflabel]]
This default regex now matches explicit values, and unfortunately in this
case gitlink was being matched by just 'link', causing the wrong inline
macro template to be applied. By renaming the macro, we can avoid being
matched by the wrong regex.
Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
filter-branch: work correctly with ambiguous refnames
'git-filter-branch branch' could fail producing the error:
"Which ref do you want to rewrite?" if existed another branch
or tag, which name was 'branch-something' or 'something/branch'.
[jc: original report and fix were done between Dmitry Potapov
and Dscho; I rewrote it using "rev-parse --symbolic-full-name"]
The plumbing level can understand that the user meant
"refs/heads/master" when the user says "master" or
"heads/master", but there is no easy way for the scripts to
figure it out without duplicating the dwim_ref() logic.
git-stash clear: refuse to work with extra parameter for now
Because it is so tempting to expect "git stash clear stash@{4}"
to remove the fourth element in the stash while leaving other
elements intact, we should not blindly throw away everything
upon seeing such a command.
This may change when we start using "git reflog delete" to
selectively nuke a single (or multiple, for that matter) stash
entries with such a command line.
gitk: Restore some widget options whose defaults changed in Tk 8.5
The default options for panedwindows in Tk 8.5 make the sash
virtually invisible -- the handle is not shown and the relief is
flat. This puts the defaults back to showing the handle and a
raised relief on the sash, as in Tk 8.4.
This uses the option command to do this, and also uses the option
command to set the default font for various UI elements to the
UI font ("uifont").
git-stash: use stdout instead of stderr for non error messages
Some scripts and libraries check stderr to detect a failing command,
instead of checking the exit code. Because the output from git-status
is not primarily for machine consumption, it would not hurt to send
these messages to stdout instead and it will make it easier to drive
the command for such callers.
Signed-off-by: Marco Costalba <mcostalba@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t3800: do not use a temporary file to hold expected result.
It is a good practice to write program output to a temporary file
during the test, as it would allow easier postmortem when the tested
program does break. But there is no benefit in writing the expected
output out to the temporary.
This actually fixes a bug in check_verify_failure() routine.
The intention of the test seems to make sure the "git mktag" command
fails, and it spits out the expected error message. But if the
command did not fail as expected, the shell function as originally
written would not have detected the failure.
* git://repo.or.cz/git-gui:
git-gui: Make commit log messages end with a newline
Added Swedish translation.
git-gui: Unconditionally use absolute paths with Cygwin
git-gui: Handle file mode changes (644->755) in diff viewer
git-gui: Move frequently used commands to the top of the context menu.
1. The program has already loaded git_diff_ui_config, in
which case this is a noop.
2. The program didn't, which means it is plumbing that
does not _want_ git_diff_ui_config to be loaded.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The funcname patterns influence the "comment" on @@ lines of
the diff. They are safe to use with plumbing since they
don't fundamentally change the meaning of the diff in any
way.
Since all diff users call either diff_ui_config or
diff_basic_config, we can get rid of the lazy reading of the
config.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The diff porcelain uses git_diff_ui_config to set
porcelain-ish config options, like automatically turning on
color. The plumbing specifically avoids calling this
function, since it doesn't want things like automatic color
or rename detection.
However, some diff options should be set for both plumbing
and porcelain. For example, one can still turn on color in
git-diff-files using the --color command line option. This
means we want the color config from color.diff.* (so that
once color is on, we use the user's preferred scheme), but
_not_ the color.diff variable.
We split the diff config into "ui" and "basic", where
"basic" is suitable for use by plumbing (so _most_ things
affecting the output should still go into the "ui" part).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now the routine is an open-coded loop that avoids an extra
strlen() in the previous implementation, it got a bit too big to
be inlined. Uninlining it makes code footprint smaller but the
result still retains the avoidance of strlen() cost.
This updates send-pack and fast-import to use symbolic constants
for checking the return values from check_ref_format(), and also
futureproof the logic in lock_any_ref_for_update() to explicitly
name the case that is usually considered an error but is Ok for
this particular use.
git-svn: unlink index files that were globbed, too
commit 3157dd9e89a71e80673d0bc21b5c0630f3b1fe68 (git-svn: unlink
internal index files after operations) introduced unlinking
index files after fetching. However, this missed indices for
refs that were created by globbing branches and tags. This will
track all refs we ever touch during a fetch and unlink them at
exit time.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Certain codepaths (notably "git log --pretty=format...") use
prefixcmp() extensively, with very short prefixes. In those cases,
calling strlen() is a wasteful operation, so avoid it.
Initial patch by Marco Costalba.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
lock_any_ref_for_update(): reject wildcard return from check_ref_format
Recent check_ref_format() returns -3 as well as -1 (general
error) and -2 (less than two levels). The caller was explicitly
checking for -1, to allow "HEAD" but still needed to disallow
bogus refs.
This introduces symbolic constants for the return values from
check_ref_format() to make them read better and more
meaningful. Normal ref creation codepath can still treat
non-zero return values as errors.
config: handle lack of newline at end of file better
The config parsing routines use the static global
'config_file' to store the FILE* pointing to the current
config file being parsed. The function get_next_char()
automatically converts an EOF on this file to a newline for
the convenience of its callers, and it sets config_file to
NULL to indicate that EOF was reached.
This throws away useful information, though, since some
routines want to call ftell on 'config_file' to find out
exactly _where_ the routine ended. In the case of a key
ending at EOF boundary, we ended up segfaulting in some
cases (changing that key or adding another key in its
section), or failing to provide the necessary newline
(adding a new section).
This patch adds a new flag to indicate EOF and uses that
instead of setting config_file to NULL. It also makes sure
to add newlines where necessary for truncated input. All
three included tests fail without the patch.