Commit a469a101 wraps some error calls in macros to give the
compiler a chance to do more static analysis on their
constant -1 return value.  We limit the use of these macros
to __GNUC__, since gcc is the primary beneficiary of the new
information, and because we use GNU features for handling
variadic macros.

However, clang also defines __GNUC__, but generates warnings
with -Wunused-value when these macros are used in a void
context, because the constant "-1" ends up being useless.
Gcc does not complain about this case (though it is unclear
if it is because it is smart enough to see what we are
doing, or too dumb to realize that the -1 is unused).  We
can squelch the warning by just disabling these macros when
clang is in use.
Signed-off-by: NMax Horn <max@quendi.de>
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When git is compiled with "gcc -Wuninitialized -O3", some
inlined calls provide an additional opportunity for the
compiler to do static analysis on variable initialization.
For example, with two functions like this:

  int get_foo(int *foo)
  {
	if (something_that_might_fail() < 0)
		return error("unable to get foo");
	*foo = 0;
	return 0;
  }

  void some_fun(void)
  {
	  int foo;
	  if (get_foo(&foo) < 0)
		  return -1;
	  printf("foo is %d\n", foo);
  }

If get_foo() is not inlined, then when compiling some_fun,
gcc sees only that a pointer to the local variable is
passed, and must assume that it is an out parameter that
is initialized after get_foo returns.

However, when get_foo() is inlined, the compiler may look at
all of the code together and see that some code paths in
get_foo() do not initialize the variable. As a result, it
prints a warning. But what the compiler can't see is that
error() always returns -1, and therefore we know that either
we return early from some_fun, or foo ends up initialized,
and the code is safe.  The warning is a false positive.

If we can make the compiler aware that error() will always
return -1, it can do a better job of analysis. The simplest
method would be to inline the error() function. However,
this doesn't work, because gcc will not inline a variadc
function. We can work around this by defining a macro. This
relies on two gcc extensions:

  1. Variadic macros (these are present in C99, but we do
     not rely on that).

  2. Gcc treats the "##" paste operator specially between a
     comma and __VA_ARGS__, which lets our variadic macro
     work even if no format parameters are passed to
     error().

Since we are using these extra features, we hide the macro
behind an #ifdef. This is OK, though, because our goal was
just to help gcc.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

RFC 2047 requires more characters to be encoded than it is currently done.
Especially, RFC 2047 distinguishes between allowed remaining characters
in encoded words in addresses (From, To, etc.) and other headers, such
as Subject.

Make add_rfc2047() and is_rfc2047_special() location dependent and include
all non-allowed characters to hopefully be RFC 2047 conformant.

This especially fixes a problem, where RFC 822 specials (e. g. ".") were
left unencoded in addresses, which was solved with a non-standard-conforming
workaround in the past (which is going to be removed in a follow-up patch).
Signed-off-by: NJan H. Schönherr <schnhrr@cs.tu-berlin.de>
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>

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>

Introduce a compatibility helper for platforms with such a mkdir().
Signed-off-by: NJoachim Schmitz <jojo@schmitz-digital.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The previous series introduced warnings to multiple places, but it
could become tiring to see the warning on the same path over and
over again during a single run of Git.  Making just one function
responsible for issuing this warning, we could later choose to keep
track of which paths we issued a warning (it would involve a hash
table of paths after running them through real_path() or something)
in order to reduce noise.

Right now we do not know if the noise reduction is necessary, but it
still would be a good code reduction/sharing anyway.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Before reading a config file, we check "!access(path, R_OK)"
to make sure that the file exists and is readable. If it's
not, then we silently ignore it.

For the case of ENOENT, this is fine, as the presence of the
file is optional. For other cases, though, it may indicate a
configuration error (e.g., not having permissions to read
the file). Let's print a warning in these cases to let the
user know.
Signed-off-by: NJeff King <peff@peff.net>
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>

When getpwuid fails, we give a cute but cryptic message.
While it makes sense if you know that getpwuid or identity
functions are being called, this code is triggered behind
the scenes by quite a few git commands these days (e.g.,
receive-pack on a remote server might use it for a reflog;
the current message is hard to distinguish from an
authentication error).  Let's switch to something that gives
a little more context.

While we're at it, we can factor out all of the
cut-and-pastes of the "you don't exist" message into a
wrapper function. Rather than provide xgetpwuid, let's make
it even more specific to just getting the passwd entry for
the current uid. That's the only way we use getpwuid anyway,
and it lets us make an even more specific error message.

The current message also fails to mention errno. While the
usual cause for getpwuid failing is that the user does not
exist, mentioning errno makes it easier to diagnose these
problems.  Note that POSIX specifies that errno remain
untouched if the passwd entry does not exist (but will be
set on actual errors), whereas some systems will return
ENOENT or similar for a missing entry. We handle both cases
in our wrapper.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In particular, sparse complains as follows:

        SP ctype.c
    ctype.c:30:12: warning: symbol 'tolower_trans_tbl' was not declared.\
         Should it be static?

An appropriate extern declaration for the 'tolower_trans_tbl' symbol
is included in the "cache.h" header file. In order to suppress the
warning, therefore, we could replace the "git-compat-util.h" header
inclusion with "cache.h", since "cache.h" includes "git-compat-util.h"
in turn. Here, however, we choose to move the extern declaration for
'tolower_trans_tbl' into "git-compat-util.h", alongside the other
extern declaration from ctype.c for 'sane_ctype'.
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

"perf" uses a the forked copy of this file, and wants to use these two
macros.
Signed-off-by: NNamhyung Kim <namhyung.kim@lge.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If you access repositories over smart-http using http
authentication, then it can be annoying to have git ask you
for your password repeatedly. We cache credentials in
memory, of course, but git is composed of many small
programs. Having to input your password for each one can be
frustrating.

This patch introduces a credential helper that will cache
passwords in memory for a short period of time.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Suggested-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NRamkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The previous one introduced an implementation of the function, but forgot
to add a declaration.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Do not include header files when compiling with MSVC that do not
exist and which are also not included when compiling with MINGW.
A direct consequence is that git can be compiled again with MSVC
because the missing "sys/resources.h" is no longer included.

Instead of current

	#ifndef mingw32 is the only one that is strange
        ... everything for systems that is not strange ...
        #else
        ... include mingw specific tweaks ...
        #endif
        #ifdef msvc is also strange
        ... include msvc specific tweaks ...
        #endif

it turns things around and says what it wants to achieve in a more direct
way, i.e.

	#if mingw32
        #include "compat/mingw.h"
	#elif msvc
        #include "compat/msvc.h"
	#else
        ... all the others ...
	#endif

which makes it a lot simpler.
Signed-off-by: NVincent van Ravesteijn <vfr@lyx.org>
Helped-by: NJunio C Hamano <gitster@pobox.com>
Acked-by: NErik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The new process's error output may be redirected elsewhere, but if
the exec fails, output should still go to the parent's stderr. This
has already been done for the die_routine. Do the same for
error_routine.
Signed-off-by: NClemens Buchacher <drizzd@aon.at>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Due to a bug in gcc 4.6+ it can crash when doing profile feedback
with a noreturn function pointer

(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49299)

This adds a Makefile variable to disable noreturns.

[Patch by Junio, description by Andi Kleen]
Signed-off-by: NAndi Kleen <ak@linux.intel.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

real_path currently assumes it's input had '/' as path seperator.
This assumption does not hold true for the code-path from
prefix_path (on Windows), where real_path can be called before
normalize_path_copy.

Fix real_path so it doesn't make this assumption. Create a helper
function to reverse-search for the last path-seperator in a string.
Signed-off-by: NTheo Niessink <theo@taletn.com>
Signed-off-by: NErik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The earlier design was to take whatever non-alnum that the short format
parser happens to support, leaving the rest as part of the pattern, so a
version of git that knows '*' magic and a version that does not would have
behaved differently when given ":*Makefile".  The former would have
applied the '*' magic to the pattern "Makefile", while the latter would
used no magic to the pattern "*Makefile".

Instead, just reserve all non-alnum ASCII letters that are neither glob
nor regexp special as potential magic signature, and when we see a magic
that is not supported, die with an error message, just like the longhand
codepath does.

With this, ":%#!*Makefile" will always mean "%#!" magic applied to the
pattern "*Makefile", no matter what version of git is used (it is a
different matter if the version of git supports all of these three magic
matching rules).

Also make ':' without anything else to mean "there is no pathspec".  This
would allow differences between "git log" and "git log ." run from the top
level of the working tree (the latter simplifies no-op commits away from
the history) to be expressed from a subdirectory by saying "git log :".
Helped-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Starting with commit c7934306 (Limit file descriptors used by packs,
2011-02-28), git uses getrlimit to tell how many file descriptors it
can use.  Unfortunately it does not include the header declaring that
function, resulting in compilation errors:

 sha1_file.c: In function 'open_packed_git_1':
 sha1_file.c:718: error: storage size of 'lim' isn't known
 sha1_file.c:721: warning: implicit declaration of function 'getrlimit'
 sha1_file.c:721: error: 'RLIMIT_NOFILE' undeclared (first use in this function)
 sha1_file.c:718: warning: unused variable 'lim'

The standard header to include for this is <sys/resource.h> (which on
some systems itself requires declarations from <sys/types.h> or
<sys/time.h>).  Probably the problem was missed until now because in
current glibc sys/resource.h happens to be included by sys/wait.h.

MinGW does not provide sys/resource.h (and compat/mingw takes care of
providing getrlimit some other way), so add the missing #include to
the "#ifndef __MINGW32__" block in git-compat-util.h.
Reported-by: NStefan Sperling <stsp@stsp.name>
Tested-by: Stefan Sperling <stsp@stsp.name> [on OpenBSD]
Tested-by: Arnaud Lacombe <lacombar@gmail.com> [on FreeBSD 8]
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Since an obvious implementation of va_list is to make it a pointer
into the stack frame, implementing va_copy as "dst = src" will work on
many systems.  Platforms that use something different (e.g., a size-1
array of structs, to be assigned with *(dst) = *(src)) will need some
other compatibility macro, though.

Luckily, as the glibc manual hints, such systems tend to provide the
__va_copy macro (introduced in GCC in March, 1997).  By using that if
it is available, we can cover our bases pretty well.

Discovered by building with CC="gcc -std=c89" on an amd64 machine:

 $ make CC=c89 strbuf.o
 [...]
 strbuf.c: In function 'strbuf_vaddf':
 strbuf.c:211:2: error: incompatible types when assigning to type 'va_list'
  from type 'struct __va_list_tag *'
 make: *** [strbuf.o] Error 1
Explained-by: NJunio C Hamano <gitster@pobox.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

HP C for Integrity servers (Itanium) gained support for noreturn
attribute sometime in 2006. It was released in Compiler Version
A.06.10 and made available in July 2006.

The __HP_cc define detects the HP C compiler version.  Precede the
__GNUC__ check so it works well when compiling with HP C using -Agcc
option that enables partial support for the GNU C dialect. The -Agcc
defines the __GNUC__ too.
Signed-off-by: NMichal Rokos <michal.rokos@nextsoft.cz>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

va_copy is C99.  We have avoided using va_copy many times in the past,
which has led to a bunch of cut-and-paste.  From everything I found
searching the web, implementations have historically either provided
va_copy or just let your code assume that simple assignment of worked.

So my guess is that this will be sufficient, though we won't really
know for sure until somebody reports a problem.
Signed-off-by: NJeff King <peff@peff.net>
Improved-by: NErik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The idiom (a + b < a) works fine for detecting that an unsigned
integer has overflowed, but a more explicit

	unsigned_add_overflows(a, b)

might be easier to read.

Define such a macro, expanding roughly to ((a) < UINT_MAX - (b)).
Because the expansion uses each argument only once outside of sizeof()
expressions, it is safe to use with arguments that have side effects.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The odb_mkstemp and odb_pack_keep functions open files under the
$GIT_OBJECT_DIRECTORY directory.  This requires access to the git
configuration which very simple programs do not need.

Move these functions to environment.o, closer to their dependencies.
This should make it easier for programs to link to wrapper.o without
linking to environment.o.
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NErik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Windows doesn't have inet_pton and inet_ntop, so
add prototypes in git-compat-util.h for them.

At the same time include git-compat-util.h in
the sources for these functions, so they use the
network-wrappers from there on Windows.
Signed-off-by: NMike Pape <dotzenlabs@gmail.com>
Signed-off-by: NErik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Syslog does not usually exist on Windows, so implement our own using
Window's ReportEvent mechanism.

Strings containing "%1" gets expanded into them selves by ReportEvent,
resulting in an unreadable string. "%2" and above is not a problem.
Unfortunately, on Windows an IPv6 address can contain "%1", so expand
"%1" to "% 1" before reporting. "%%1" is also a problem for ReportEvent,
but that string cannot occur in an IPv6 address.
Signed-off-by: NMike Pape <dotzenlabs@gmail.com>
Signed-off-by: NErik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* add required build options to Makefile.
* introduce new NO_INTTYPES_H for systems lacking inttypes; code
  includes stdint.h instead, if this is set.
* introduce new NO_SYS_POLL_H for systems lacking sys/poll.h; code
  includes poll.h instead, if this is set.
* introduce NO_INITGROUPS. initgroups() call is simply omitted.
Signed-off-by: NMarkus Duft <mduft@gentoo.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed integer overflow is not defined in C, so do not depend on it.

This fixes a problem with GCC 4.4.0 and -O3 where the optimizer would
consider "consumed_bytes > consumed_bytes + bytes" as a constant
expression, and never execute the die()-call.
Signed-off-by: NErik Faye-Lund <kusmabite@gmail.com>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

In particular, on systems that define uint32_t as an unsigned long,
gcc complains as follows:

      CC vcs-svn/fast_export.o
  vcs-svn/fast_export.c: In function `fast_export_modify':
  vcs-svn/fast_export.c:28: warning: unsigned int format, uint32_t arg (arg 2)
  vcs-svn/fast_export.c:28: warning: int format, uint32_t arg (arg 3)
  vcs-svn/fast_export.c: In function `fast_export_commit':
  vcs-svn/fast_export.c:42: warning: int format, uint32_t arg (arg 5)
  vcs-svn/fast_export.c:62: warning: int format, uint32_t arg (arg 2)
  vcs-svn/fast_export.c: In function `fast_export_blob':
  vcs-svn/fast_export.c:72: warning: int format, uint32_t arg (arg 2)
  vcs-svn/fast_export.c:72: warning: int format, uint32_t arg (arg 3)
      CC vcs-svn/svndump.o
  vcs-svn/svndump.c: In function `svndump_read':
  vcs-svn/svndump.c:260: warning: int format, uint32_t arg (arg 3)

In order to suppress the warnings we use the C99 format specifier
macros PRIo32 and PRIu32 from <inttypes.h>.
Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Windows does not have strtok_r (and while it does have an identical
strtok_s, but it is not obvious how to use it).  Grab an
implementation from glibc.

The svn-fe tool uses strtok_r to parse paths.
Acked-by: NJohannes Sixt <j6t@kdbg.org>
Helped-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJonathan Nieder <jrnieder@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Attempting to mmap (via git-add or similar) a file larger than 4GB on
32-bit Linux systems results in a repository that has only the file
modulo 4GB stored, because of truncation of the off_t file size to a
size_t for mmap.

When xsize_t was introduced to handle this truncation in dc49cd76 (Cast
64 bit off_t to 32 bit size_t, 2007-03-06), Shawn even pointed out
that it should detect when such a cutoff happens.

Make it so.
Signed-off-by: NThomas Rast <trast@student.ethz.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

IRIX 6.5.26m does not define the 'sgi' macro, but it does define an '__sgi'
macro.  Since later IRIX versions (6.5.29m) define both macros, and since
an underscore prefixed macro is preferred anyway, use '__sgi' to detect
compilation on SGI IRIX.
Signed-off-by: NBrandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: NGary V. Vaughan <gary@thewrittenword.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some platforms with mmap() lack MAP_FAILED definition.
Signed-off-by: NGary V. Vaughan <gary@thewrittenword.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This effectively requires from the callers of set_try_to_free_routine to
treat the try-to-free-routines as a stack.

We will need this for the next patch where the only current caller cannot
depend on that the previously set routine was the default routine.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The default executable path list used by exec_cmd.c is hard-coded to
be "/usr/local/bin:/usr/bin:/bin".  Use an appropriate value for the
system from <paths.h> when available.

Add HAVE_PATHS_H make variables and enable it on Linux, FreeBSD,
NetBSD, OpenBSD and GNU where it is known to exist for now. Somebody
else may want to do an autoconf support later.
Signed-off-by: NChris Webb <chris@arachsys.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

As on FreeBSD, defining _XOPEN_SOURCE to 600 on DragonFly BSD 2.4-RELEASE
or later hides symbols from programs, which leads to implicit declaration
of functions, making the return value to be assumed an int.  On architectures
where sizeof(int) < sizeof(void *), this can cause unexpected behaviors or
crashes.
This change won't affect other OSes unless they define __DragonFly__ macro,
or older versions of DragonFly BSD as the current git code doesn't rely on
the features only available with _XOPEN_SOURCE set to 600 on DragonFly.
Signed-off-by: NYONETANI Tomokazu <y0netan1@dragonflybsd.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This patch introduces the remove_or_warn function which is a
generalised version of the {unlink,rmdir}_or_warn functions.  It takes
an additional parameter indicating the mode of the file to be removed.

The patch also modifies certain functions to use remove_or_warn
where appropriate, and adds a test case for a bug fixed by the use
of remove_or_warn.
Signed-off-by: NPeter Collingbourne <peter@pcc.me.uk>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>