setup_git_directory_gently has done the check already.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/spht:
Use gitattributes to define per-path whitespace rule
core.whitespace: documentation updates.
builtin-apply: teach whitespace_rules
builtin-apply: rename "whitespace" variables and fix styles
core.whitespace: add test for diff whitespace error highlighting
git-diff: complain about >=8 consecutive spaces in initial indent
War on whitespace: first, a bit of retreat.
Conflicts:
cache.h
config.c
diff.c
An earlier fix to the said commit was incomplete; it mixed up the
meaning of the flag parameter passed to the internal fmt_ident()
function, so this corrects it.
git_author_info() and git_committer_info() can be told to issue a
warning when no usable user information is found, and optionally can be
told to error out. Operations that actually use the information to
record a new commit or a tag will still error out, but the caller to
leave reflog record will just silently use bogus user information.
Not warning on misconfigured user information while writing a reflog
entry is somewhat debatable, but it is probably nicer to the users to
silently let it pass, because the only information you are losing is who
checked out the branch.
* git_author_info() and git_committer_info() used to take 1 (positive
int) to error out with a warning on misconfiguration; this is now
signalled with a symbolic constant IDENT_ERROR_ON_NO_NAME.
* These functions used to take -1 (negative int) to warn but continue;
this is now signalled with a symbolic constant IDENT_WARN_ON_NO_NAME.
* fmt_ident() function implements the above error reporting behaviour
common to git_author_info() and git_committer_info(). A symbolic
constant IDENT_NO_DATE can be or'ed in to the flag parameter to make
it return only the "Name <email@address.xz>".
* fmt_name() is a thin wrapper around fmt_ident() that always passes
IDENT_ERROR_ON_NO_NAME and IDENT_NO_DATE.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As desired, these pass for git-commit.sh, fail for builtin-commit (prior
to the fixes), and succeeded for builtin-commit (after the fixes).
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old git-commit.sh script allowed the commit-msg hook to not only
prevent a commit from proceding, but also to edit the commit message
on the fly and allow it to proceed. So here we teach builtin-commit
to do the same.
This is based on Wincent's patch, but redone with a clarified logic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The documentation for the --no-verify switch should mention the
commit-msg hook, not just the pre-commit hook.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At the moment the --no-verify switch to "git commit" instructs it to
skip over the pre-commit hook. Here we teach "git commit --no-verify"
to skip over the commit-msg hook as well. This brings the behaviour
of builtin-commit back in line with git-commit.sh.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git ls-remote $remote $name1 $name2..." used to limit the output to
refs that end with one of the $name given from the command line, but
recent rewrite to C forgot to implement that support.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code tried to parse and clean-up the author name and the one line
information in three places (two callers of insert_author_oneline() and
the called function itself), which was a mess.
This renames the callee to insert_one_record() and make it responsible
for cleaning up the author name and one line information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The empty loop pretended to have an empty statement as its body by a
phony indentation, but in fact was slurping the next statement into it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current method consists of a master thread serving chunks of objects
to work threads when they're done with their previous chunk. The issue
is to determine the best chunk size: making it too large creates poor
load balancing, while making it too small has a negative effect on pack
size because of the increased number of chunk boundaries and poor delta
window utilization.
This patch implements a completely different approach by initially
splitting the work in large chunks uniformly amongst all threads, and
whenever a thread is done then it steals half of the remaining work from
another thread with the largest amount of unprocessed objects.
This has the advantage of greatly reducing the number of chunk boundaries
with an almost perfect load balancing.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is currently sorted and then walked backward. Not only this doesn't
feel natural for my poor brain, but it would make the next patch less
obvious as well.
So reverse the sort order, and reverse the list walking direction,
which effectively produce the exact same end result as before.
Also bring the relevant comment nearer the actual code and adjust it
accordingly, with minor additional clarifications.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The wrong value was substracted from delta_cache_size when replacing
a cached delta, as trg_entry->delta_size was used after the old size
had been replaced by the new size.
Noticed by Linus.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch is the result of reading over git-status with an
editorial eye:
- fix a few typo/grammatical errors
- mention untracked output
- present output types in the order they appear from the
command
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output of git-status was recently changed to output relative
paths. Setting this variable to false restores the old behavior for
any old-timers that prefer it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that we are correctly removing leading prefixes from files in git
status, there is a degenerate case: the directory matching the prefix.
Because we show only the directory name for a directory that contains
only untracked files, it gets collapsed to an empty string.
Example:
$ git init
$ mkdir subdir
$ touch subdir/file
$ git status
...
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# subdir/
So far, so good.
$ cd subdir
$ git status
....
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#
Oops, that's a bit confusing.
This patch prints './' to show that there is some output.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches "git bisect visualize" to be more useful in non-windowed
environments.
(1) When no option is given, and $DISPLAY is set, it continues to
spawn gitk as before;
(2) When no option is given, and $DISPLAY is unset, "git log" is run
to show the range of commits between the bad one and the good ones;
(3) If only "-flag" options are given, "git log <options>" is run.
E.g. "git bisect visualize --stat"
(4) Otherwise, all of the given options are taken as the initial part
of the command line and the commit range expression is given to
that command. E.g. "git bisect visualize tig" will run "tig"
history viewer to show between the bad one and the good ones.
As "visualize" is a bit too long to type, we also give it a shorter
synonym "view".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rather than replicating the colorization logic of "git diff-files" we
rely on "git diff-files" itself. This guarantees consistent colorization
in and outside "git add -i".
Seeing as speed is not a concern here (the bottleneck is how fast the
user can read, not how fast "git diff-files" runs) we do this by
actually running it twice, once without color and once with.
In this way as the whitespace colorization provided by "git diff-files"
evolves (per-path attributes, new classes of whitespace error), "git
add -i" will automatically benefit from it and stay in synch.
Also, by working with two sets of diff output (an uncolorized one for
internal processing and a colorized one for display only) we minimize
the risk of regressions because the changes required to implement this
are minimally invasive.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Prepend $(prefix)/share/man to the MANPATH environment variable before
invoking 'man' from help.c:show_man_page(). There may be other git
documentation in the user's MANPATH but the user is asking a specific
instance of git about its own documentation, so we'd better show the
documentation for _that_ instance of git.
Signed-off-by: Sergei Organov <osv@javad.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://repo.or.cz/git-gui:
Update Hungarian translation. 100% completed.
Update ja.po for git-gui
git-gui: Improve the application icon on Windows.
git-gui: install-sh from automake does not like -m755
git-gui: Reorder msgfmt command-line arguments
Update German translation. 100% completed.
Update git-gui.pot with latest (few) string additions and changes.
git-gui: update it.po and glossary/it.po
git-gui: fix a typo in lib/commit.tcl
Update configure.ac (and config.mak.in) to keep up with git
development by adding [compile] test whether your library has an old
iconv(), where the second (input buffer pointer) parameter is declared
with type (const char **) (OLD_ICONV).
Test-proposed-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apple ships a newer version of iconv with Leopard (Mac OS X 10.5/Darwin
9). Ensure that OLD_ICONV is not set on any version of Darwin in the
9.x series; this should be good for at least a couple of years, when
Darwin 10 comes out and we can invert the sense of the test to
specifically check for Darwin 7 or 8.
A more sophisticated and robust check is possible for those who use
autoconf, but not everybody does that.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Consistently with all other diff oriented commands, we have given paths
relative to the work tree root in git-status output for a long time.
This documents the recent behaviour change, as people's eyes (and worse
yet, scripts, although scripts should not parse "git status" output) may
depend on the old behaviour.
In the longer run, giving a --full-name option to git-diff Porcelain
similar to what ls-files has, and change the default for git-diff
Porcelain to show relative paths may be a good thing to do, in order to
hide the oddballness of this git-status behaviour, but that would have a
rather large impact to established expectation by existing users.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code calls fetch_pack() to get the list of refs it fetched, and
discards refs and always returns 0 to signal success.
But builtin-fetch-pack.c::fetch_pack() has error cases. The function
returns NULL if error is detected (shallow-support side seems to choose
to die but I suspect that is easily fixable to error out as well).
Make fetch_refs_via_pack() propagate that error to the caller.
Acked-By: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
for-each-ref can accept only one quoting style. For this reason it uses
OPT_BIT for the quoting style switches so that it is easy to check for
more than one bit being set. However, not all symbolic constants were
actually single bit values. In particular:
$ git for-each-ref --python
error: more than one quoting style ?
This fixes it.
While we are here, let's also remove the space before the question mark.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark Drago had a subversion repository which was then converted to hg
and now is moving in to git. The first commit in the svn repo was
just the creation of the empty directory. This made its way in to the
hg repository fine, but converting from hg to git would cause an
error. The problem was that hg-to-git.py tries to commit the change,
git-commit fails, and then hg-to-git.py tries to checkout the new
revision and that fails (because it was not created). This may have
only caused an error because it was the first commit in the
repository. If an empty directory was added in the middle of the repo
somewhere things might have worked out fine.
This patch will use the new --allow-empty option to git-commit to
record such an "empty" commit, to reproduce the history recorded in hg
more faithfully.
Tested-by: Mark Drago <markdrago@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The `core.whitespace` configuration variable allows you to define what
`diff` and `apply` should consider whitespace errors for all paths in
the project (See gitlink:git-config[1]). This attribute gives you finer
control per path.
For example, if you have these in the .gitattributes:
frotz whitespace
nitfol -whitespace
xyzzy whitespace=-trailing
all types of whitespace problems known to git are noticed in path 'frotz'
(i.e. diff shows them in diff.whitespace color, and apply warns about
them), no whitespace problem is noticed in path 'nitfol', and the
default types of whitespace problems except "trailing whitespace" are
noticed for path 'xyzzy'. A project with mixed Python and C might want
to have:
*.c whitespace
*.py whitespace=-indent-with-non-tab
in its toplevel .gitattributes file.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The applications can ask for color.diff but the configuration of old
timer users can still instruct it to use color with diff.color this
way.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before this change, conflicted files were open in external merge tool with
temporary filenames like REMOTE.$$ and LOCAL.$$. This way meld was unable
to recognize these files and syntax highlighting feature was unusable.
Help such merge tools by giving temporar files the same extension as the
original.
Signed-off-by: Pini Reznik <pinir@expand.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clean "*.rej" should attempt to look at only paths that match
pattern "*.rej", but rewrite to C broke it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is mostly lifted from earlier series by Dan Zwell, but updated to
use "git config --get-color" and "git config --get-colorbool" to make it
simpler and more consistent with commands written in C.
A new configuration color.interactive variable is like color.diff and
color.status, and controls if "git-add -i" uses color.
A set of configuration variables, color.interactive.<slot>, are used to
define what color is used for the prompt, header, and help text.
For perl scripts, Git.pm provides $repo->get_color() method, which takes
the slot name and the default color, and returns the terminal escape
sequence to color the output text. $repo->get_colorbool() method can be
used to check if color is set to be used for a given operation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds an option to help scripts find out color settings from
the configuration file.
git config --get-colorbool color.diff
inspects color.diff variable, and exits with status 0 (i.e. success) if
color is to be used. It exits with status 1 otherwise.
If a script wants "true"/"false" answer to the standard output of the
command, it can pass an additional boolean parameter to its command
line, telling if its standard output is a terminal, like this:
git config --get-colorbool color.diff true
When called like this, the command outputs "true" to its standard output
if color is to be used (i.e. "color.diff" says "always", "auto", or
"true"), and "false" otherwise.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-am -i: report rewritten title
git grep shows the same hit repeatedly for unmerged paths
Do check_repository_format() early (re-fix)
Do check_repository_format() early
Add missing inside_work_tree setting in setup_git_directory_gently
Jeff Garzik noticed that "git am -i" reports the applied patch with
the title before the user edited it. This was confusing.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the index is unmerged, e.g.
$ git ls-files -u
100644 faf413748eb6ccb15161a212156c5e348302b1b6 1 setup.c
100644 145eca50f4 2 setup.c
100644 cb9558c49b6027bf225ba2a6154c4d2a52bcdbe2 3 setup.c
running "git grep" for work tree files repeats hits for each unmerged
stage.
$ git grep -n -e setup_work_tree -- '*.[ch]'
setup.c:209:void setup_work_tree(void)
setup.c:209:void setup_work_tree(void)
setup.c:209:void setup_work_tree(void)
This should fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
