Junio C Hamano [Sat, 20 Feb 2010 18:38:42 +0000 (10:38 -0800)]
Merge branch 'maint'
* maint:
git-p4: fix bug in symlink handling
t1450: fix testcases that were wrongly expecting failure
Documentation: Fix indentation problem in git-commit(1)
Evan Powers [Tue, 16 Feb 2010 08:44:08 +0000 (00:44 -0800)]
git-p4: fix bug in symlink handling
Fix inadvertent breakage from b932705 (git-p4: stream from perforce to
speed up clones, 2009-07-30) in the code that strips the trailing '\n'
from p4 print on a symlink. (In practice, contents is of the form
['target\n', ''].)
Signed-off-by: Evan Powers <evan.powers@gmail.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Sat, 20 Feb 2010 00:18:44 +0000 (01:18 +0100)]
t1450: fix testcases that were wrongly expecting failure
Almost exactly a year ago in 02a6552 (Test fsck a bit harder), I
introduced two testcases that were expecting failure.
However, the only bug was that the testcases wrote *blobs* because I
forgot to pass -t tag to hash-object. Fix this, and then adjust the
rest of the test to properly check the result.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jacob Helwig [Mon, 15 Feb 2010 12:33:06 +0000 (04:33 -0800)]
Documentation: Fix indentation problem in git-commit(1)
Ever since the "See linkgit:git-config[1]..." paragraph was added to the
description for --untracked-files (d6293d1), the paragraphs for the
following options were indented at the same level as the "See
linkgit:git-config[1]" paragraph. This problem showed up in the
manpages, but not in the HTML documentation.
While this does fix the alignment of the options following
--untracked-files in the manpage, the "See linkgit..." portion of the
description does not retain its previous indentation level in the
manpages, or HTML documentation.
Signed-off-by: Jacob Helwig <jacob.helwig@gmail.com> Acked-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Fri, 19 Feb 2010 05:57:21 +0000 (00:57 -0500)]
rm: fix bug in recursive subdirectory removal
If we remove a path in a/deep/subdirectory, we should try to
remove as many trailing components as possible (i.e.,
subdirectory, then deep, then a). However, the test for the
return value of rmdir was reversed, so we only ever deleted
at most one level.
The fix is in remove_path, so "apply" and "merge-recursive"
also are fixed.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Stephen Boyd [Thu, 18 Feb 2010 09:10:28 +0000 (01:10 -0800)]
Documentation: describe --thin more accurately
The description for --thin was misleading and downright wrong. Correct
it with some inspiration from the description of index-pack's --fix-thin
and some background information from Nicolas Pitre <nico@fluxnic.net>.
Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Thu, 18 Feb 2010 01:16:20 +0000 (20:16 -0500)]
docs: don't talk about $GIT_DIR/refs/ everywhere
It is misleading to say that we pull refs from $GIT_DIR/refs/*, because we
may also consult the packed refs mechanism. These days we tend to treat
the "refs hierarchy" as more of an abstract namespace that happens to be
represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at
worst it can confuse users who then look in $GIT_DIR/refs and find that it
is missing some of the refs they expected to see.
This patch drops most uses of "$GIT_DIR/refs/*", changing them into just
"refs/*", under the assumption that users can handle the concept of an
abstract refs namespace. There are a few things to note:
- most cases just dropped the $GIT_DIR/ portion. But for cases where
that left _just_ the word "refs", I changed it to "refs/" to help
indicate that it was a hierarchy. I didn't do the same for longer
paths (e.g., "refs/heads" remained, instead of becoming
"refs/heads/").
- in some cases, no change was made, as the text was explicitly about
unpacked refs (e.g., the discussion in git-pack-refs).
- In some cases it made sense instead to note the existence of packed
refs (e.g., in check-ref-format and rev-parse).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 17 Feb 2010 23:28:25 +0000 (15:28 -0800)]
Merge branch 'np/fast-import-idx-v2'
* np/fast-import-idx-v2:
fast-import: use the diff_delta() max_delta_size argument
fast-import: honor pack.indexversion and pack.packsizelimit config vars
fast-import: make default pack size unlimited
fast-import: use write_idx_file() instead of custom code
fast-import: use sha1write() for pack data
fast-import: start using struct pack_idx_entry
Acked-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 17 Feb 2010 22:55:24 +0000 (14:55 -0800)]
Merge branch 'jk/cherry-pick-reword' into maint
* jk/cherry-pick-reword:
cherry-pick: prettify the advice message
cherry-pick: show commit name instead of sha1
cherry-pick: format help message as strbuf
cherry-pick: refactor commit parsing code
cherry-pick: rewrap advice message
Jakub Narebski [Sun, 7 Feb 2010 20:52:25 +0000 (21:52 +0100)]
gitweb: Protect escaping functions against calling on undef
This is a bit of future-proofing esc_html and friends: when called
with undefined value they would now would return undef... which would
probably mean that error would still occur, but closer to the source
of problem.
This means that we can safely use
esc_html(shift) || "Internal Server Error"
in die_error() instead of
esc_html(shift || "Internal Server Error")
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jakub Narebski [Sun, 7 Feb 2010 20:51:18 +0000 (21:51 +0100)]
gitweb: esc_html (short) error message in die_error
The error message (second argument to die_error) is meant to be short,
one-line text description of given error. A few callers call
die_error with error message containing unescaped user supplied data
($hash, $file_name). Instead of forcing callers to escape data,
simply call esc_html on the parameter.
Note that optional third parameter, which contains detailed error
description, is meant to be HTML formatted, and therefore should be
not escaped.
While at it update esc_html synopsis/usage, and bring default error
description to read 'Internal Server Error' (titlecased).
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nicolas Pitre [Wed, 17 Feb 2010 19:05:56 +0000 (14:05 -0500)]
fast-import: use the diff_delta() max_delta_size argument
This let diff_delta() abort early if it is going to bust the given
size limit. Also, only objects larger than 20 bytes are considered
as objects smaller than that are most certainly going to produce
larger deltas than the original object due to the additional headers.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nicolas Pitre [Wed, 17 Feb 2010 19:05:54 +0000 (14:05 -0500)]
fast-import: make default pack size unlimited
Now that fast-import is creating packs with index version 2, there is
no point limiting the pack size by default. A pack split will still
happen if off_t is not sufficiently large to hold large offsets.
While updating the doc, let's remove the "packfiles fit on CDs"
suggestion. Pack files created by fast-import are still suboptimal and
a 'git repack -a -f -d' or even 'git gc --aggressive' would be a pretty
good idea before considering storage on CDs.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Nicolas Pitre [Wed, 17 Feb 2010 19:05:52 +0000 (14:05 -0500)]
fast-import: use sha1write() for pack data
This is in preparation for using write_idx_file(). Also, by using
sha1write() we get some buffering to reduces the number of write
syscalls, and the written data is SHA1 summed which allows for the extra
data integrity validation check performed in fixup_pack_header_footer()
(details on this in commit abeb40e5aa).
Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Wed, 17 Feb 2010 06:40:45 +0000 (22:40 -0800)]
Merge branch 'maint'
* maint:
Prepare 1.7.0.1 release notes
Fix use of mutex in threaded grep
dwim_ref: fix dangling symref warning
stash pop: remove 'apply' options during 'drop' invocation
diff: make sure --output=/bad/path is caught
Remove hyphen from "git-command" in two error messages
Junio C Hamano [Tue, 16 Feb 2010 02:34:28 +0000 (18:34 -0800)]
Fix use of mutex in threaded grep
The program can decide at runtime not to use threading even if the support
is compiled in. In such a case, mutexes are not necessary and left
uninitialized. But the code incorrectly tried to take and release the
read_sha1_mutex unconditionally.
Signed-off-by: Junio C Hamano <gitster@pobox.com> Acked-by: Fredrik Kuivinen <frekui@gmail.com>
Junio C Hamano [Tue, 16 Feb 2010 23:05:02 +0000 (15:05 -0800)]
Merge branch 'maint-1.6.6' into maint
* maint-1.6.6:
dwim_ref: fix dangling symref warning
stash pop: remove 'apply' options during 'drop' invocation
diff: make sure --output=/bad/path is caught
Remove hyphen from "git-command" in two error messages
Jeff King [Tue, 16 Feb 2010 07:03:16 +0000 (02:03 -0500)]
dwim_ref: fix dangling symref warning
If we encounter a symref that is dangling, in most cases we will warn
about it. The one exception is a dangling HEAD, as that indicates a
branch yet to be born.
However, the check in dwim_ref was not quite right. If we were fed
something like "HEAD^0" we would try to resolve "HEAD", see that it is
dangling, and then check whether the _original_ string we got was
"HEAD" (which it wasn't in this case). And that makes no sense; the
dangling thing we found was not "HEAD^0" but rather "HEAD".
Fixing this squelches a scary warning from "submodule summary HEAD" (and
consequently "git status" with status.submodulesummary set) in an empty
repo, as the submodule script calls "git rev-parse -q --verify HEAD^0".
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Mon, 15 Feb 2010 16:05:46 +0000 (17:05 +0100)]
stash pop: remove 'apply' options during 'drop' invocation
The 'git stash pop' option parsing used to remove the first argument
in --index mode. At the time this was implemented, this first
argument was always --index. However, since the invention of the -q
option in fcdd0e9 (stash: teach quiet option, 2009-06-17) you can
cause an internal invocation of
git stash drop --index
by running
git stash pop -q --index
which then of course fails because drop doesn't know --index.
To handle this, instead let 'git stash apply' decide what the future
argument to 'drop' should be.
Warning: this means that 'git stash apply' must parse all options that
'drop' can take, and deal with them in the same way. This is
currently true for its only option -q.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Acked-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 13 Feb 2010 23:09:33 +0000 (15:09 -0800)]
Merge branch 'jk/cherry-pick-reword'
* jk/cherry-pick-reword:
cherry-pick: prettify the advice message
cherry-pick: show commit name instead of sha1
cherry-pick: format help message as strbuf
cherry-pick: refactor commit parsing code
cherry-pick: rewrap advice message
Junio C Hamano [Wed, 10 Feb 2010 20:33:58 +0000 (12:33 -0800)]
archive documentation: attributes are taken from the tree by default
By default, git-archive takes attributes from the tree being archived.
People however often wonder why their attempts to affect the way how the
command archives their tree by changing .gitattributes in their work tree
fail.
Add a bit of explanatory note to tell them how to achieve what they want
to do.
Noticed-by: Francois Marier Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Thu, 11 Feb 2010 21:19:37 +0000 (16:19 -0500)]
cherry-pick: prettify the advice message
It's hard to see the "how to commit" part of this message,
which users may want to cut and paste. On top of that,
having it in paragraph form means that a really long commit
name may cause ugly wrapping. Let's make it prettier, like:
Automatic cherry-pick failed. After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result with:
git commit -c HEAD~23
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Thu, 11 Feb 2010 21:07:06 +0000 (16:07 -0500)]
cherry-pick: format help message as strbuf
This gets rid of the fixed-size buffer and an unchecked
sprintf. That sprintf is actually OK as the only
variable-sized thing put in it is an abbreviated sha1, which
is bounded at 40 characters. However, the next patch will
change that to something unbounded.
Note that this function now returns an allocated buffer
instead of a static one; however, it doesn't matter as the
only caller exits immediately.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Thu, 11 Feb 2010 22:27:14 +0000 (17:27 -0500)]
am: switch --resolved to --continue
Rebase calls this same function "--continue", which means
users may be trained to type it. There is no reason to
deprecate --resolved (or -r), so we will keep it as a
synonym.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Tue, 9 Feb 2010 18:06:33 +0000 (10:06 -0800)]
t8003: check exit code of command and error message separately
Shell reports exit status only from the most downstream command
in a pipeline. In these tests, we want to make sure that the
command fails in a controlled way, and produces a correct error
message.
This issue was known by Jay who submitted the patch, and also was
pointed out by Hannes during the review process, but I forgot to
fix it up before applying. Sorry about that.
Junio C Hamano [Wed, 10 Feb 2010 21:02:43 +0000 (13:02 -0800)]
Merge branch 'jc/maint-reflog-bad-timestamp' into maint
* jc/maint-reflog-bad-timestamp:
t0101: use a fixed timestamp when searching in the reflog
Update @{bogus.timestamp} fix not to die()
approxidate_careful() reports errorneous date string
Junio C Hamano [Tue, 9 Feb 2010 05:54:10 +0000 (21:54 -0800)]
Merge branch 'maint'
* maint:
blame: prevent a segv when -L given start > EOF
git-push: document all the status flags used in the output
Fix parsing of imap.preformattedHTML and imap.sslverify
git-add documentation: Fix shell quoting example
Jay Soffian [Tue, 9 Feb 2010 03:48:13 +0000 (22:48 -0500)]
blame: prevent a segv when -L given start > EOF
blame would segv if given -L <lineno> with <lineno> past the end of the file.
While we're fixing the bug, add test cases for an invalid <start> when called
as -L <start>,<end> or -L<start>.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Mon, 8 Feb 2010 20:12:41 +0000 (12:12 -0800)]
git-add documentation: Fix shell quoting example
When 921177f (Documentation: improve "add", "pull" and "format-patch"
examples, 2008-05-07) converted this from enumeration header to displayed
text, it failed to adjust for the AsciiDoc's rule to quote backslashes.
In displayed text, backslash is shown verbatim, while in enumeration
header, we need to double it.
We have a similar construct in git-rm.txt documentation, and need to be
careful when somebody wants to update it to match the style of the "git
add" example.
Noticed by: Greg Bacon <gbacon@dbresearch.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
That commit made the situation better for repositories with relatively
small number of objects. However with many objects and a small pack size
limit, the time required to complete the repack tends towards O(n^2),
or even much worse with long delta chains.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Sun, 7 Feb 2010 04:44:15 +0000 (23:44 -0500)]
accept "git grep -- pattern"
Currently the only way to "quote" a grep pattern that might
begin with a dash is to use "git grep -e pattern". This
works just fine, and is also the way right way to do it on
many traditional grep implemenations.
Some people prefer to use "git grep -- pattern", however, as
"--" is the usual "end of options" marker, and at least GNU
grep and Solaris 10 grep support this. This patch makes that
syntax work.
There is a slight behavior change, in that "git grep -- $X"
used to be interpreted as "grep for -- in $X". However, that
usage is questionable. "--" is usually the end-of-options
marker, so "git grep" was unlike many other greps in
treating it as a literal pattern (e.g., both GNU grep and
Solaris 10 grep will treat "grep --" as missing a pattern).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sun, 7 Feb 2010 23:52:28 +0000 (15:52 -0800)]
Merge git://repo.or.cz/git-gui
* git://repo.or.cz/git-gui:
git-gui: update french translation
git-gui: update Japanese translation
git-gui: fix shortcut for menu "Commit/Revert Changes"
git-gui: Quote git path when starting another gui in a submodule
git-gui: update Italian translation
git-gui: Update Swedish translation (520t0f0u)
git-gui: use themed tk widgets with Tk 8.5
git-gui: Update German translation (12 new or changed strings).
git-gui: Update translation template
git-gui: Remove unused icon file_parttick
git-gui: use different icon for new and modified files in the index
git-gui: set GIT_DIR and GIT_WORK_TREE after setup
git-gui: update shortcut tools to use _gitworktree
git-gui: handle bare repos correctly
git-gui: handle non-standard worktree locations
git-gui: Support applying a range of changes at once
git-gui: Add a special diff popup menu for submodules
git-gui: Use git diff --submodule when available
René Scharfe [Sun, 7 Feb 2010 23:30:20 +0000 (00:30 +0100)]
archive: simplify archive format guessing
The code to guess an output archive's format consumed any --format
options and built a new one. Jonathan noticed that it does so in an
unsafe way, risking to overflow the static buffer fmt_opt.
Change the code to keep the existing --format options intact and to only
add a new one if a format could be guessed based on the output file name.
The new option is added as the first one, allowing the existing ones to
overrule it, i.e. explicit --format options given on the command line win
over format guesses, as before.
To simplify the code further, format_from_name() is changed to return the
full --format option, thus no potentially dangerous sprintf() calls are
needed any more.
Reported-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Mon, 1 Feb 2010 13:39:03 +0000 (08:39 -0500)]
Fix invalid read in quote_c_style_counted
This function did not work on strings that were not NUL-terminated. It
reads through a length-bounded string, searching for characters in need of
quoting. After we find one, we output the quoted character, then advance
our pointer to find the next one. However, we never decremented the
length, meaning we ended up looking at whatever random junk was stored
after the string.
This bug was not found by the existing tests because most code paths feed
a NUL-terminated string. The notable exception is a directory name being
fed by ls-tree.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
René Scharfe [Sat, 6 Feb 2010 09:35:19 +0000 (10:35 +0100)]
setenv(GIT_DIR) clean-up
This patch converts the setenv() calls in path.c and setup.c. After
the call, git grep with a pager works again in bare repos.
It leaves the setenv(GIT_DIR_ENVIRONMENT, ...) calls in git.c alone, as
they respond to command line switches that emulate the effect of setting
the environment variable directly.
The remaining site in environment.c is in set_git_dir() and is left
alone, too, of course. Finally, builtin-init-db.c is left changed
because the repo is still being carefully constructed when the
environment variable is set.
This fixes git shortlog when run inside a git directory, which had been
broken by abe549e1.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Brian Gernhardt [Sat, 6 Feb 2010 14:50:03 +0000 (09:50 -0500)]
t9501: Re-fix max load test
Revert the previous attempt to skip this test on platforms where we
currently cannot determine the system load. We want to make sure that
the max-load-limit codepath produces results cleanly, when gitweb is
updated and becomes capable of reading the load average by some other
method.
The code to check for load returns 0 if it doesn't know how to find
load. It also checks to see if the current load is higher than the
max load. So to force the script to quit early by setting the maxload
variable negative which should work for systems where we can detect
load (which should be a positive number) and systems where we can't
(where detected load is 0)
Signed-off-by: Brian Gernhardt <brian@gernhardtsoftware.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
projects / git / log