summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)AuthorFilesLines
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-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
2016-02-25add DEVELOPER makefile knob to check for acknowledged warningsLibravatar Lars Schneider1-0/+12
We assume Git developers have a reasonably modern compiler and recommend them to enable the DEVELOPER makefile knob to ensure their patches are clear of all compiler warnings the Git core project cares about. Enable the DEVELOPER makefile knob in the Travis-CI build. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-17Merge branch 'js/mingw-tests'Libravatar Junio C Hamano1-0/+1
Test scripts have been updated to remove assumptions that are not portable between Git for POSIX and Git for Windows, or to skip ones with expectations that are not satisfiable on Git for Windows. * js/mingw-tests: (21 commits) gitignore: ignore generated test-fake-ssh executable mingw: do not bother to test funny file names mingw: skip a test in t9130 that cannot pass on Windows mingw: handle the missing POSIXPERM prereq in t9124 mingw: avoid illegal filename in t9118 mingw: mark t9100's test cases with appropriate prereqs t0008: avoid absolute path mingw: work around pwd issues in the tests mingw: fix t9700's assumption about directory separators mingw: skip test in t1508 that fails due to path conversion tests: turn off git-daemon tests if FIFOs are not available mingw: disable mkfifo-based tests mingw: accomodate t0060-path-utils for MSYS2 mingw: fix t5601-clone.sh mingw: let lstat() fail with errno == ENOTDIR when appropriate mingw: try to delete target directory before renaming mingw: prepare the TMPDIR environment variable for shell scripts mingw: factor out Windows specific environment setup Git.pm: stop assuming that absolute paths start with a slash mingw: do not trust MSYS2's MinGW gettext.sh ...
2016-01-27mingw: fix t5601-clone.shLibravatar Johannes Schindelin1-0/+1
Since baaf233 (connect: improve check for plink to reduce false positives, 2015-04-26), t5601 writes out a `plink.exe` for testing that is actually a shell script. So the assumption that the `.exe` extension implies that the file is *not* a shell script is now wrong. Since there was no love for the idea of allowing `.exe` files to be shell scripts on Windows, let's go the other way round: *make* `plink.exe` a real `.exe`. This fixes t5601-clone.sh in Git for Windows' SDK. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-12Merge branch 'ep/make-phoney'Libravatar Junio C Hamano1-0/+9
A slight update to the Makefile. * ep/make-phoney: Makefile: add missing phony target
2015-12-16Makefile: add missing phony targetLibravatar Elia Pinto1-0/+9
Add some missing phony target to Makefile. Signed-off-by: Elia Pinto <gitter.spiros@gmail.com> Helped-by: Matthieu Moy <Matthieu.Moy@imag.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-12-08Merge branch 'dt/refs-backend-pre-vtable'Libravatar Junio C Hamano1-1/+2
Code preparation for pluggable ref backends. * dt/refs-backend-pre-vtable: refs: break out ref conflict checks files_log_ref_write: new function initdb: make safe_create_dir public refs: split filesystem-based refs code into a new file refs/refs-internal.h: new header file refname_is_safe(): improve docstring pack_if_possible_fn(): use ref_type() instead of is_per_worktree_ref() copy_msg(): rename to copy_reflog_msg() verify_refname_available(): new function verify_refname_available(): rename function
2015-12-08Merge branch 'ad/sha1-update-chunked' into maintLibravatar Junio C Hamano1-0/+13
Apple's common crypto implementation of SHA1_Update() does not take more than 4GB at a time, and we now have a compile-time workaround for it. * ad/sha1-update-chunked: sha1: allow limiting the size of the data passed to SHA1_Update() sha1: provide another level of indirection for the SHA-1 functions
2015-12-04Merge branch 'ad/sha1-update-chunked'Libravatar Junio C Hamano1-0/+13
Apple's common crypto implementation of SHA1_Update() does not take more than 4GB at a time, and we now have a compile-time workaround for it. * ad/sha1-update-chunked: sha1: allow limiting the size of the data passed to SHA1_Update() sha1: provide another level of indirection for the SHA-1 functions
2015-11-20refs: split filesystem-based refs code into a new fileLibravatar Michael Haggerty1-1/+2
As another step in the move to pluggable reference backends, move the code that is specific to the filesystem-based reference backend (i.e., the current system of storing references as loose and packed files) into a separate file, refs/files-backend.c. Aside from a tiny bit of file header boilerplate, this commit only moves a subset of the code verbatim from refs.c to the new file, as can easily be verified using patience diff: git diff --patience $commit^:refs.c $commit:refs.c git diff --patience $commit^:refs.c $commit:refs/files-backend.c Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net>
2015-11-05Merge branch 'rp/link-curl-before-ssl' into maintLibravatar Junio C Hamano1-6/+11
The linkage order of libraries was wrong in places around libcurl. * rp/link-curl-before-ssl: configure.ac: detect ssl need with libcurl Makefile: make curl-config path configurable Makefile: link libcurl before zlib
2015-11-05sha1: allow limiting the size of the data passed to SHA1_Update()Libravatar Atousa Pahlevan Duprat1-0/+13
Using the previous commit's inredirection mechanism for SHA1, support a chunked implementation of SHA1_Update() that limits the amount of data in the chunk passed to SHA1_Update(). This is enabled by using the Makefile variable SHA1_MAX_BLOCK_SIZE to specify chunk size. When using Apple's CommonCrypto library this is set to 1GiB (the implementation cannot handle more 4GiB). Signed-off-by: Atousa Pahlevan Duprat <apahlevan@ieee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-29Merge branch 'jc/mailinfo-lib'Libravatar Junio C Hamano1-0/+1
The implementation of "git mailinfo" was refactored so that a mailinfo() function can be directly called from inside a process. * jc/mailinfo-lib: (34 commits) mailinfo: remove calls to exit() and die() deep in the callchain mailinfo: handle charset conversion errors in the caller mailinfo: libify mailinfo: keep the parsed log message in a strbuf mailinfo: handle_commit_msg() shouldn't be called after finding patchbreak mailinfo: move content/content_top to struct mailinfo mailinfo: move [ps]_hdr_data to struct mailinfo mailinfo: move cmitmsg and patchfile to struct mailinfo mailinfo: move charset to struct mailinfo mailinfo: move transfer_encoding to struct mailinfo mailinfo: move check for metainfo_charset to convert_to_utf8() mailinfo: move metainfo_charset to struct mailinfo mailinfo: move use_scissors and use_inbody_headers to struct mailinfo mailinfo: move add_message_id and message_id to struct mailinfo mailinfo: move patch_lines to struct mailinfo mailinfo: move filter/header stage to struct mailinfo mailinfo: move global "FILE *fin, *fout" to struct mailinfo mailinfo: move keep_subject & keep_non_patch_bracket to struct mailinfo mailinfo: introduce "struct mailinfo" to hold globals mailinfo: move global "line" into mailinfo() function ...