* ob/imap-send-ssl-verify:
imap-send: support subjectAltName as well
imap-send: the subject of SSL certificate must match the host
imap-send: move #ifdef around
Check not only the common name of the certificate subject, but also
check the subject alternative DNS names as well, when verifying that
the certificate matches that of the host we are trying to talk to.
Signed-off-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
imap-send: the subject of SSL certificate must match the host
We did not check a valid certificate's subject at all, and would
have happily talked with a wrong host after connecting to an
incorrect address and getting a valid certificate that does not
belong to the host we intended to talk to.
Signed-off-by: Oswald Buddenhagen <ossi@kde.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Html documents will be installed to root dir (/) no matter what prefix
is set, if run these commands before `make` and `make install-html`:
$ make configure
$ ./configure --prefix=<PREFIX>
After the installation, all the html documents will copy to rootdir (/),
and:
$ git --html-path
<PREFIX>
$ git help -w something
fatal: '<PREFIX>': not a documentation directory.
This is because the variable "htmldir" points to a undefined variable
"$(docdir)" in file "config.mak.autogen", which is generated by running
`./configure`. By default $(docdir) generated by configure is supposed
be set this way:
but since fc1c5415d69d (Honor configure's htmldir switch, 2013-02-02),
we only set and export htmldir without doing so for PACKAGE_TARNAME
(which is set to 'git' by the configure script).
Add the required two variables "PACKAGE_TARNAME" and "docdir" to file
"config.mak.in" will work this issue around.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Usually we do not pass an empty string to the function hash_name()
because we almost always ask for hash values for a path that is a
candidate to be added to the index. However, check-ignore (and most
likely check-attr, but I didn't check) apparently has a callchain
to ask the hash value for an empty path when it was given a "." from
the top-level directory to ask "Is the path . excluded by default?"
Make sure that hash_name() does not overrun the end of the given
pathname even when it is empty.
Remove a sweep-the-issue-under-the-rug conditional in check-ignore
that avoided to pass an empty string to the callchain while at it.
It is a valid question to ask for check-ignore if the top-level is
set to be ignored by default, even though the answer is most likely
no, if only because there is currently no way to specify such an
entry in the .gitignore file. But it is an unusual thing to ask and
it is not worth optimizing for it by special casing at the top level
of the call chain.
Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
user-manual: Flesh out uncommitted changes and submodule updates
If you try and update a submodule with a dirty working directory, you
get an error message like:
$ git submodule update
error: Your local changes to the following files would be overwritten by checkout:
...
Please, commit your changes or stash them before you can switch branches.
Aborting
...
Mention this in the submodule notes. The previous phrase was short
enough that I originally thought it might have been referring to the
reflog note (obviously, uncommitted changes will not show up in the
reflog either ;).
Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
user-manual: Use request-pull to generate "please pull" text
Less work and more error checking (e.g. does a merge base exist?).
Add an explicit push before request-pull to satisfy request-pull,
which checks to make sure the references are publically available.
Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
user-manual: Reorganize the reroll sections, adding 'git rebase -i'
I think this interface is often more convenient than extended cherry
picking or using 'git format-patch'. In fact, I removed the
cherry-pick section entirely. The entry-level suggestions for
rerolling are now:
1. git commit --amend
2. git format-patch origin
git reset --hard origin
...edit and reorder patches...
git am *.patch
3. git rebase -i origin
Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
test_expect_success_multi() helper function warrants some explanation,
since at first sight it may seem like generic test framework plumbing,
but is in fact specific to testing check-ignore, and allows more
thorough testing of the various output formats without significantly
increase the size of t0008.
Signed-off-by: Adam Spiers <git@adamspiers.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-commit: only append a newline to -m mesg if necessary
Currently, git will append two newlines to every message supplied via
the -m switch. The purpose of this is to allow -m to be supplied
multiple times and have each supplied string become a paragraph in the
resulting commit message.
Normally, this does not cause a problem since any trailing newlines will
be removed by the cleanup operation. If cleanup=verbatim for example,
then the trailing newlines will not be removed and will survive into the
resulting commit message.
Instead, let's ensure that the string supplied to -m is newline terminated,
but only append a second newline when appending additional messages.
Fixes the test in t7502.
Signed-off-by: Brandon Casey <drafnel@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t7502: demonstrate breakage with a commit message with trailing newlines
This test attempts to verify that a commit message supplied to 'git
commit' via the -m switch was used in full as the commit message for a
commit when --cleanup=verbatim was used.
But, this test has been broken since it was introduced. Since the
commit message containing trailing newlines was supplied to 'git commit'
using a command substitution, the trailing newlines were removed by the
shell. This means that a string without any trailing newlines was
actually supplied to 'git commit'.
The test was able to complete successfully since internally, git appends
two newlines to each string supplied via the -m switch. So, the two
newlines removed by the shell were then re-added by git, and the
resulting commit matched what was expected.
So, let's move the initial creation of the commit message string out
from within a previous test so that it stands alone. Assign the desired
commit message to a variable using literal newlines. Then populate the
expect file from the contents of the commit message variable. This way
the shell variable becomes the authoritative source of the commit
message and can be supplied via the -m switch with the trailing newlines
intact.
Mark this test as failing, since it is not handled correctly by git.
As described above, git appends two extra newlines to every string
supplied via -m, even to the ones that already end with a newline.
Signed-off-by: Brandon Casey <drafnel@gmail.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
t/t7502: compare entire commit message with what was expected
This test attempts to verify that a commit in "verbatim" mode, when
supplied a commit template, produces a commit in which the commit
message matches exactly the template that was supplied. But, since the
commit operation appends additional instructions for the user as
comments in the commit buffer, which would cause the comparison to fail,
this test decided to compare only the first three lines (the length of
the template) of the resulting commit message to the original template
file.
This has two problems.
1. It does not allow the template to be lengthened or shortened
without also modifying the number of lines that are considered
significant (i.e. the argument to 'head -n').
2. It will not catch a bug in git that causes git to append additional
lines to the commit message.
So, let's use the --no-status option to 'git commit' which will cause
git to refrain from appending the lines of instructional text to the
commit message. This will allow the entire resulting commit message to
be compared against the expected value.
Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of adding an early return to the inside of the
ssl_socket_connect() function for NO_OPENSSL compilation, split it
into a separate stub function.
No functional change, but the next change to extend ssl_socket_connect()
will become easier to read this way.
We stopped mentioning `tracking` is a deprecated but supported
synonym for `upstream` in pull.default even though we have no
intention of removing the support for it.
* jc/mention-tracking-for-pull-default:
doc: mention tracking for pull.default
* maint:
user-manual: use -o latest.tar.gz to create a gzipped tarball
user-manual: use 'git config --global user.*' for setup
user-manual: mention 'git remote add' for remote branch config
user-manual: give 'git push -f' as an alternative to +master
user-manual: use 'remote add' to setup push URLs
user-manual: use 'git config --global user.*' for setup
A simple command line call is easier than spawning an editor,
especially for folks new to ideas like the "command line" and "text
editors". This is also the approach suggested by 'git commit' if you
try and commit without having configured user.name or user.email.
Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git.txt: update description of the configuration mechanism
The old Git version where it appeared is now useful only to historians,
not to normal users. Also, the text was mentioning only the per-repo
config file, but this is a good place to teach that customization can
also be made per-user.
While at it, remove a now-defunct e-mail from an example.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"make COMPUTE_HEADER_DEPENDENCIES=no clean" would try to run "rm
-rf $(dep_dirs)" with an empty dep_dir, but some implementations of
"rm -rf" barf on an empty argument list.
* mk/make-rm-depdirs-could-be-empty:
Makefile: don't run "rm" without any files
user-manual: Update for receive.denyCurrentBranch=refuse
acd2a45 (Refuse updating the current branch in a non-bare repository
via push, 2009-02-11) changed the default to refuse such a push, but
it forgot to update the docs.
7d182f5 (Documentation: receive.denyCurrentBranch defaults to
'refuse', 2010-03-17) updated Documentation/config.txt, but forgot to
update the user manual.
Signed-off-by: W. Trevor King <wking@tremily.us> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refactors a lot of repetitive code sequence from the graph drawing
code and adds it to the combined diff output.
* jk/diff-graph-cleanup:
combine-diff.c: teach combined diffs about line prefix
diff.c: use diff_line_prefix() where applicable
diff: add diff_line_prefix function
diff.c: make constant string arguments const
diff: write prefix to the correct file
graph: output padding for merge subsequent parents
* bw/get-tz-offset-perl:
cvsimport: format commit timestamp ourselves without using strftime
perl/Git.pm: fix get_tz_offset to properly handle DST boundary cases
Move Git::SVN::get_tz to Git::get_tz_offset
Instead of requiring the full 40-hex object names on the index
line, we can read submodule commit object names from the textual
diff when synthesizing a fake ancestore tree for "git am -3".
* jc/extended-fake-ancestor-for-gitlink:
apply: verify submodule commit object name better
contrib/subtree updates, but here are only the ones that looked
ready. The remainder of the patches will have another day.
* dg/subtree-fixes:
contrib/subtree: make the manual directory if needed
contrib/subtree: honor DESTDIR
contrib/subtree: fix synopsis
contrib/subtree: better error handling for 'subtree add'
contrib/subtree: use %B for split subject/body
contrib/subtree: remove test number comments
pretty: parse the gpg status lines rather than the output
Currently, parse_signature_lines() parses the gpg output for strings
which depend on LANG so it fails to recognize good commit signatures
(and thus does not fill in %G? and the like) in most locales.
Make it parse the status lines from gpg instead, which are the proper
machine interface. This fixes the problem described above.
There is a change in behavior for "%GS" which we intentionally do not
work around: "%GS" used to put quotes around the signer's uid (or
rather: it inherited from the gpg user output). We output the uid
without quotes now, just like author and committer names.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gpg-interface: check good signature in a reliable way
Currently, verify_signed_buffer() only checks the return code of gpg,
and some callers implement additional unreliable checks for "Good
signature" in the gpg output meant for the user.
Use the status output instead and parse for a line beinning with
"[GNUPG:] GOODSIG ". This is the only reliable way of checking for a
good gpg signature.
If needed we can change this easily to "[GNUPG:] VALIDSIG " if we want
to take into account the trust model.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add 3 extra tests for the bash.showDirtyState config option; the
tests now cover all combinations of the shell var being set/unset
and the config option being missing/enabled/disabled, given a dirty
file.
Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add 4 tests for the bash.showUntrackedFiles config option, covering
all combinations of the shell var being set/unset and the config
option being enabled/disabled (the other 2 cases, missing config
with and without shell variable, are already covered by existing
tests).
Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When COMPUTE_HEADER_DEPENDENCIES is set to "auto" and the compiler
does not support it, $(dep_dirs) becomes empty. "make clean" runs
"rm -rf $(dep_dirs)", which can fail in such a case.
Signed-off-by: Matt Kraai <matt.kraai@amo.abbott.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a config option 'bash.showUntrackedFiles' which allows enabling
the prompt showing untracked files on a per-repository basis. This is
useful for some repositories where the 'git ls-files ...' command may
take a long time.
Signed-off-by: Martin Erik Werner <martinerikwerner@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit eff80a9 (Allow custom "comment char") introduced a custom comment
character for commit messages but did not teach git-rebase--interactive
to use it.
Change git-rebase--interactive to read core.commentchar and use its
value when generating commit messages and for the command list.
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
combine-diff.c: teach combined diffs about line prefix
When running "git log --graph --cc -p" the diff output for merges is not
indented by the graph structure, unlike the diffs of non-merge commits
(added in commit 7be5761 - diff.c: Output the text graph padding before
each diff line).
Fix this by teaching the combined diff code to output diff_line_prefix()
before each line.
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a helper function to call the diff output_prefix function and
return its value as a C string, allowing us to greatly simplify
everywhere that needs to get the output prefix.
Signed-off-by: John Keeping <john@keeping.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This needs to be done in two places: __git_config_get_set_variables to
allow clever completion of "git config --local --get foo<tab>", and
_git_config to allow "git config --loc<tab>" to complete to --local.
While we're there, change the order of options in the code to match
git-config.txt.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
pathspec is the most widely used term, and is the one defined in
gitglossary.txt. <filepattern> was used only in the synopsys for git-add
and git-commit, and in git-add.txt. Get rid of it.
Because our command-line parser considers only one byte at the time
for short-options, we incorrectly report only the first byte when
multi-byte input was provided. This makes user-errors slightly
awkward to diagnose for instance under UTF-8 locale and non-English
keyboard layouts.
Report the whole argument-string when a non-ASCII short-option is
detected.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Improved-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
expat 1.1 and 1.2 provide xmlparse.h instead of expat.h. Include the
former on systems that define the EXPAT_NEEDS_XMLPARSE_H variable and
define that variable on QNX systems, which ship with expat 1.1.
Signed-off-by: Matt Kraai <matt.kraai@amo.abbott.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you run "git log --grep=foo", we will run your regex on
the literal bytes of the commit message. This can provide
confusing results if the commit message is not in the same
encoding as your grep expression (or worse, you have commits
in multiple encodings, in which case your regex would need
to be written to match either encoding). On top of this, we
might also be grepping in the commit's notes, which are
already re-encoded, potentially leading to grepping in a
buffer with mixed encodings concatenated. This is insanity,
but most people never noticed, because their terminal and
their commit encodings all match.
Instead, let's massage the to-be-grepped commit into a
standardized encoding. There is not much point in adding a
flag for "this is the encoding I expect my grep pattern to
match"; the only sane choice is for it to use the log output
encoding. That is presumably what the user's terminal is
using, and it means that the patterns found by the grep will
match the output produced by git.
As a bonus, this fixes a potential segfault in commit_match
when commit->buffer is NULL, as we now build on logmsg_reencode,
which handles reading the commit buffer from disk if
necessary. The segfault can be triggered with:
which arguably does not make any sense (--graph inherently
wants a connected history, and by --no-walk the command line
is telling us to show discrete points in history without
connectivity), and we probably should forbid the
combination, but that is a separate issue.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add utf8_fprintf helper that returns correct number of columns
Since command usages can be translated, they may include utf-8
encoded strings, and the output in console may not align well any
more. This is because strlen() is different from strwidth() on utf-8
strings.
A wrapper utf8_fprintf() can help to return the correct number of
columns required.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Reviewed-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"reset" can be easily misunderstood as resetting a bisect session to its
start without finishing it. Clarify that it actually quits the bisect
session.
Reported-by: Andreas Mohr <andi@lisas.de> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
cvsimport: format commit timestamp ourselves without using strftime
Some implementations of strftime(3) lack support for "%z". Also
there is no need for %s in git-cvsimport as the supplied time is
already in seconds since the epoch.
For %z, use the function get_tz_offset provided by Git.pm instead.
Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
perl/Git.pm: fix get_tz_offset to properly handle DST boundary cases
When passed a local time that was on the boundary of a DST change,
get_tz_offset returned a GMT offset that was incorrect (off by one
hour). This is because the time was converted to GMT and then back to
a time stamp via timelocal() which cannot disambiguate boundary cases
as noted in its documentation.
Modify this algorithm, using an approach suggested in
to first convert the timestamp in question to two broken down forms
with localtime() and gmtime(), and then compute what timestamps
these two broken down forms would represent in GMT (i.e. a timezone
that does not have DST issues) by applying timegm() on them. The
difference between the resulting timestamps is the timezone offset.
This avoids the ambigious conversion and allows a correct time to be
returned on every occassion.
Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function has utility outside of the SVN module for any routine
that needs the equivalent of GNU strftime's %z formatting option.
Move it to the top-level Git.pm so that non-SVN modules don't need to
import the SVN module to use it.
The rename makes the purpose of the function clearer.
Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>