git-config recently learned a --get-colorbool option. By
using it, we will get the same color=auto behavior that
other git commands have.
Specifically, this fixes the case where "color.diff = true"
meant "always" in git-svn, but "auto" in other programs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When deciding whether or not to turn on automatic color
support, git_config_colorbool checks whether stdout is a
tty. However, because we run a pager, if stdout is not a
tty, we must check whether it is because we started the
pager. This used to be done by checking the pager_in_use
variable.
This variable was set only when the git program being run
started the pager; there was no way for an external program
running git indicate that it had already started a pager.
This patch allows a program to set GIT_PAGER_IN_USE to a
true value to indicate that even though stdout is not a tty,
it is because a pager is being used.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive did not support merging trees that have conflicting
changes in submodules they contain, and died. Support it exactly the
same way as how it handles conflicting symbolic link changes --- mark it
as a conflict, take the tentative result from the current side, and
letting the caller resolve the conflict, without dying in merge_file()
function.
Also reword the error message issued when merge_file() has to die
because it sees a tree entry of type it does not support yet.
[jc: fixed up initial draft by Finn Arne Gangstad]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The scripted version relied on the nice "auto-strip the terminating LF"
behaviour shell gives to "var=$(cmd)" construct, but we have to roll
that ourselves.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 396865859918e9c7bf8ce74aae137c57da134610 broke signed tags using
the "-u" flag when it made builtin-tag.c use parse_options() to parse its
arguments (but it quite possibly was broken even before that, by the
builtin rewrite).
It used to be that passing the signing ID with the -u parameter also
(obviously!) implied that you wanted to sign and annotate the tag, but
that logic got dropped. It also totally ignored the actual key ID that was
passed in.
This reinstates it all.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When not prompting, initial_reply_to can be left unset. Do not try to
sanitize it and get useless warning.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
DESTDIR is supposed to be overridden on 'make install' after doing
'make'. Have the automatically generated perl/perl.mak not cache the
value of DESTDIR to support that for the perl/ subdirectory also.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check for asciidoc, and if it exists check asciidoc version, setting
ASCIIDOC8 when needed. Currently it just runs asciidoc in asciidoc7
compatibility mode (see: Documentation/Makefile).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reinstates an old optimization in .rev_db which
stored the highest revision number we scanned, allowing
us to avoid scanning the SVN log for those revisions
again in a subsequent invocation.
This means the last 24-byte record in a .rev_map file
can be a 4-byte SVN revision number with 20-bytes of
zeroes representing a non-existent commit. This record
can and will be overwritten when a new commit iff
the commit is all zeroes.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Migrations are done automatically on an as-needed basis when new
revisions are to be fetched. Stale remote branches do not get
migrated, yet.
However, unless you set noMetadata or useSvkProps it's safe to
just do:
find $GIT_DIR/svn -name '.rev_db*' -print0 | xargs rm -f
to purge all the old .rev_db files.
The new format is a one-way migration and is NOT compatible with
old versions of git-svn.
This is the replacement for the rev_db format, which was too big
and inefficient for large repositories with a lot of sparse history
(mainly tags).
The format is this:
- 24 bytes for every record,
* 4 bytes for the integer representing an SVN revision number
* 20 bytes representing the sha1 of a git commit
- No empty padding records like the old format
- new records are written append-only since SVN revision numbers
increase monotonically
- lookups on SVN revision number are done via a binary search
- Piping the file to xxd(1) -c24 is a good way of dumping it for
viewing or editing, should the need ever arise.
As with .rev_db, these files are disposable unless noMetadata or
useSvmProps is set.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code that splits the object list amongst work threads tries to do so
on "path" boundaries not to prevent good delta matches. However, in
some cases, a few paths may largely dominate the hash distribution and
it is not possible to have good load balancing without ignoring those
boundaries.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you have local changes that don't conflict with the
branch-switching changes, these should be kept, not cause errors even
without -m, and be reported afterwards in name-status format.
With -m, the changes carried across should be listed as well. And, for
now, include the merge-recursive output from this process.
Also test the detatched head message in at least one case.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An item in a bulletted list in AsciiDoc is followed with two colons,
not just one.
Signed-off-by: Eyvind Bernhardsen <eyvind-git@orakel.ntnu.no>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As pointed out by Junio on the mailing list, surrounding tests in
double quotes can lead to bugs wherein variables get substituted away,
so this isn't just style churn but important to prevent others from
looking at these tests in the future and thinking that this is "the
way" that Git tests should be written.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Supplement the existing tests for the commit-msg hook (which all use
"git commit -m") with tests which use an interactive editor (no -m
switch) to ensure that all code paths get tested.
At the same time the quoting of some of the existing tests is changed
to conform to Junio's recommendations for test style (single quotes
used around the test unless there is a compelling reason not to, and
the opening quote on the same line as the test_expect and the closing
quote in column 1).
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier attempt in 2ea7fe0 (ls-remote: resurrect pattern limit support) forgot
that the user string can also be a glob. This should finally fix it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Quite some variables defined as extern in http.h are only used in http.c,
and some others, only defined in http.c, were not static.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
3803bcea tried to fix this, but it only adds the branckes when the given
In-Reply-To begins and ends with whitespaces. It also didn't do anything
to the --in-reply-to argument.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tip about speeding up subsequent operations is now
obsolete; since aecbf914, git-diff now squelches empty diffs
and performs an automatic refresh.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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
Also explain that "git instaweb" may use "web.browser" config
variable.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now "git-instaweb" will try to use the browser configured as
"web.browser", if "instaweb.browser" is not set.
"git-browse-help" will check first "help.browser" and then
"web.browser".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now when using "git help -w cmd", we will try to show the HTML man
page "git-cmd.html" in your prefered web browser.
To do that "help.c" code will call a new shell script
"git-browse-help".
This currently works only if the HTML versions of the man page
have been installed in $(htmldir) (typically "/usr/share/doc/git-doc"),
so new target to do that is added to "Documentation/Makefile".
The browser to use can be configured using the "web.browser"
config variable.
We try to open a new tab in an existing web browser, if possible.
The code in "git-browse-help" is heavily stolen from "git-mergetool"
by Theodore Y. Ts'o. Thanks.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
