2008-05-20 06:48:54 +00:00
|
|
|
#include "cache.h"
|
2012-10-28 16:16:24 +00:00
|
|
|
#include "string-list.h"
|
2008-05-20 06:48:54 +00:00
|
|
|
|
2012-10-28 16:16:25 +00:00
|
|
|
/*
|
|
|
|
* A "string_list_each_func_t" function that normalizes an entry from
|
|
|
|
* GIT_CEILING_DIRECTORIES. If the path is unusable for some reason,
|
|
|
|
* die with an explanation.
|
|
|
|
*/
|
|
|
|
static int normalize_ceiling_entry(struct string_list_item *item, void *unused)
|
|
|
|
{
|
2016-02-22 22:44:54 +00:00
|
|
|
char *ceil = item->string;
|
2012-10-28 16:16:25 +00:00
|
|
|
|
2016-02-22 22:44:54 +00:00
|
|
|
if (!*ceil)
|
2012-10-28 16:16:25 +00:00
|
|
|
die("Empty path is not supported");
|
|
|
|
if (!is_absolute_path(ceil))
|
|
|
|
die("Path \"%s\" is not absolute", ceil);
|
2016-02-22 22:44:54 +00:00
|
|
|
if (normalize_path_copy(ceil, ceil) < 0)
|
2012-10-28 16:16:25 +00:00
|
|
|
die("Path \"%s\" could not be normalized", ceil);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2013-06-25 15:53:42 +00:00
|
|
|
static void normalize_argv_string(const char **var, const char *input)
|
|
|
|
{
|
|
|
|
if (!strcmp(input, "<null>"))
|
|
|
|
*var = NULL;
|
|
|
|
else if (!strcmp(input, "<empty>"))
|
|
|
|
*var = "";
|
|
|
|
else
|
|
|
|
*var = input;
|
|
|
|
|
|
|
|
if (*var && (**var == '<' || **var == '('))
|
|
|
|
die("Bad value: %s\n", input);
|
|
|
|
}
|
|
|
|
|
2016-01-12 07:57:57 +00:00
|
|
|
struct test_data {
|
|
|
|
const char *from; /* input: transform from this ... */
|
|
|
|
const char *to; /* output: ... to this. */
|
t0060: loosen overly strict expectations
The dirname() tests file were developed and tested on only the five
platforms available to the developer at the time, namely: Linux (both 32
and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
(i.e. the POSIX spec) says, in part:
If the string pointed to by path consists entirely of the '/'
character, basename() shall return a pointer to the string "/".
If the string pointed to by path is exactly "//", it is
implementation-defined whether "/" or "//" is returned.
The thinking behind testing precise, OS-dependent output values was to
document that different setups produce different values. However, as the
test failures on MacOSX illustrated eloquently: hardcoding pretty much each
and every setup's expectations is pretty fragile.
This is not limited to the "//" vs "/" case, of course, other inputs are
also allowed to produce multiple outputs by the POSIX specs.
So let's just test for all allowed values and be done with it. This still
documents that Git cannot rely on one particular output value in those
cases, so the intention of the original tests is still met.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-14 06:48:27 +00:00
|
|
|
const char *alternative; /* output: ... or this. */
|
2016-01-12 07:57:57 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static int test_function(struct test_data *data, char *(*func)(char *input),
|
|
|
|
const char *funcname)
|
|
|
|
{
|
|
|
|
int failed = 0, i;
|
|
|
|
char buffer[1024];
|
|
|
|
char *to;
|
|
|
|
|
|
|
|
for (i = 0; data[i].to; i++) {
|
|
|
|
if (!data[i].from)
|
|
|
|
to = func(NULL);
|
|
|
|
else {
|
2016-02-08 22:21:55 +00:00
|
|
|
xsnprintf(buffer, sizeof(buffer), "%s", data[i].from);
|
2016-01-12 07:57:57 +00:00
|
|
|
to = func(buffer);
|
|
|
|
}
|
t0060: loosen overly strict expectations
The dirname() tests file were developed and tested on only the five
platforms available to the developer at the time, namely: Linux (both 32
and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
(i.e. the POSIX spec) says, in part:
If the string pointed to by path consists entirely of the '/'
character, basename() shall return a pointer to the string "/".
If the string pointed to by path is exactly "//", it is
implementation-defined whether "/" or "//" is returned.
The thinking behind testing precise, OS-dependent output values was to
document that different setups produce different values. However, as the
test failures on MacOSX illustrated eloquently: hardcoding pretty much each
and every setup's expectations is pretty fragile.
This is not limited to the "//" vs "/" case, of course, other inputs are
also allowed to produce multiple outputs by the POSIX specs.
So let's just test for all allowed values and be done with it. This still
documents that Git cannot rely on one particular output value in those
cases, so the intention of the original tests is still met.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-14 06:48:27 +00:00
|
|
|
if (!strcmp(to, data[i].to))
|
|
|
|
continue;
|
|
|
|
if (!data[i].alternative)
|
2016-01-12 07:57:57 +00:00
|
|
|
error("FAIL: %s(%s) => '%s' != '%s'\n",
|
|
|
|
funcname, data[i].from, to, data[i].to);
|
t0060: loosen overly strict expectations
The dirname() tests file were developed and tested on only the five
platforms available to the developer at the time, namely: Linux (both 32
and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
(i.e. the POSIX spec) says, in part:
If the string pointed to by path consists entirely of the '/'
character, basename() shall return a pointer to the string "/".
If the string pointed to by path is exactly "//", it is
implementation-defined whether "/" or "//" is returned.
The thinking behind testing precise, OS-dependent output values was to
document that different setups produce different values. However, as the
test failures on MacOSX illustrated eloquently: hardcoding pretty much each
and every setup's expectations is pretty fragile.
This is not limited to the "//" vs "/" case, of course, other inputs are
also allowed to produce multiple outputs by the POSIX specs.
So let's just test for all allowed values and be done with it. This still
documents that Git cannot rely on one particular output value in those
cases, so the intention of the original tests is still met.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-14 06:48:27 +00:00
|
|
|
else if (!strcmp(to, data[i].alternative))
|
|
|
|
continue;
|
|
|
|
else
|
|
|
|
error("FAIL: %s(%s) => '%s' != '%s', '%s'\n",
|
|
|
|
funcname, data[i].from, to, data[i].to,
|
|
|
|
data[i].alternative);
|
|
|
|
failed = 1;
|
2016-01-12 07:57:57 +00:00
|
|
|
}
|
|
|
|
return failed;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct test_data basename_data[] = {
|
|
|
|
/* --- POSIX type paths --- */
|
|
|
|
{ NULL, "." },
|
|
|
|
{ "", "." },
|
|
|
|
{ ".", "." },
|
|
|
|
{ "..", ".." },
|
|
|
|
{ "/", "/" },
|
t0060: loosen overly strict expectations
The dirname() tests file were developed and tested on only the five
platforms available to the developer at the time, namely: Linux (both 32
and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
(i.e. the POSIX spec) says, in part:
If the string pointed to by path consists entirely of the '/'
character, basename() shall return a pointer to the string "/".
If the string pointed to by path is exactly "//", it is
implementation-defined whether "/" or "//" is returned.
The thinking behind testing precise, OS-dependent output values was to
document that different setups produce different values. However, as the
test failures on MacOSX illustrated eloquently: hardcoding pretty much each
and every setup's expectations is pretty fragile.
This is not limited to the "//" vs "/" case, of course, other inputs are
also allowed to produce multiple outputs by the POSIX specs.
So let's just test for all allowed values and be done with it. This still
documents that Git cannot rely on one particular output value in those
cases, so the intention of the original tests is still met.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-14 06:48:27 +00:00
|
|
|
{ "//", "/", "//" },
|
|
|
|
{ "///", "/", "//" },
|
|
|
|
{ "////", "/", "//" },
|
2016-01-12 07:57:57 +00:00
|
|
|
{ "usr", "usr" },
|
|
|
|
{ "/usr", "usr" },
|
|
|
|
{ "/usr/", "usr" },
|
|
|
|
{ "/usr//", "usr" },
|
|
|
|
{ "/usr/lib", "lib" },
|
|
|
|
{ "usr/lib", "lib" },
|
|
|
|
{ "usr/lib///", "lib" },
|
|
|
|
|
|
|
|
#if defined(__MINGW32__) || defined(_MSC_VER)
|
|
|
|
/* --- win32 type paths --- */
|
|
|
|
{ "\\usr", "usr" },
|
|
|
|
{ "\\usr\\", "usr" },
|
|
|
|
{ "\\usr\\\\", "usr" },
|
|
|
|
{ "\\usr\\lib", "lib" },
|
|
|
|
{ "usr\\lib", "lib" },
|
|
|
|
{ "usr\\lib\\\\\\", "lib" },
|
|
|
|
{ "C:/usr", "usr" },
|
|
|
|
{ "C:/usr", "usr" },
|
|
|
|
{ "C:/usr/", "usr" },
|
|
|
|
{ "C:/usr//", "usr" },
|
|
|
|
{ "C:/usr/lib", "lib" },
|
|
|
|
{ "C:usr/lib", "lib" },
|
|
|
|
{ "C:usr/lib///", "lib" },
|
|
|
|
{ "C:", "." },
|
|
|
|
{ "C:a", "a" },
|
|
|
|
{ "C:/", "/" },
|
|
|
|
{ "C:///", "/" },
|
t0060: loosen overly strict expectations
The dirname() tests file were developed and tested on only the five
platforms available to the developer at the time, namely: Linux (both 32
and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
(i.e. the POSIX spec) says, in part:
If the string pointed to by path consists entirely of the '/'
character, basename() shall return a pointer to the string "/".
If the string pointed to by path is exactly "//", it is
implementation-defined whether "/" or "//" is returned.
The thinking behind testing precise, OS-dependent output values was to
document that different setups produce different values. However, as the
test failures on MacOSX illustrated eloquently: hardcoding pretty much each
and every setup's expectations is pretty fragile.
This is not limited to the "//" vs "/" case, of course, other inputs are
also allowed to produce multiple outputs by the POSIX specs.
So let's just test for all allowed values and be done with it. This still
documents that Git cannot rely on one particular output value in those
cases, so the intention of the original tests is still met.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-14 06:48:27 +00:00
|
|
|
{ "\\", "\\", "/" },
|
|
|
|
{ "\\\\", "\\", "/" },
|
|
|
|
{ "\\\\\\", "\\", "/" },
|
2016-01-12 07:57:57 +00:00
|
|
|
#endif
|
|
|
|
{ NULL, NULL }
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct test_data dirname_data[] = {
|
|
|
|
/* --- POSIX type paths --- */
|
|
|
|
{ NULL, "." },
|
|
|
|
{ "", "." },
|
|
|
|
{ ".", "." },
|
|
|
|
{ "..", "." },
|
|
|
|
{ "/", "/" },
|
t0060: loosen overly strict expectations
The dirname() tests file were developed and tested on only the five
platforms available to the developer at the time, namely: Linux (both 32
and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
(i.e. the POSIX spec) says, in part:
If the string pointed to by path consists entirely of the '/'
character, basename() shall return a pointer to the string "/".
If the string pointed to by path is exactly "//", it is
implementation-defined whether "/" or "//" is returned.
The thinking behind testing precise, OS-dependent output values was to
document that different setups produce different values. However, as the
test failures on MacOSX illustrated eloquently: hardcoding pretty much each
and every setup's expectations is pretty fragile.
This is not limited to the "//" vs "/" case, of course, other inputs are
also allowed to produce multiple outputs by the POSIX specs.
So let's just test for all allowed values and be done with it. This still
documents that Git cannot rely on one particular output value in those
cases, so the intention of the original tests is still met.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-14 06:48:27 +00:00
|
|
|
{ "//", "/", "//" },
|
|
|
|
{ "///", "/", "//" },
|
|
|
|
{ "////", "/", "//" },
|
2016-01-12 07:57:57 +00:00
|
|
|
{ "usr", "." },
|
|
|
|
{ "/usr", "/" },
|
|
|
|
{ "/usr/", "/" },
|
|
|
|
{ "/usr//", "/" },
|
|
|
|
{ "/usr/lib", "/usr" },
|
|
|
|
{ "usr/lib", "usr" },
|
|
|
|
{ "usr/lib///", "usr" },
|
|
|
|
|
|
|
|
#if defined(__MINGW32__) || defined(_MSC_VER)
|
|
|
|
/* --- win32 type paths --- */
|
|
|
|
{ "\\", "\\" },
|
|
|
|
{ "\\\\", "\\\\" },
|
|
|
|
{ "\\usr", "\\" },
|
|
|
|
{ "\\usr\\", "\\" },
|
|
|
|
{ "\\usr\\\\", "\\" },
|
|
|
|
{ "\\usr\\lib", "\\usr" },
|
|
|
|
{ "usr\\lib", "usr" },
|
|
|
|
{ "usr\\lib\\\\\\", "usr" },
|
|
|
|
{ "C:a", "C:." },
|
|
|
|
{ "C:/", "C:/" },
|
|
|
|
{ "C:///", "C:/" },
|
|
|
|
{ "C:/usr", "C:/" },
|
|
|
|
{ "C:/usr/", "C:/" },
|
|
|
|
{ "C:/usr//", "C:/" },
|
|
|
|
{ "C:/usr/lib", "C:/usr" },
|
|
|
|
{ "C:usr/lib", "C:usr" },
|
|
|
|
{ "C:usr/lib///", "C:usr" },
|
|
|
|
{ "\\\\\\", "\\" },
|
|
|
|
{ "\\\\\\\\", "\\" },
|
t0060: loosen overly strict expectations
The dirname() tests file were developed and tested on only the five
platforms available to the developer at the time, namely: Linux (both 32
and 64bit), Windows XP 32-bit (MSVC), MinGW 32-bit and Cygwin 32-bit.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/basename.html
(i.e. the POSIX spec) says, in part:
If the string pointed to by path consists entirely of the '/'
character, basename() shall return a pointer to the string "/".
If the string pointed to by path is exactly "//", it is
implementation-defined whether "/" or "//" is returned.
The thinking behind testing precise, OS-dependent output values was to
document that different setups produce different values. However, as the
test failures on MacOSX illustrated eloquently: hardcoding pretty much each
and every setup's expectations is pretty fragile.
This is not limited to the "//" vs "/" case, of course, other inputs are
also allowed to produce multiple outputs by the POSIX specs.
So let's just test for all allowed values and be done with it. This still
documents that Git cannot rely on one particular output value in those
cases, so the intention of the original tests is still met.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-01-14 06:48:27 +00:00
|
|
|
{ "C:", "C:.", "." },
|
2016-01-12 07:57:57 +00:00
|
|
|
#endif
|
|
|
|
{ NULL, NULL }
|
|
|
|
};
|
|
|
|
|
add an extra level of indirection to main()
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-07-01 05:58:58 +00:00
|
|
|
int cmd_main(int argc, const char **argv)
|
2008-05-20 06:48:54 +00:00
|
|
|
{
|
2009-02-07 15:08:30 +00:00
|
|
|
if (argc == 3 && !strcmp(argv[1], "normalize_path_copy")) {
|
2016-02-22 22:44:54 +00:00
|
|
|
char *buf = xmallocz(strlen(argv[2]));
|
2009-02-07 15:08:30 +00:00
|
|
|
int rv = normalize_path_copy(buf, argv[2]);
|
|
|
|
if (rv)
|
|
|
|
buf = "++failed++";
|
2008-05-20 06:48:54 +00:00
|
|
|
puts(buf);
|
2009-02-07 15:08:27 +00:00
|
|
|
return 0;
|
2008-05-20 06:48:54 +00:00
|
|
|
}
|
|
|
|
|
2011-03-17 11:26:46 +00:00
|
|
|
if (argc >= 2 && !strcmp(argv[1], "real_path")) {
|
2008-05-20 06:49:00 +00:00
|
|
|
while (argc > 2) {
|
2011-03-17 11:26:46 +00:00
|
|
|
puts(real_path(argv[2]));
|
2008-05-20 06:49:00 +00:00
|
|
|
argc--;
|
|
|
|
argv++;
|
|
|
|
}
|
2009-02-07 15:08:27 +00:00
|
|
|
return 0;
|
2008-05-20 06:49:00 +00:00
|
|
|
}
|
|
|
|
|
2011-08-04 04:47:47 +00:00
|
|
|
if (argc >= 2 && !strcmp(argv[1], "absolute_path")) {
|
|
|
|
while (argc > 2) {
|
|
|
|
puts(absolute_path(argv[2]));
|
|
|
|
argc--;
|
|
|
|
argv++;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2008-05-20 06:49:26 +00:00
|
|
|
if (argc == 4 && !strcmp(argv[1], "longest_ancestor_length")) {
|
2012-10-28 16:16:24 +00:00
|
|
|
int len;
|
|
|
|
struct string_list ceiling_dirs = STRING_LIST_INIT_DUP;
|
2012-10-28 16:16:25 +00:00
|
|
|
char *path = xstrdup(argv[2]);
|
2012-10-28 16:16:24 +00:00
|
|
|
|
2012-10-28 16:16:25 +00:00
|
|
|
/*
|
|
|
|
* We have to normalize the arguments because under
|
|
|
|
* Windows, bash mangles arguments that look like
|
|
|
|
* absolute POSIX paths or colon-separate lists of
|
|
|
|
* absolute POSIX paths into DOS paths (e.g.,
|
|
|
|
* "/foo:/foo/bar" might be converted to
|
|
|
|
* "D:\Src\msysgit\foo;D:\Src\msysgit\foo\bar"),
|
|
|
|
* whereas longest_ancestor_length() requires paths
|
|
|
|
* that use forward slashes.
|
|
|
|
*/
|
|
|
|
if (normalize_path_copy(path, path))
|
|
|
|
die("Path \"%s\" could not be normalized", argv[2]);
|
2012-10-28 16:16:24 +00:00
|
|
|
string_list_split(&ceiling_dirs, argv[3], PATH_SEP, -1);
|
2012-10-28 16:16:25 +00:00
|
|
|
filter_string_list(&ceiling_dirs, 0,
|
|
|
|
normalize_ceiling_entry, NULL);
|
|
|
|
len = longest_ancestor_length(path, &ceiling_dirs);
|
2012-10-28 16:16:24 +00:00
|
|
|
string_list_clear(&ceiling_dirs, 0);
|
2012-10-28 16:16:25 +00:00
|
|
|
free(path);
|
2008-05-20 06:49:26 +00:00
|
|
|
printf("%d\n", len);
|
2009-02-07 15:08:27 +00:00
|
|
|
return 0;
|
2008-05-20 06:49:26 +00:00
|
|
|
}
|
|
|
|
|
2011-08-04 04:47:48 +00:00
|
|
|
if (argc >= 4 && !strcmp(argv[1], "prefix_path")) {
|
add an extra level of indirection to main()
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-07-01 05:58:58 +00:00
|
|
|
const char *prefix = argv[2];
|
2011-08-04 04:47:48 +00:00
|
|
|
int prefix_len = strlen(prefix);
|
|
|
|
int nongit_ok;
|
|
|
|
setup_git_directory_gently(&nongit_ok);
|
|
|
|
while (argc > 3) {
|
|
|
|
puts(prefix_path(prefix, prefix_len, argv[3]));
|
|
|
|
argc--;
|
|
|
|
argv++;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-02-19 19:10:49 +00:00
|
|
|
if (argc == 4 && !strcmp(argv[1], "strip_path_suffix")) {
|
|
|
|
char *prefix = strip_path_suffix(argv[2], argv[3]);
|
|
|
|
printf("%s\n", prefix ? prefix : "(null)");
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-10-10 20:49:43 +00:00
|
|
|
if (argc == 3 && !strcmp(argv[1], "print_path")) {
|
2013-06-25 15:53:57 +00:00
|
|
|
puts(argv[2]);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-06-25 15:53:42 +00:00
|
|
|
if (argc == 4 && !strcmp(argv[1], "relative_path")) {
|
2013-06-25 15:53:43 +00:00
|
|
|
struct strbuf sb = STRBUF_INIT;
|
2013-06-25 15:53:42 +00:00
|
|
|
const char *in, *prefix, *rel;
|
|
|
|
normalize_argv_string(&in, argv[2]);
|
|
|
|
normalize_argv_string(&prefix, argv[3]);
|
2013-06-25 15:53:43 +00:00
|
|
|
rel = relative_path(in, prefix, &sb);
|
2013-06-25 15:53:42 +00:00
|
|
|
if (!rel)
|
|
|
|
puts("(null)");
|
|
|
|
else
|
|
|
|
puts(strlen(rel) > 0 ? rel : "(empty)");
|
2013-06-25 15:53:43 +00:00
|
|
|
strbuf_release(&sb);
|
2013-06-25 15:53:42 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-01-12 07:57:57 +00:00
|
|
|
if (argc == 2 && !strcmp(argv[1], "basename"))
|
|
|
|
return test_function(basename_data, basename, argv[1]);
|
|
|
|
|
|
|
|
if (argc == 2 && !strcmp(argv[1], "dirname"))
|
|
|
|
return test_function(dirname_data, dirname, argv[1]);
|
|
|
|
|
2009-02-07 15:08:27 +00:00
|
|
|
fprintf(stderr, "%s: unknown function name: %s\n", argv[0],
|
|
|
|
argv[1] ? argv[1] : "(there was none)");
|
|
|
|
return 1;
|
2008-05-20 06:48:54 +00:00
|
|
|
}
|