The malloc checks can be disabled using the TEST_NO_MALLOC_CHECK
variable, either from the environment or command line of an
'make test' invocation. In order to allow the malloc checks to be
disabled from the 'config.mak' file, we add TEST_NO_MALLOC_CHECK
to the environment using an export directive.
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Includes the addition of some new defines and their description for others to use.
Signed-off-by: NJoachim Schmitz <jojo@schmitz-digital.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

move poll.[ch] out of compat/win32/ into compat/poll/ and adjust
Makefile with the changed paths. Adding comments to Makefile about
how/when to enable it and add logic for this
Signed-off-by: NJoachim Schmitz <jojo@schmitz-digital.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Add two new functions, string_list_split() and
string_list_split_in_place().  These split a string into a string_list
on a separator character.  The first makes copies of the substrings
(leaving the input string untouched) and the second splits the
original string in place, overwriting the separator characters with
NULs and referring to the original string's memory.

These functions are similar to the strbuf_split_*() functions except
that they work with the more powerful string_list interface.
Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJoachim Schmitz <jojo@schmitz-digital.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The current code uses setitimer() only for reducing perceived
latency.  On platforms that lack setitimer() (e.g. HP NonStop),
allow builders to say "make NO_SETITIMER=YesPlease" to use a no-op
substitute, as doing so would not affect correctness.

HP NonStop does provide struct itimerval, but other platforms may
not, so this is taken care of in this commit too, by setting
NO_STRUCT_ITIMERVAL.
Signed-off-by: NJoachim Schmitz <jojo@schmitz-digital.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The current code tries to get a list of documented commands
by doing "ls Documentation/git*txt" and culling a bunch of
special cases from the result. Looking for "git-*.txt" would
be more accurate, but would miss a few commands like
"gitweb" and "gitk".

Fortunately, Documentation/Makefile already knows what this
list is, so we can just ask it. Annoyingly, we still have to
post-process its output a little, since make will print
extra cruft like "GIT-VERSION-FILE is up to date" to stdout.

Now that our list is accurate, we can remove all of the ugly
special-cases.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The check-docs target special-cases git-help to avoid
mentioning it as "documented but removed". This dates back
to the early implementation of git-help, when its code was
simply included inside git.c.

These days it is a full-fledged builtin (in builtin/help.c)
and does not need special-casing.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

git-gui is already documented and mentioned in command-list,
but adding it to the Makefile makes sure it is so. We also
add its alias git-citool (which is also documented).

As a result, we can drop them from the special case
statement that avoids them being listed as "documented but
does not exist".
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The check-docs command list is composed from several
Makefile variables plus some special cases. Let's make the
meaning of the list more obvious and avoid repeating
ourselves by factoring it out.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The check-docs target looks at Documentation/git*txt and
complains if any entry does not have a matching command.
Therefore we need to explicitly ignore any entries which are
not meant to describe a command (like gitattributes.txt).
This list has grown stale over time, so let's bring it up to
date.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Like gitk, gitweb is not listed in the usual Makefile
variables and must be fed to check-docs specially. Otherwise
check-docs thinks it is documented but removed.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Now that git_terminal_prompt can cleanly interact with /dev/tty on
Solaris, enable HAVE_DEV_TTY so that this code path is used for
credential reading instead of relying on the crippled getpass().
Signed-off-by: NBen Walton <bwalton@artsci.utoronto.ca>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The Makefile already offers the variable $(FIND) and uses it except in one
place. Fix it.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

While Makefile.PL now finds .pm files on its own, it does not
detect new files after it generates perl/perl.mak.

[ew: commit message, minor tweaks]

ref: http://mid.gmane.org/7vlii51xz4.fsf@alter.siamese.dyndns.orgSigned-off-by: NEric Wong <normalperson@yhbt.net>

Since we have additional shell wrappers (gettextln and eval_gettextln)
for gettext, we need to take into account these wrappers when running
'make pot' to extract messages from shell scripts.
Signed-off-by: NJiang Xin <worldhello.net@gmail.com>
Reviewed-by: NStefano Lattarini <stefano.lattarini@gmail.com>
Reviewed-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

block-sha1/ is fast on most known platforms.  Clarify the Makefile to
be less misleading about that.

Early versions of block-sha1/ explicitly relied on fast htonl() and
fast 32-bit loads with arbitrary alignment.  Now it uses those on some
arches but the default behavior is byte-at-a-time access for the sake
of arches like ARM, Alpha, and their kin and it is still pretty fast
on these arches (fast enough to supersede the mozilla SHA1
implementation and the hand-written ARM assembler implementation that
were bundled before).
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When I invoke "make block-sha1/sha1.s", 'make' runs $(CC) -S without
specifying where it should put its output and the output ends up in
./sha1.s.  Confusing.

Add an -o option to the .s rule to fix this.  We were already doing
that for most compiler invocations but had forgotten it for the
assembler listings.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This provides a reduced but still useful sibling of the Automake's
"automatic Makefile rebuild" feature.  It's important to note that
we take care to enable the new rules only if the tree that has already
be configured with './configure', so that users relying on manual
configuration won't be negatively impacted.
Signed-off-by: NStefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Those filed hold variables, settings and information set by the
configuration process run by './configure'; in Autotools-based
build system that kind of stuff should only be removed by
"make distclean".  Having it removed by "make clean" is not only
inconsistent, but causes real confusion for that part of the Git
audience that is used to the Autotools semantics; for example,
an autotools old-timer that has run:

    ./configure --prefix /opt/git

in the past, without running "make distclean" afterwards, would
expect a "make install" issued after a "make clean" to rebuild and
install git in '/opt/git'; but with the current behaviour, the
"make clean" invocation removes (among the other things) the file
'config.mak.autogen', so that the "make install" falls back to the
default prefix of '$HOME', thus installing git in the user's home
directory -- definitely unexpected.
Signed-off-by: NStefano Lattarini <stefano.lattarini@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When a source file makes use of a makefile variable, there should be a
corresponding dependency on a file that changes when that variable
changes to ensure the build output is not left stale when the variable
changes.

Document this, even though we are not following the rule perfectly
yet.  Based on an explanation from Jeff King.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There is a list of all of the targets which depend on
GIT-VERSION-FILE, but it can be quite far from the actual
point where the targets actually use $(GIT_VERSION). This
can make it hard to verify that each use of $(GIT_VERSION)
has a matching dependency.

This patch moves the dependency closer to the actual build
instructions, which makes verification easier.  This also
fixes the generation of "configure", which did not properly
mark the dependency.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Instaweb would not properly rebuild if the build-time
parameters changed. Fix this by depending on the
GIT-SCRIPT-DEFINES meta-file and using $(cmd_munge_script)
like all the other shell scripts. This requires adding a few
new parametres to cmd_munge_script, but that doesn't hurt
existing scripts.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Currently, running:

  make SHELL_PATH=/bin/bash &&
  make SHELL_PATH=/bin/sh

will not rebuild any shell scripts in the second command,
leading to incorrect results when building from an unclean
working directory.

This patch introduces a new dependency meta-file to notice
the change.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

No shell script actually uses the replacement (it is used in
some perl scripts, but cmd_munge_script only handles shell
scripts). We can also therefore drop the dependency on
GIT-VERSION-FILE.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Most of the build targets do not care about the setting of
$prefix (or its derivative variables), but will be rebuilt
if the prefix changes. For most setups this doesn't matter
(they set prefix once and never change it), but for a setup
which puts each branch or version in its own prefix, this
unnecessarily causes a full rebuild whenever the branc is
changed.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

To avoid noise during builds, unlike the GIT-CFLAGS rule which prints
"* new build flags or prefix" so the operator knows why all files are
being rebuilt when it changes, GIT-USER-AGENT generation is silent.

If this code breaks and a target depending on GIT-USER-AGENT ends up
being rebuilt when it shouldn't be, the full dependency chain can be
retrieved with "make --debug=b".
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The default user-agent depends on the GIT_VERSION, which
means that anytime you switch versions, it causes a full
rebuild. Instead, let's split it out into its own file and
restrict the dependency to version.o.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

No scripts actually care about this replacement. This was
erroneously added by 42dcbb73 (version: add git_user_agent function,
2012-06-02).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When a C file "foo.c" depends on a generated header file, we
note the dependency for the "foo.o" target. However, we
should also note it for other targets that are built from
foo.c, like "foo.sp" and "foo.s". These tend to be missed
because the latter two are not part of the default build,
and are typically built after a regular build which will
generate the header.  Let's be consistent about including
them in dependencies.

This also makes us more consistent with nearby lines which
tack on EXTRA_CPPFLAGS when building certain files.  These
flags may sometimes require extra dependencies to be added
(e.g., like GIT-VERSION-FILE; this is not the case for any
of the updated lines in this patch, but it is establishing a
style that will be used in later patches). Technically the
".sp" and ".s" targets do not care about these dependencies,
because they are force-built (".sp" because it is a phony
target, and ".s" because we explicitly force a rebuild).

Since the blocks in question are about communicating "things
built from foo.c depend on these flags", it frees the reader
from having to know or care more about how those targets are
implemented, and why it is OK for only "foo.o" to depend on
GIT-VERSION-FILE while "foo.sp" and "foo.s" both are
impacted by $(GIT_VERSION). And it helps future-proof us if
those force-build details should ever change.

This patch explicitly does not update the static header
dependencies used when COMPUTED_HEADER_DEPENDENCIES is off.
They are similar to the GIT-VERSION-FILE case above, in that
technically "foo.s" would depend on its included headers,
but it is irrelevant because we force-build it anyway. So it
would be tempting to update them in the same way (for
readability and future-proofing). However, those rules are
meant as a fallback to the computed header dependencies,
which do not handle ".s" and ".sp" at all (and are a much
harder problem to solve, as gcc is the one generating those
dependency lists).

So let's leave that harder problem until (and if) somebody
wants to change the ".sp" and ".s" rules, and keep the
static header dependencies consistent with the computed
ones.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This dependency has been stale since 70827b15 (Split up
builtin commands into separate files from git.c, 2006-04-21).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Just like MISC_H (see previous commit), there is no reason to track
xdiff and vcs-svn headers separately from the rest of the headers.
The only purpose of these variables is to keep track of recompilation
dependencies.

As a pleasant side effect, folding these into LIB_H lets us stop
tracking GIT_OBJS and VCSSVN_TEST_OBJS separately from the list of all
OBJECTS.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Mac OS X mangles file names containing unicode on file systems HFS+,
VFAT or SAMBA.  When a file using unicode code points outside ASCII
is created on a HFS+ drive, the file name is converted into
decomposed unicode and written to disk. No conversion is done if
the file name is already decomposed unicode.

Calling open("\xc3\x84", ...) with a precomposed "Ä" yields the same
result as open("\x41\xcc\x88",...) with a decomposed "Ä".

As a consequence, readdir() returns the file names in decomposed
unicode, even if the user expects precomposed unicode.  Unlike on
HFS+, Mac OS X stores files on a VFAT drive (e.g. an USB drive) in
precomposed unicode, but readdir() still returns file names in
decomposed unicode.  When a git repository is stored on a network
share using SAMBA, file names are send over the wire and written to
disk on the remote system in precomposed unicode, but Mac OS X
readdir() returns decomposed unicode to be compatible with its
behaviour on HFS+ and VFAT.

The unicode decomposition causes many problems:

- The names "git add" and other commands get from the end user may
  often be precomposed form (the decomposed form is not easily input
  from the keyboard), but when the commands read from the filesystem
  to see what it is going to update the index with already is on the
  filesystem, readdir() will give decomposed form, which is different.

- Similarly "git log", "git mv" and all other commands that need to
  compare pathnames found on the command line (often but not always
  precomposed form; a command line input resulting from globbing may
  be in decomposed) with pathnames found in the tree objects (should
  be precomposed form to be compatible with other systems and for
  consistency in general).

- The same for names stored in the index, which should be
  precomposed, that may need to be compared with the names read from
  readdir().

NFS mounted from Linux is fully transparent and does not suffer from
the above.

As Mac OS X treats precomposed and decomposed file names as equal,
we can

 - wrap readdir() on Mac OS X to return the precomposed form, and

 - normalize decomposed form given from the command line also to the
   precomposed form,

to ensure that all pathnames used in Git are always in the
precomposed form.  This behaviour can be requested by setting
"core.precomposedunicode" configuration variable to true.

The code in compat/precomposed_utf8.c implements basically 4 new
functions: precomposed_utf8_opendir(), precomposed_utf8_readdir(),
precomposed_utf8_closedir() and precompose_argv().  The first three
are to wrap opendir(3), readdir(3), and closedir(3) functions.

The argv[] conversion allows to use the TAB filename completion done
by the shell on command line.  It tolerates other tools which use
readdir() to feed decomposed file names into git.

When creating a new git repository with "git init" or "git clone",
"core.precomposedunicode" will be set "false".

The user needs to activate this feature manually.  She typically
sets core.precomposedunicode to "true" on HFS and VFAT, or file
systems mounted via SAMBA.
Helped-by: NJunio C Hamano <gitster@pobox.com>
Signed-off-by: NTorsten Bögershausen <tboegi@web.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The Cygwin implementation of pread() is not thread-safe since, just
like the emulation provided by compat/pread.c, it uses a sequence of
seek-read-seek calls. In order to avoid failues due to thread-safety
issues, commit b038a610 disables threading when NO_PREAD is defined.
(ie when using the emulation code in compat/pread.c).

We introduce a new build variable, NO_THREAD_SAFE_PREAD, which allows
use to disable the threaded index-pack code on cygwin, in addition to
the above NO_PREAD case.
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The credential API is in C, and not available to scripting languages.
Expose the functionalities of the API by wrapping them into a new
plumbing command "git credentials".

In other words, replace the internal "test-credential" by an official Git
command.

Most documentation writen by: Jeff King <peff@peff.net>
Signed-off-by: NPavel Volek <Pavel.Volek@ensimag.imag.fr>
Signed-off-by: NKim Thuat Nguyen <Kim-Thuat.Nguyen@ensimag.imag.fr>
Signed-off-by: NJavier Roucher Iglesias <Javier.Roucher-Iglesias@ensimag.imag.fr>
Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We keep a list of most of the header files in LIB_H, but
some are split out into MISC_H. The original point
of LIB_H was that it would force recompilation of C files
when any of the library headers changed. It was
over-encompassing, since not all C files included all of the
library headers; this made it simple to maintain, but meant
that we sometimes recompiled when it was not necessary.

Over time, some new headers were omitted from LIB_H, and
rules were added to the Makefile for a few specific targets
to explicitly depend on them. This avoided some unnecessary
recompilation at the cost of having to maintain the
dependency list of those targets manually (e.g., d349a03e).

Later, we needed a complete list of headers from which we
should extract strings to localized. Thus 1b8b2e4d introduced
MISC_H to mention all header files not included in LIB_H,
and the concatenation of the two lists is fed to xgettext.
Headers mentioned as dependencies must also be manually
added to MISC_H to receive the benefits of localization.

Having to update multiple locations manually is a pain and
has led to errors. For example, see "git log -Swt-status.h
Makefile" for some back-and-forth between the two locations.
Or the fact that column.h was never added to MISC_H, and
therefore was not localized (which is fixed by this patch).
Moreover, the benefits of keeping these few headers out of
LIB_H is not that great, for two reasons:

  1. The better way to do this is by auto-computing the
     dependencies, which is more accurate and less work to
     maintain. If your compiler supports it, we turn on
     computed header dependencies by default these days. So
     these manual dependencies are used only for people who
     do not have gcc at all (which increases the chance of
     them becoming stale, as many developers will never even
     use them).

  2. Even if you do not have gcc, the manual header
     dependencies do not help all that much.  They obviously
     cannot help with an initial compilation (since their
     purpose is to avoid unnecessary recompilation when a
     header changes), which means they are only useful when
     building a new version of git in the working tree that
     held an existing build (e.g., after checkout or during a
     bisection). But since a change of a header in LIB_H
     will force recompilation, and given that the vast
     majority of headers are in LIB_H, most version changes
     will result in a full rebuild anyway.

Let's just fold MISC_H into LIB_H and get rid of these
manual rules. The worst case is some extra compilation, but
even that is unlikely to matter due to the reasons above.

The one exception is that we should keep common-cmds.h
separate. Because it is generated, the computed dependencies
do not handle it properly, and we must keep separate
individual dependencies on it. Let's therefore rename MISC_H
to GENERATED_H to make it more clear what should go in it.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This was mostly sorted already, but put things like
"cache-tree.h" after "cache.h", even though "-" comes before
"." (at least in the C locale). This will make it easier to
keep the list sorted later by piping it through "sort".
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When 'git help $cmd' is run without a format option (e.g. -w), the
'man' format is always used. On some platforms, however, manual page
viewers are not often available.

Introduce DEFAULT_HELP_FORMAT make variable in order to allow the
default format configurable at compile time, and set it to HTML when
compiling on Windows (but not Cygwin).
Helped-by: NJeff King <peff@peff.net>
Signed-off-by: NVincent van Ravesteijn <vfr@lyx.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This means we will respect the GIT_USER_AGENT build-time
configuration and run-time environment variable.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>