When loading a notes tree, the code primarily looks for SHA1-like paths
whose total length (discounting directory separators) are 40 chars
(interpreted as valid note entries) or less (interpreted as subtree
entries that may in turn contain note entries when unpacked).
However, there is an additional condition that must hold for valid
subtree entries: They must be _tree_ objects (duh).
This patch adds an appropriate test for this condition, thereby fixing
the crash that occured when passing a non-tree object to the tree-walk
API.
The patch also adds another selftest verifying correct behaviour of
non-notes in note trees.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '--no-chain-reply-to' option is a Getopt::Long boolean option. The
'--no-' prefix (as in --no-chain-reply-to) for boolean options is not
supported in Getopt::Long version 2.32 which was released with Perl 5.8.0.
This version only supports '--no' as in '--nochain-reply-to'. More recent
versions of Getopt::Long, such as version 2.34, support either prefix. So
use the older form in the tests.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even setting it to empty is better than leaving it unset as it
prevents the warning cruft from appearing in the output.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now "git merge <msg> HEAD" is officially deprecated, we should
clean our own use as well.
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Prepare for 1.6.5.4
merge: do not add standard message when message is given with -m option
Do not misidentify "git merge foo HEAD" as an old-style invocation
Conflicts:
RelNotes
Even if the user explicitly gave her own message to "git merge", the
command still added its standard merge message. It resulted in a
useless repetition like this:
% git merge -m "Merge early part of side branch" `git rev-parse side~2`
% git show -s
commit 37217141e7519629353738d5e4e677a15096206f
Merge: e68e646 a1d2374
Author: しらいし ななこ <nanako3@lavabit.com>
Date: Wed Dec 2 14:33:20 2009 +0900
Merge early part of side branch
Merge commit 'a1d2374f8f52f4e8a53171601a920b538a6cec23'
The gave her own message because she didn't want git to add the
standard message (if she wanted to, she wouldn't have given one,
or she would have prepared it using git-fmt-merge-msg command).
Noticed by Nanako Shiraishi
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was misinterpreted as an ancient style "git merge <message> HEAD
<commit> <commit>..." that merges one (or more) <commit> into the current
branch and record the resulting commit with the given message. Then a
later sanity check found that there is no <commit> specified and gave
a usage message.
Tested-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
help: Do not unnecessarily look for a repository
Documentation: Fix a few i.e./e.g. mix-ups
Documentation: Document --branch option in git clone synopsis
The ancient form of git merge command used in the original sample script
has been copied from Linus and are still found everywhere, I think, and
people may still have it in their scripts, but on the other hand, it is so
unintuitive that even people reasonably familiar with git are surprised by
accidentally triggering the support to parse this ancient form.
Gently nudge people to upgrade their script to more recent and readable
style for eventual removal of the original syntax.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The entries in states->stale list is filled in handle_one_branch() that is
a call-back funcation to for_each_ref() using the callback parameter given
to it. We need to strdup() the refnames (both the string list key and the
value stored in util) for more permanent storage and free them when we are
done.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although 'git help' actually doesn't need to be run inside a git
repository and uses no repository-specific information, it looks for a git
directory. Searching for a git directory can be annoying in auto-mount
environments. With this commit, 'git help' no longer searches for a
repository when run without any options.
7c3baa9 originally modified 'git help -a' to not require a repository.
This applies the same fix for 'git help'.
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A git bundle can be transported by several means (such as e-mail), not
only by snekaernet, so use e.g. instead of i.e.
The mix-up in git-bundle.txt is obvious.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/gitweb-blame:
gitweb: Add link to other blame implementation in blame views
gitweb: Make linking to actions requiring JavaScript a feature
gitweb.js: fix padLeftStr() and its usage
gitweb.js: Harden setting blamed commit info in incremental blame
gitweb.js: fix null object exception in initials calculation
gitweb: Minify gitweb.js if JSMIN is defined
gitweb: Create links leading to 'blame_incremental' using JavaScript
gitweb: Colorize 'blame_incremental' view during processing
gitweb: Incremental blame (using JavaScript)
gitweb: Add optional "time to generate page" info in footer
Conflicts:
Makefile
gitweb/gitweb.css
Add link to 'blame_incremental' action (which requires JavaScript) in
'blame' view, and add link to 'blame' action in 'blame_incremental'
view.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Let gitweb turn some links (like 'blame' links) into linking to actions
which require JavaScript (like 'blame_incremental' action) only if
'javascript-actions' feature is enabled.
This means that links to such actions would be present only if both
JavaScript is enabled and 'javascript-actions' feature is enabled.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document the --branch option as [-b <name>] in git clones synopsis.
Signed-off-by: David Soria Parra <dsp@php.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fadd069d03 (merge-recursive: give less scary messages when merge did not
start, Sep 7 2009) introduced some friendlier error message for merge
failure, but the messages were shown only for non-fast forward merges.
This patch uses the same for fast-forward.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The construction of the struct unpack_trees_error_msgs was done within
git_merge_trees(), which prevented using the same messages easily from
another function.
[jc: backported for 1.6.5 maint before advice_commit_before_merge]
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These were added without documentation in 2009-03-16 (6720721).
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed to allow test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We need to call exclude_cmds() after the loop, not during the loop, because
excluding a command from the array can change the indexes of objects in the
array. The result is that, depending on file ordering, some commands
weren't excluded as they should have been.
Signed-off-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is needed to allow the test suite to run against a standard
install bin directory instead of GIT_EXEC_PATH.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Give a warning message when send-email uses chain-reply-to to thread the
messages because of the current default, not because the user explicitly
asked to, either from the command line or from the configuration.
This way, by the time 1.7.0 switches the default, everybody will be ready.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The ARM SHA-1 implementation was removed by commit 30ae47b
(remove ARM and Mozilla SHA1 implementations, 2009-08-17). Prune
its directory from the list of object files to delete in 'make
clean'.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Inspired by the coloring of quilt.
Introduce a separate color and paint the hunk comment part, i.e. the name
of the function, in a separate color "diff.func" (defaults to plain).
Whitespace between hunk header and hunk comment is printed in plain color.
Signed-off-by: Bert Wesarg <bert.wesarg@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds the option to specify the envelope sender as "auto" which
would pick the 'from' address. This is good because now we can specify
the address only in one place in $HOME/.gitconfig and change it easily.
[jc: added tests]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When emit_line() is called with an empty line (but non-zero length, as we
send line terminating LF or CRLF to the function), it used to emit
<SET><RESET> followed by a newline. Stop the wastefulness.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ever since the initial implementation, "git am" had kept a dead code that
never triggered due to a typo in the variable name. Worse yet, the code,
if it weren't for the typo, would have attempted to add "[PATCH] " at the
beginning of the Subject: header when "git am" is run with its "-k"
option. However, because "git am -k" tells mailinfo to keep such prefix
when parsing the input, the "[PATCH] " added by this dead code would have
really been unnecessary duplicate.
Embarrassing is that we kept _maintaining_ the codepath without anybody
noticing for four years.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johan Herland