summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
2016-09-26Merge branch 'js/regexec-buf'Libravatar Junio C Hamano1-1/+2
Some codepaths in "git diff" used regexec(3) on a buffer that was mmap(2)ed, which may not have a terminating NUL, leading to a read beyond the end of the mapped region. This was fixed by introducing a regexec_buf() helper that takes a <ptr,len> pair with REG_STARTEND extension. * js/regexec-buf: regex: use regexec_buf() regex: add regexec_buf() that can work on a non NUL-terminated string regex: -G<pattern> feeds a non NUL-terminated string to regexec() and fails
2016-09-26Merge branch 'rs/cocci'Libravatar Junio C Hamano1-0/+14
Code cleanup. * rs/cocci: use strbuf_addstr() for adding constant strings to a strbuf, part 2 add coccicheck make target contrib/coccinelle: fix semantic patch for oid_to_hex_r()
2016-09-21regex: add regexec_buf() that can work on a non NUL-terminated stringLibravatar Johannes Schindelin1-1/+2
We just introduced a test that demonstrates that our sloppy use of regexec() on a mmap()ed area can result in incorrect results or even hard crashes. So what we need to fix this is a function that calls regexec() on a length-delimited, rather than a NUL-terminated, string. Happily, there is an extension to regexec() introduced by the NetBSD project and present in all major regex implementation including Linux', MacOSX' and the one Git includes in compat/regex/: by using the (non-POSIX) REG_STARTEND flag, it is possible to tell the regexec() function that it should only look at the offsets between pmatch[0].rm_so and pmatch[0].rm_eo. That is exactly what we need. Since support for REG_STARTEND is so widespread by now, let's just introduce a helper function that always uses it, and tell people on a platform whose regex library does not support it to use the one from our compat/regex/ directory. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-19Merge branch 'cc/apply-am'Libravatar Junio C Hamano1-0/+1
"git am" has been taught to make an internal call to "git apply"'s innards without spawning the latter as a separate process. * cc/apply-am: (41 commits) builtin/am: use apply API in run_apply() apply: learn to use a different index file apply: pass apply state to build_fake_ancestor() apply: refactor `git apply` option parsing apply: change error_routine when silent usage: add get_error_routine() and get_warn_routine() usage: add set_warn_routine() apply: don't print on stdout in verbosity_silent mode apply: make it possible to silently apply apply: use error_errno() where possible apply: make some parsing functions static again apply: move libified code from builtin/apply.c to apply.{c,h} apply: rename and move opt constants to apply.h builtin/apply: rename option parsing functions builtin/apply: make create_one_file() return -1 on error builtin/apply: make try_create_file() return -1 on error builtin/apply: make write_out_results() return -1 on error builtin/apply: make write_out_one_result() return -1 on error builtin/apply: make create_file() return -1 on error builtin/apply: make add_index_file() return -1 on error ...
2016-09-15add coccicheck make targetLibravatar René Scharfe1-0/+14
Provide a simple way to run Coccinelle against all source files, in the form of a Makefile target. Running "make coccicheck" applies each .cocci file in contrib/coccinelle/ on all source files. It generates a .patch file for each .cocci file, containing the actual changes for effecting the transformations described by the semantic patches. Non-empty .patch files are reported. They can be applied to the work tree using "patch -p0", but should be checked to e.g. make sure they don't screw up formatting or create circular references. Coccinelle's diagnostic output (stderr) is piped into .log files. Linux has a much more elaborate make target of the same name; let's start nice and easy. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-09-12Merge branch 'rs/compat-strdup'Libravatar Junio C Hamano1-3/+14
* rs/compat-strdup: compat: move strdup(3) replacement to its own file
2016-09-07compat: move strdup(3) replacement to its own fileLibravatar René Scharfe1-3/+14
Move our implementation of strdup(3) out of compat/nedmalloc/ and allow it to be used independently from USE_NED_ALLOCATOR. The original nedmalloc doesn't come with strdup() and doesn't need it. Only _users_ of nedmalloc need it, which was added when we imported it to our compat/ hierarchy. This reduces the difference of our copy of nedmalloc from the original, making it easier to update, and allows for easier testing and reusing of our version of strdup(). Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-11builtin/apply: move init_apply_state() to apply.cLibravatar Christian Couder1-0/+1
To libify `git apply` functionality we must make init_apply_state() usable outside "builtin/apply.c". Let's do that by moving it into a new "apply.c". Helped-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-08Merge branch 'ew/build-time-pager-tweaks'Libravatar Junio C Hamano1-1/+20
The build procedure learned PAGER_ENV knob that lists what default environment variable settings to export for popular pagers. This mechanism is used to tweak the default settings to MORE on FreeBSD. * ew/build-time-pager-tweaks: pager: move pager-specific setup into the build
2016-08-08Merge branch 'jk/pack-objects-optim'Libravatar Junio C Hamano1-0/+1
"git pack-objects" has a few options that tell it not to pack objects found in certain packfiles, which require it to scan .idx files of all available packs. The codepaths involved in these operations have been optimized for a common case of not having any non-local pack and/or any .kept pack. * jk/pack-objects-optim: pack-objects: compute local/ignore_pack_keep early pack-objects: break out of want_object loop early find_pack_entry: replace last_found_pack with MRU cache add generic most-recently-used list sha1_file: drop free_pack_by_name t/perf: add tests for many-pack scenarios
2016-08-08Merge branch 'nd/test-helpers' into maintLibravatar Junio C Hamano1-10/+2
Build clean-up. * nd/test-helpers: t/test-lib.sh: fix running tests with --valgrind Makefile: use VCSSVN_LIB to refer to svn library Makefile: drop extra dependencies for test helpers
2016-08-04pager: move pager-specific setup into the buildLibravatar Eric Wong1-1/+20
Allowing PAGER_ENV to be set at build-time allows us to move pager-specific knowledge out of our build. This allows us to set a better default for FreeBSD more(1), which pretends not to understand ANSI color escapes if the MORE environment variable is left empty, but accepts the same variables as less(1) Originally-from: https://public-inbox.org/git/xmqq61piw4yf.fsf@gitster.dls.corp.google.com/ Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-29add generic most-recently-used listLibravatar Jeff King1-0/+1
There are a few places in Git that would benefit from a fast most-recently-used cache (e.g., the list of packs, which we search linearly but would like to order based on locality). This patch introduces a generic list that can be used to store arbitrary pointers in most-recently-used order. The implementation is just a doubly-linked list, where "marking" an item as used moves it to the front of the list. Insertion and marking are O(1), and iteration is O(n). There's no lookup support provided; if you need fast lookups, you are better off with a different data structure in the first place. There is also no deletion support. This would not be hard to do, but it's not necessary for handling pack structs, which are created and never removed. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-25Merge branch 'nd/test-helpers'Libravatar Junio C Hamano1-10/+2
Build clean-up. * nd/test-helpers: t/test-lib.sh: fix running tests with --valgrind Makefile: use VCSSVN_LIB to refer to svn library Makefile: drop extra dependencies for test helpers
2016-07-25Merge branch 'rw/make-needs-librt'Libravatar Junio C Hamano1-3/+9
Makefile assumed that -lrt is always available on platforms that want to use clock_gettime() and CLOCK_MONOTONIC, which is not a case for recent Mac OS X. The necessary symbols are often found in libc on many modern systems and having -lrt on the command line, as long as the library exists, had no effect, but when the platform removes librt.a that is a different matter--having -lrt will break the linkage. This change could be seen as a regression for those who do need to specify -lrt, as they now specifically ask for NEEDS_LIBRT when building. Hopefully they are in the minority these days. * rw/make-needs-librt: config.mak.uname: define NEEDS_LIBRT under Linux, for now Makefile: add NEEDS_LIBRT to optionally link with librt
2016-07-25Merge branch 'mh/ref-iterators'Libravatar Junio C Hamano1-0/+2
The API to iterate over all the refs (i.e. for_each_ref(), etc.) has been revamped. * mh/ref-iterators: for_each_reflog(): reimplement using iterators dir_iterator: new API for iterating over a directory tree for_each_reflog(): don't abort for bad references do_for_each_ref(): reimplement using reference iteration refs: introduce an iterator interface ref_resolves_to_object(): new function entry_resolves_to_object(): rename function from ref_resolves_to_object() get_ref_cache(): only create an instance if there is a submodule remote rm: handle symbolic refs correctly delete_refs(): add a flags argument refs: use name "prefix" consistently do_for_each_ref(): move docstring to the header file refs: remove unnecessary "extern" keywords
2016-07-19Merge branch 'jk/common-main'Libravatar Junio C Hamano1-4/+13
There are certain house-keeping tasks that need to be performed at the very beginning of any Git program, and programs that are not built-in commands had to do them exactly the same way as "git" potty does. It was easy to make mistakes in one-off standalone programs (like test helpers). A common "main()" function that calls cmd_main() of individual program has been introduced to make it harder to make mistakes. * jk/common-main: mingw: declare main()'s argv as const common-main: call git_setup_gettext() common-main: call restore_sigpipe_to_default() common-main: call sanitize_stdfds() common-main: call git_extract_argv0_path() add an extra level of indirection to main()
2016-07-13Merge branch 'va/i18n-even-more'Libravatar Junio C Hamano1-1/+4
More markings of messages for i18n, with updates to various tests to pass GETTEXT_POISON tests. One patch from the original submission dropped due to conflicts with jk/upload-pack-hook, which is still in flux. * va/i18n-even-more: (38 commits) t5541: become resilient to GETTEXT_POISON i18n: branch: mark comment when editing branch description for translation i18n: unmark die messages for translation i18n: submodule: escape shell variables inside eval_gettext i18n: submodule: join strings marked for translation i18n: init-db: join message pieces i18n: remote: allow translations to reorder message i18n: remote: mark URL fallback text for translation i18n: standardise messages i18n: sequencer: add period to error message i18n: merge: change command option help to lowercase i18n: merge: mark messages for translation i18n: notes: mark options for translation i18n: notes: mark strings for translation i18n: transport-helper.c: change N_() call to _() i18n: bisect: mark strings for translation t5523: use test_i18ngrep for negation t4153: fix negated test_i18ngrep call t9003: become resilient to GETTEXT_POISON tests: unpack-trees: update to use test_i18n* functions ...
2016-07-07Makefile: add NEEDS_LIBRT to optionally link with librtLibravatar Ronald Wampler1-3/+9
We unconditionally link with librt, when HAVE_CLOCK_GETTIME is defined. But clock_gettime() has been available in most libc implementations for some time now (e.g., for glibc since version 2.17) and no longer requires linking with librt. Furthermore, commit a6c3c63 (configure.ac: check for clock_gettime() and CLOCK_MONOTONIC) will automatically determined which library (libc or librt) is required for linking when checking for clock_gettime(). The assumption to unconditionally link with librt was OK, since either almost every Unix-like system provides a version of librt for backwards compatibility or other systems, namely Windows or OS X, never provided clock_gettime(). However, in the latest release of OS X (macOS Sierra), this function has been added to OS X libc version. As a result, when running the configuration script, HAVE_CLOCK_GETTIME is set and since librt is not present, it causes a linker error. This patches requires those not building via the configuration scripts to define NEEDS_LIBRT in addition to HAVE_CLOCK_GETTIME, if needed. Signed-off-by: Ronald Wampler <rdwampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06Makefile: use VCSSVN_LIB to refer to svn libraryLibravatar Jeff King1-2/+2
We have an abstracted variable; let's use it consistently. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06Makefile: drop extra dependencies for test helpersLibravatar Jeff King1-8/+0
A few test-helpers have Makefile dependencies on specific object files. But since these files are part of libgit.a (which all of the helpers link against), the inclusion is simply redundant. These were once necessary, but became redundant due to 5c5ba73 (Makefile: Use generic rule to build test programs, 2007-05-31), which added the $(GITLIBS) dependency (but didn't prune the extra dependency lines). Later commits then cargo-culted the practice (e.g., b4285c7). Note that we _do_ need to leave the dependencies on the svn library, as that is not part of the usual link command. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-06Merge branch 'jk/common-main-2.8' into jk/common-mainLibravatar Junio C Hamano1-4/+13
* jk/common-main-2.8: mingw: declare main()'s argv as const common-main: call git_setup_gettext() common-main: call restore_sigpipe_to_default() common-main: call sanitize_stdfds() common-main: call git_extract_argv0_path() add an extra level of indirection to main()
2016-07-01add an extra level of indirection to main()Libravatar Jeff King1-4/+13
There are certain startup tasks that we expect every git process to do. In some cases this is just to improve the quality of the program (e.g., setting up gettext()). In others it is a requirement for using certain functions in libgit.a (e.g., system_path() expects that you have called git_extract_argv0_path()). Most commands are builtins and are covered by the git.c version of main(). However, there are still a few external commands that use their own main(). Each of these has to remember to include the correct startup sequence, and we are not always consistent. Rather than just fix the inconsistencies, let's make this harder to get wrong by providing a common main() that can run this standard startup. We basically have two options to do this: - the compat/mingw.h file already does something like this by adding a #define that replaces the definition of main with a wrapper that calls mingw_startup(). The upside is that the code in each program doesn't need to be changed at all; it's rewritten on the fly by the preprocessor. The downside is that it may make debugging of the startup sequence a bit more confusing, as the preprocessor is quietly inserting new code. - the builtin functions are all of the form cmd_foo(), and git.c's main() calls them. This is much more explicit, which may make things more obvious to somebody reading the code. It's also more flexible (because of course we have to figure out _which_ cmd_foo() to call). The downside is that each of the builtins must define cmd_foo(), instead of just main(). This patch chooses the latter option, preferring the more explicit approach, even though it is more invasive. We introduce a new file common-main.c, with the "real" main. It expects to call cmd_main() from whatever other objects it is linked against. We link common-main.o against anything that links against libgit.a, since we know that such programs will need to do this setup. Note that common-main.o can't actually go inside libgit.a, as the linker would not pick up its main() function automatically (it has no callers). The rest of the patch is just adjusting all of the various external programs (mostly in t/helper) to use cmd_main(). I've provided a global declaration for cmd_main(), which means that all of the programs also need to match its signature. In particular, many functions need to switch to "const char **" instead of "char **" for argv. This effect ripples out to a few other variables and functions, as well. This makes the patch even more invasive, but the end result is much better. We should be treating argv strings as const anyway, and now all programs conform to the same signature (which also matches the way builtins are defined). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20dir_iterator: new API for iterating over a directory treeLibravatar Michael Haggerty1-0/+1
The iterator interface is modeled on that for references, though no vtable is necessary because there is (so far?) only one type of dir_iterator. There are obviously a lot of features that could easily be added to this class: * Skip/include directory paths in the iteration * Shallow/deep iteration * Letting the caller decide which subdirectories to recurse into (e.g., via a dir_iterator_advance_into() function) * Option to iterate in sorted order * Option to iterate over directory paths before vs. after their contents But these are not needed for the current patch series, so I refrain. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-20refs: introduce an iterator interfaceLibravatar Michael Haggerty1-0/+1
Currently, the API for iterating over references is via a family of for_each_ref()-type functions that invoke a callback function for each selected reference. All of these eventually call do_for_each_ref(), which knows how to do one thing: iterate in parallel through two ref_caches, one for loose and one for packed refs, giving loose references precedence over packed refs. This is rather complicated code, and is quite specialized to the files backend. It also requires callers to encapsulate their work into a callback function, which often means that they have to define and use a "cb_data" struct to manage their context. The current design is already bursting at the seams, and will become even more awkward in the upcoming world of multiple reference storage backends: * Per-worktree vs. shared references are currently handled via a kludge in git_path() rather than iterating over each part of the reference namespace separately and merging the results. This kludge will cease to work when we have multiple reference storage backends. * The current scheme is inflexible. What if we sometimes want to bypass the ref_cache, or use it only for packed or only for loose refs? What if we want to store symbolic refs in one type of storage backend and non-symbolic ones in another? In the future, each reference backend will need to define its own way of iterating over references. The crux of the problem with the current design is that it is impossible to compose for_each_ref()-style iterations, because the flow of control is owned by the for_each_ref() function. There is nothing that a caller can do but iterate through all references in a single burst, so there is no way for it to interleave references from multiple backends and present the result to the rest of the world as a single compound backend. This commit introduces a new iteration primitive for references: a ref_iterator. A ref_iterator is a polymorphic object that a reference storage backend can be asked to instantiate. There are three functions that can be applied to a ref_iterator: * ref_iterator_advance(): move to the next reference in the iteration * ref_iterator_abort(): end the iteration before it is exhausted * ref_iterator_peel(): peel the reference currently being looked at Iterating using a ref_iterator leaves the flow of control in the hands of the caller, which means that ref_iterators from multiple sources (e.g., loose and packed refs) can be composed and presented to the world as a single compound ref_iterator. It also means that the backend code for implementing reference iteration will sometimes be more complicated. For example, the cache_ref_iterator (which iterates over a ref_cache) can't use the C stack to recurse; instead, it must manage its own stack internally as explicit data structures. There is also a lot of boilerplate connected with object-oriented programming in C. Eventually, end-user callers will be able to be written in a more natural way—managing their own flow of control rather than having to work via callbacks. Since there will only be a few reference backends but there are many consumers of this API, this is a good tradeoff. More importantly, we gain composability, and especially the possibility of writing interchangeable parts that can work with any ref_iterator. For example, merge_ref_iterator implements a generic way of merging the contents of any two ref_iterators. It is used to merge loose + packed refs as part of the implementation of the files_ref_iterator. But it will also be possible to use it to merge other pairs of reference sources (e.g., per-worktree vs. shared refs). Another example is prefix_ref_iterator, which can be used to trim a prefix off the front of reference names before presenting them to the caller (e.g., "refs/heads/master" -> "master"). In this patch, we introduce the iterator abstraction and many utilities, and implement a reference iterator for the files ref storage backend. (I've written several other obvious utilities, for example a generic way to filter references being iterated over. These will probably be useful in the future. But they are not needed for this patch series, so I am not including them at this time.) In a moment we will rewrite do_for_each_ref() to work via reference iterators (allowing some special-purpose code to be discarded), and do something similar for reflogs. In future patch series, we will expose the ref_iterator abstraction in the public refs API so that callers can use it directly. Implementation note: I tried abstracting this a layer further to allow generic iterators (over arbitrary types of objects) and generic utilities like a generic merge_iterator. But the implementation in C was very cumbersome, involving (in my opinion) too much boilerplate and too much unsafe casting, some of which would have had to be done on the caller side. However, I did put a few iterator-related constants in a top-level header file, iterator.h, as they will be useful in a moment to implement iteration over directory trees and possibly other types of iterators in the future. Signed-off-by: Ramsay Jones <ramsay@ramsayjones.plus.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: rebase-interactive: mark strings for translationLibravatar Vasco Almeida1-0/+1
Mark strings in git-rebase--interactive.sh for translation. There is no need to source git-sh-i18n since git-rebase.sh already does so. Add git-rebase--interactive.sh to LOCALIZED_SH in Makefile in order to enable extracting strings marked for translation by xgettext. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: git-sh-setup.sh: mark strings for translationLibravatar Vasco Almeida1-1/+3
Positional arguments, such as $0, $1, etc, need to be stored on shell variables for use in translatable strings, according to gettext manual [1]. Add git-sh-setup.sh to LOCALIZED_SH variable in Makefile to enable extraction of string marked for translation by xgettext. Source git-sh-i18n in git-sh-setup.sh for gettext support. git-sh-setup.sh is a shell library to be sourced by other shell scripts. In order to avoid other scripts from sourcing git-sh-i18n twice, remove line that sources it from them. Not sourcing git-sh-i18n in any script that uses gettext would lead to failure due to, for instance, gettextln not being found. [1] http://www.gnu.org/software/gettext/manual/html_node/Preparing-Shell-Scripts.html Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-03Merge branch 'mm/makefile-developer-can-be-in-config-mak'Libravatar Junio C Hamano1-8/+9
"make DEVELOPER=1" worked as expected; setting DEVELOPER=1 in config.mak didn't. * mm/makefile-developer-can-be-in-config-mak: Makefile: add $(DEVELOPER_CFLAGS) variable Makefile: move 'ifdef DEVELOPER' after config.mak* inclusion
2016-06-01Makefile: add $(DEVELOPER_CFLAGS) variableLibravatar Matthieu Moy1-9/+10
This does not change the behavior, but allows the user to tweak DEVELOPER_CFLAGS on the command-line or in a config.mak* file if needed. This also makes the code somewhat cleaner as it follows the pattern <initialisation of variables> <include statements> <actual build logic> by specifying which flags to activate in the first part, and actually activating them in the last one. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-31Makefile: move 'ifdef DEVELOPER' after config.mak* inclusionLibravatar Matthieu Moy1-12/+12
The DEVELOPER knob was introduced in 658df95 (add DEVELOPER makefile knob to check for acknowledged warnings, 2016-02-25), and works well when used as "make DEVELOPER=1", and when the configure script was not used. However, the advice given in CodingGuidelines to add DEVELOPER=1 to config.mak does not: config.mak is included after testing for DEVELOPER in the Makefile, and at least GNU Make's manual specifies "Conditional directives are parsed immediately", hence the config.mak declaration is not visible at the time the conditional is evaluated. Also, when using the configure script to generate a config.mak.autogen, the later file contained a "CFLAGS = <flags>" initialization, which overrode the "CFLAGS += -W..." triggered by DEVELOPER. This patch fixes both issues. Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-26Merge branch 'va/i18n-misc-updates' into maintLibravatar Junio C Hamano1-1/+1
Mark several messages for translation. * va/i18n-misc-updates: i18n: unpack-trees: avoid substituting only a verb in sentences i18n: builtin/pull.c: split strings marked for translation i18n: builtin/pull.c: mark placeholders for translation i18n: git-parse-remote.sh: mark strings for translation i18n: branch: move comment for translators i18n: branch: unmark string for translation i18n: builtin/rm.c: remove a comma ',' from string i18n: unpack-trees: mark strings for translation i18n: builtin/branch.c: mark option for translation i18n: index-pack: use plural string instead of normal one
2016-05-23Merge branch 'jc/doc-lint'Libravatar Junio C Hamano1-0/+1
Find common mistakes when writing gitlink: in our documentation and drive the check from "make check-docs". I am not entirely happy with the way the script chooses what input file to validate, but it is not worse than not having anything, so let's move it forward and have the logic improved later when people care about it deeply. * jc/doc-lint: ci: validate "linkgit:" in documentation
2016-05-17Merge branch 'va/i18n-misc-updates'Libravatar Junio C Hamano1-1/+1
Mark several messages for translation. * va/i18n-misc-updates: i18n: unpack-trees: avoid substituting only a verb in sentences i18n: builtin/pull.c: split strings marked for translation i18n: builtin/pull.c: mark placeholders for translation i18n: git-parse-remote.sh: mark strings for translation i18n: branch: move comment for translators i18n: branch: unmark string for translation i18n: builtin/rm.c: remove a comma ',' from string i18n: unpack-trees: mark strings for translation i18n: builtin/branch.c: mark option for translation i18n: index-pack: use plural string instead of normal one
2016-05-10ci: validate "linkgit:" in documentationLibravatar Junio C Hamano1-0/+1
It is easy to add incorrect "linkgit:<page>[<section>]" references to our documentation suite. Catch these common classes of errors: * Referring to Documentation/<page>.txt that does not exist. * Referring to a <page> outside the Git suite. In general, <page> must begin with "git". * Listing the manual <section> incorrectly. The first line of the Documentation/<page>.txt must end with "(<section>)". with a new script "ci/lint-gitlink", and drive it from "make check-docs". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-05-06Merge branch 'ky/imap-send-openssl-1.1.0' into maintLibravatar Junio C Hamano1-6/+0
Upcoming OpenSSL 1.1.0 will break compilation b updating a few APIs we use in imap-send, which has been adjusted for the change. * ky/imap-send-openssl-1.1.0: configure: remove checking for HMAC_CTX_cleanup imap-send: avoid deprecated TLSv1_method() imap-send: check NULL return of SSL_CTX_new() imap-send: use HMAC() function provided by OpenSSL
2016-05-06Merge branch 'jc/drop-git-spec-in'Libravatar Junio C Hamano1-13/+6
As nobody maintains our in-tree git.spec.in and distros use their own spec file, we stopped pretending that we support "make rpm". * jc/drop-git-spec-in: Makefile: remove dependency on git.spec Makefile: stop pretending to support rpmbuild
2016-04-29Merge branch 'jc/makefile-redirection-stderr' into maintLibravatar Junio C Hamano1-2/+2
A minor fix in the Makefile. * jc/makefile-redirection-stderr: Makefile: fix misdirected redirections
2016-04-29Merge branch 'nd/test-helpers'Libravatar Junio C Hamano1-14/+14
Sources to many test helper binaries (and the generated helpers) have been moved to t/helper/ subdirectory to reduce clutter at the top level of the tree. * nd/test-helpers: test helpers: move test-* to t/helper/ subdirectory Makefile: clean *.o files we create
2016-04-27Makefile: remove dependency on git.specLibravatar Dennis Kaarsemaker1-1/+1
ab214331 (Makefile: stop pretending to support rpmbuild, 2016-04-04) dropped support for rpmbuild using our own specfile by removing git.spec.in, but forgot to remove the dependency of the dist target on git.spec. Signed-off-by: Dennis Kaarsemaker <dennis@kaarsemaker.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-22Merge branch 'ky/imap-send-openssl-1.1.0'Libravatar Junio C Hamano1-6/+0
Upcoming OpenSSL 1.1.0 will break compilation b updating a few APIs we use in imap-send, which has been adjusted for the change. * ky/imap-send-openssl-1.1.0: configure: remove checking for HMAC_CTX_cleanup imap-send: avoid deprecated TLSv1_method() imap-send: check NULL return of SSL_CTX_new() imap-send: use HMAC() function provided by OpenSSL
2016-04-19i18n: git-parse-remote.sh: mark strings for translationLibravatar Vasco Almeida1-1/+1
Change Makefile to include git-parse-remote.sh in LOCALIZED_SH. TODO: remove 3rd argument of error_on_missing_default_upstream function that is no longer required. Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-15test helpers: move test-* to t/helper/ subdirectoryLibravatar Nguyễn Thái Ngọc Duy1-12/+12
This keeps top dir a bit less crowded. And because these programs are for testing purposes, it makes sense that they stay somewhere in t/ Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-15Makefile: clean *.o files we createLibravatar Junio C Hamano1-2/+2
The part that removes object files in the 'clean' target predates various Makefile macros that list object files we create, and instead removes the objects with shell glob, perpetually requiring updates whenever a new location that builds object files is added. Simplify the target by removing $(OBJECTS), which is supposed to have all the objects we create during the build. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-13Merge branch 'jc/makefile-redirection-stderr'Libravatar Junio C Hamano1-2/+2
A minor fix in the Makefile. * jc/makefile-redirection-stderr: Makefile: fix misdirected redirections
2016-04-08configure: remove checking for HMAC_CTX_cleanupLibravatar Kazuki Yamaguchi1-6/+0
We don't need it, as we no longer use HMAC_CTX_cleanup() directly. Signed-off-by: Kazuki Yamaguchi <k@rhe.jp> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06Makefile: stop pretending to support rpmbuildLibravatar Junio C Hamano1-12/+5
Nobody in the active development community seems to watch breakages in the rpmbuild target. As most major RPM based distros use their own specfile when packaging us, they aren't looking after us as their pristine upstream tree, either. At this point, it is turning to be a disservice to the users to pretend that our tree natively supports "make rpmbuild" target when we do not properly maintain it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-05Makefile: fix misdirected redirectionsLibravatar Junio C Hamano1-2/+2
In general "echo 2>&1 $msg" to redirect a possible error message that comes from 'echo' itself into the same standard output stream $msg is getting written to does not make any sense; it is not like we are expecting to see any errors out of 'echo' in these statements, and even if it were the case, there is no reason to prevent the error messages from being sent to the standard error stream. These are clearly meant to send the argument given to echo to the standard error stream as error messages. Correctly redirect by saying "send what is written to the standard output to the standard error", i.e. "1>&2" aka ">&2". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-16Merge branch 'jc/sane-grep'Libravatar Junio C Hamano1-1/+5
Recent versions of GNU grep is pickier than before to decide if a file is "binary" and refuse to give line-oriented hits when we expect it to, unless explicitly told with "-a" option. As our scripted Porcelains use sane_grep wrapper for line-oriented data, even when the line may contain non-ASCII payload we took from end-user data, use "grep -a" to implement sane_grep wrapper when using an implementation of "grep" that takes the "-a" option. * jc/sane-grep: rebase-i: clarify "is this commit relevant?" test sane_grep: pass "-a" if grep accepts it
2016-03-10sane_grep: pass "-a" if grep accepts itLibravatar Junio C Hamano1-1/+5
Newer versions of GNU grep is reported to be pickier when we feed a non-ASCII input and break some Porcelain scripts. As we know we do not feed random binary file to our own sane_grep wrapper, allow us to always pass "-a" by setting SANE_TEXT_GREP=-a Makefile variable to work it around. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-26Merge branch 'ls/makefile-cflags-developer-tweak'Libravatar Junio C Hamano1-0/+12
There is a new DEVELOPER knob that enables many compiler warning options in the Makefile. * ls/makefile-cflags-developer-tweak: add DEVELOPER makefile knob to check for acknowledged warnings