* [PATCH] http-push: support full URI in handle_remote_ls_ctx()
From: Kirill A. Korinskiy @ 2009-01-18 11:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Kirill A. Korinskiy
The program calls remote_ls() to get list of files from the server
over HTTP; handle_remote_ls_ctx() is used to parse its response to
populate "struct remote_ls_ctx" that is returned from remote_ls().
The handle_remote_ls_ctx() function assumed that the server returns a
local path in href field, but RFC 4918 (14.7) demand of support full
URI (e.g. "http://localhost:8080/repo.git").
This resulted in push failure (e.g. git-http-push issues a PROPFIND
request to "/repo.git/alhost:8080/repo.git/refs/" to the server).
Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
---
http-push.c | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/http-push.c b/http-push.c
index 7c6460919bf3eba10c46cede11ffdd9c53fd2dd2..2cb925a9ad857b6d79858d5187f14072167282e7 100644
--- a/http-push.c
+++ b/http-push.c
@@ -87,6 +87,7 @@ static struct object_list *objects;
struct repo
{
char *url;
+ char *path;
int path_len;
int has_info_refs;
int can_update_info_refs;
@@ -1424,9 +1425,18 @@ static void handle_remote_ls_ctx(struct xml_ctx *ctx, int tag_closed)
ls->userFunc(ls);
}
} else if (!strcmp(ctx->name, DAV_PROPFIND_NAME) && ctx->cdata) {
- ls->dentry_name = xmalloc(strlen(ctx->cdata) -
+ char *path = ctx->cdata;
+ if (!strcmp(ctx->cdata, "http://")) {
+ path = strchr(path + sizeof("http://") - 1, '/');
+ } else if (!strcmp(ctx->cdata, "https://")) {
+ path = strchr(path + sizeof("https://") - 1, '/');
+ }
+
+ path += remote->path_len;
+
+ ls->dentry_name = xmalloc(strlen(path) -
remote->path_len + 1);
- strcpy(ls->dentry_name, ctx->cdata + remote->path_len);
+ strcpy(ls->dentry_name, path + remote->path_len);
} else if (!strcmp(ctx->name, DAV_PROPFIND_COLLECTION)) {
ls->dentry_flags |= IS_DIR;
}
@@ -2206,10 +2216,11 @@ int main(int argc, char **argv)
if (!remote->url) {
char *path = strstr(arg, "//");
remote->url = arg;
+ remote->path_len = strlen(arg);
if (path) {
- path = strchr(path+2, '/');
- if (path)
- remote->path_len = strlen(path);
+ remote->path = strchr(path+2, '/');
+ if (remote->path)
+ remote->path_len = strlen(remote->path);
}
continue;
}
@@ -2238,8 +2249,9 @@ int main(int argc, char **argv)
rewritten_url = xmalloc(strlen(remote->url)+2);
strcpy(rewritten_url, remote->url);
strcat(rewritten_url, "/");
+ remote->path = rewritten_url + (remote->path - remote->url);
+ remote->path_len++;
remote->url = rewritten_url;
- ++remote->path_len;
}
/* Verify DAV compliance/lock support */
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] contrib/workdir: create logs/refs and rr-cache in the origin repository
From: Adeodato Simó @ 2009-01-18 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpu54cxe.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano [Sat, 17 Jan 2009 17:31:57 -0800]:
> Adeodato Simó <dato@net.com.org.es> writes:
> > If logs/refs or rr-cache are dangling symlinks in the workdir, and reflogs
> > and/or rerere are enabled, commit will die with "fatal: Could not create
> > directory". (In the case of rr-cache, it will die after having created the
> > commit.)
> > This commit just creates logs/refs and rr-cache in the origin repository if
> > they don't exist already.
> Hmm, is that better than not creating the symlink of the borrowed
> repository does not have them?
I would say so. I'll agree this covers a less common case, because one
normally starts a regular repo, work on it, and at some point realize
you'd like another checkout, and create a workdir. By that point, logs/refs
surely should exist in the original repo.
However, I've as of late directly created bare repositories knowing that
I wanted to work just with workdirs against it. In this case, the logs
for each checkout'ed branch will be stored in the workdirs and not the
repo, so deleting the workdir will make you lose those logs. Which is
bad, since workdirs should always be safe to delete.
As I said, I realized this is a bit of a cornercase, but I think it
would be nice solving in the proposed way. (If you want, I can put a
shorter version of the above rationale in the commit message.)
Thanks,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
La música es de los que la quieren escuchar y de nadie más.
-- Andrés Calamaro
^ permalink raw reply
* [PATCH 3/7 v2] git_extract_argv0_path(): Move check for valid argv0 from caller to callee
From: Steffen Prohaska @ 2009-01-18 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Johannes Sixt, Steffen Prohaska
In-Reply-To: <1232280015-8144-3-git-send-email-prohaska@zib.de>
This simplifies the calling code.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
exec_cmd.c | 3 +++
git.c | 5 ++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 23a52cf..89931e4 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -23,6 +23,9 @@ const char *system_path(const char *path)
const char *git_extract_argv0_path(const char *argv0)
{
+ if (!argv0 || !*argv0)
+ return 0;
+
const char *slash = argv0 + strlen(argv0);
while (argv0 <= slash && !is_dir_sep(*slash))
diff --git a/git.c b/git.c
index b99b1b2..9c8da93 100644
--- a/git.c
+++ b/git.c
@@ -422,9 +422,8 @@ int main(int argc, const char **argv)
const char *cmd;
int done_alias = 0;
- if (argv[0] && *argv[0])
- cmd = git_extract_argv0_path(argv[0]);
- else
+ cmd = git_extract_argv0_path(argv[0]);
+ if (!cmd)
cmd = "git-help";
/*
--
1.6.1.87.g15624
^ permalink raw reply related
* [PATCH 2/7 v2] Refactor git_set_argv0_path() to git_extract_argv0_path()
From: Steffen Prohaska @ 2009-01-18 12:00 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Johannes Sixt, Steve Haslam,
Steffen Prohaska
In-Reply-To: <1232280015-8144-2-git-send-email-prohaska@zib.de>
From: Steve Haslam <shaslam@lastminute.com>
This commit moves the code that computes the dirname of argv[0]
from git.c's main() to git_set_argv0_path() and renames the function
to git_extract_argv0_path(). This makes the code in git.c's main
less cluttered, and we can use the dirname computation from other
main() functions too.
[ spr:
- split Steve's original commit and wrote new commit message.
- Integrated Johannes Schindelin's
cca1704897e7fdb182f68d4c48a437c5d7bc5203 while rebasing onto master.
]
Signed-off-by: Steve Haslam <shaslam@lastminute.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
exec_cmd.c | 14 ++++++++++++--
exec_cmd.h | 2 +-
git.c | 19 +++++--------------
3 files changed, 18 insertions(+), 17 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index b7e7b60..23a52cf 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -21,9 +21,19 @@ const char *system_path(const char *path)
return path;
}
-void git_set_argv0_path(const char *path)
+const char *git_extract_argv0_path(const char *argv0)
{
- argv0_path = path;
+ const char *slash = argv0 + strlen(argv0);
+
+ while (argv0 <= slash && !is_dir_sep(*slash))
+ slash--;
+
+ if (slash >= argv0) {
+ argv0_path = xstrndup(argv0, slash - argv0);
+ return slash + 1;
+ }
+
+ return argv0;
}
void git_set_argv_exec_path(const char *exec_path)
diff --git a/exec_cmd.h b/exec_cmd.h
index 594f961..392e903 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -2,7 +2,7 @@
#define GIT_EXEC_CMD_H
extern void git_set_argv_exec_path(const char *exec_path);
-extern void git_set_argv0_path(const char *path);
+extern const char* git_extract_argv0_path(const char *path);
extern const char* git_exec_path(void);
extern void setup_path(void);
extern const char **prepare_git_cmd(const char **argv);
diff --git a/git.c b/git.c
index a53e24f..b99b1b2 100644
--- a/git.c
+++ b/git.c
@@ -419,22 +419,13 @@ static void execv_dashed_external(const char **argv)
int main(int argc, const char **argv)
{
- const char *cmd = argv[0] && *argv[0] ? argv[0] : "git-help";
- char *slash = (char *)cmd + strlen(cmd);
+ const char *cmd;
int done_alias = 0;
- /*
- * Take the basename of argv[0] as the command
- * name, and the dirname as the default exec_path
- * if we don't have anything better.
- */
- while (cmd <= slash && !is_dir_sep(*slash))
- slash--;
- if (cmd <= slash) {
- *slash++ = 0;
- git_set_argv0_path(cmd);
- cmd = slash;
- }
+ if (argv[0] && *argv[0])
+ cmd = git_extract_argv0_path(argv[0]);
+ else
+ cmd = "git-help";
/*
* "git-xxxx" is the same as "git xxxx", but we obviously:
--
1.6.1.87.g15624
^ permalink raw reply related
* [PATCH 5/7 v2] Modify setup_path() to only add git_exec_path() to PATH
From: Steffen Prohaska @ 2009-01-18 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Johannes Sixt, Steffen Prohaska
In-Reply-To: <1232280015-8144-5-git-send-email-prohaska@zib.de>
Searching git programs only in the highest priority location is
sufficient. It does not make sense that some of the required
programs are located at the highest priority location but other
programs are picked up from a lower priority exec-path. If
exec-path is overridden a complete set of commands should be
provided, otherwise several different versions could get mixed,
which is likely to cause confusion.
If a user explicitly overrides the default location (by --exec-path
or GIT_EXEC_PATH), we now expect that all the required programs are
found there. Instead of adding the directories "argv_exec_path",
"getenv(EXEC_PATH_ENVIRONMENT)", and "system_path(GIT_EXEC_PATH)"
to PATH, we now rely on git_exec_path(), which implements the same
order, but only returns the highest priority location to search for
executables.
Accessing only the location with highest priority is also required
for testing executables built with RUNTIME_PREFIX. The call to
system_path() should be avoided if RUNTIME_PREFIX is set and the
executable is not installed at its final destination. Because we
test before installing, we want to avoid calling system_path()
during tests. The modifications in this commit avoid calling
system_path(GIT_EXEC_PATH) if a higher-priority location is
provided, which is the case when running the tests.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
exec_cmd.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 89931e4..d9408db 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -78,9 +78,7 @@ void setup_path(void)
const char *old_path = getenv("PATH");
struct strbuf new_path = STRBUF_INIT;
- add_path(&new_path, argv_exec_path);
- add_path(&new_path, getenv(EXEC_PATH_ENVIRONMENT));
- add_path(&new_path, system_path(GIT_EXEC_PATH));
+ add_path(&new_path, git_exec_path());
add_path(&new_path, argv0_path);
if (old_path)
--
1.6.1.87.g15624
^ permalink raw reply related
* [PATCH 4/7 v2] Add calls to git_extract_argv0_path() in programs that call git_config_*
From: Steffen Prohaska @ 2009-01-18 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Johannes Sixt, Steffen Prohaska
In-Reply-To: <1232280015-8144-4-git-send-email-prohaska@zib.de>
Programs that use git_config need to find the global configuration.
When runtime prefix computation is enabled, this requires that
git_extract_argv0_path() is called early in the program's main().
This commit adds the necessary calls.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
daemon.c | 2 ++
fast-import.c | 3 +++
hash-object.c | 3 +++
http-push.c | 2 ++
imap-send.c | 3 +++
index-pack.c | 3 +++
merge-index.c | 3 +++
merge-tree.c | 3 +++
mktag.c | 3 +++
mktree.c | 3 +++
pack-redundant.c | 3 +++
patch-id.c | 3 +++
unpack-file.c | 3 +++
update-server-info.c | 3 +++
upload-pack.c | 2 ++
var.c | 3 +++
16 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/daemon.c b/daemon.c
index 540700e..d93cf96 100644
--- a/daemon.c
+++ b/daemon.c
@@ -937,6 +937,8 @@ int main(int argc, char **argv)
gid_t gid = 0;
int i;
+ git_extract_argv0_path(argv[0]);
+
for (i = 1; i < argc; i++) {
char *arg = argv[i];
diff --git a/fast-import.c b/fast-import.c
index f0e08ac..1935206 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -150,6 +150,7 @@ Format of STDIN stream:
#include "refs.h"
#include "csum-file.h"
#include "quote.h"
+#include "exec_cmd.h"
#define PACK_ID_BITS 16
#define MAX_PACK_ID ((1<<PACK_ID_BITS)-1)
@@ -2406,6 +2407,8 @@ int main(int argc, const char **argv)
{
unsigned int i, show_stats = 1;
+ git_extract_argv0_path(argv[0]);
+
setup_git_directory();
git_config(git_pack_config, NULL);
if (!pack_compression_seen && core_compression_seen)
diff --git a/hash-object.c b/hash-object.c
index 846e91a..37e6677 100644
--- a/hash-object.c
+++ b/hash-object.c
@@ -8,6 +8,7 @@
#include "blob.h"
#include "quote.h"
#include "parse-options.h"
+#include "exec_cmd.h"
static void hash_fd(int fd, const char *type, int write_object, const char *path)
{
@@ -81,6 +82,8 @@ int main(int argc, const char **argv)
type = blob_type;
+ git_extract_argv0_path(argv[0]);
+
git_config(git_default_config, NULL);
argc = parse_options(argc, argv, hash_object_options, hash_object_usage, 0);
diff --git a/http-push.c b/http-push.c
index a4b7d08..09caede 100644
--- a/http-push.c
+++ b/http-push.c
@@ -2179,6 +2179,8 @@ int main(int argc, char **argv)
struct ref *ref;
char *rewritten_url = NULL;
+ git_extract_argv0_path(argv[0]);
+
setup_git_directory();
remote = xcalloc(sizeof(*remote), 1);
diff --git a/imap-send.c b/imap-send.c
index c3fa0df..f91293c 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -23,6 +23,7 @@
*/
#include "cache.h"
+#include "exec_cmd.h"
#ifdef NO_OPENSSL
typedef void *SSL;
#endif
@@ -1389,6 +1390,8 @@ int main(int argc, char **argv)
int total, n = 0;
int nongit_ok;
+ git_extract_argv0_path(argv[0]);
+
/* init the random number generator */
arc4_init();
diff --git a/index-pack.c b/index-pack.c
index 2931511..72c41fd 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -8,6 +8,7 @@
#include "tree.h"
#include "progress.h"
#include "fsck.h"
+#include "exec_cmd.h"
static const char index_pack_usage[] =
"git index-pack [-v] [-o <index-file>] [{ ---keep | --keep=<msg> }] [--strict] { <pack-file> | --stdin [--fix-thin] [<pack-file>] }";
@@ -880,6 +881,8 @@ int main(int argc, char **argv)
struct pack_idx_entry **idx_objects;
unsigned char pack_sha1[20];
+ git_extract_argv0_path(argv[0]);
+
/*
* We wish to read the repository's config file if any, and
* for that it is necessary to call setup_git_directory_gently().
diff --git a/merge-index.c b/merge-index.c
index 7827e87..c00a2b3 100644
--- a/merge-index.c
+++ b/merge-index.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "run-command.h"
+#include "exec_cmd.h"
static const char *pgm;
static const char *arguments[9];
@@ -93,6 +94,8 @@ int main(int argc, char **argv)
if (argc < 3)
usage("git-merge-index [-o] [-q] <merge-program> (-a | [--] <filename>*)");
+ git_extract_argv0_path(argv[0]);
+
setup_git_directory();
read_cache();
diff --git a/merge-tree.c b/merge-tree.c
index 2d1413e..f18201a 100644
--- a/merge-tree.c
+++ b/merge-tree.c
@@ -2,6 +2,7 @@
#include "tree-walk.h"
#include "xdiff-interface.h"
#include "blob.h"
+#include "exec_cmd.h"
static const char merge_tree_usage[] = "git-merge-tree <base-tree> <branch1> <branch2>";
static int resolve_directories = 1;
@@ -344,6 +345,8 @@ int main(int argc, char **argv)
if (argc != 4)
usage(merge_tree_usage);
+ git_extract_argv0_path(argv[0]);
+
setup_git_directory();
buf1 = get_tree_descriptor(t+0, argv[1]);
diff --git a/mktag.c b/mktag.c
index ba3d495..6d5083e 100644
--- a/mktag.c
+++ b/mktag.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "tag.h"
+#include "exec_cmd.h"
/*
* A signature file has a very simple fixed format: four lines
@@ -159,6 +160,8 @@ int main(int argc, char **argv)
if (argc != 1)
usage("git-mktag < signaturefile");
+ git_extract_argv0_path(argv[0]);
+
setup_git_directory();
if (strbuf_read(&buf, 0, 4096) < 0) {
diff --git a/mktree.c b/mktree.c
index 514fd9b..6283bc3 100644
--- a/mktree.c
+++ b/mktree.c
@@ -6,6 +6,7 @@
#include "cache.h"
#include "quote.h"
#include "tree.h"
+#include "exec_cmd.h"
static struct treeent {
unsigned mode;
@@ -70,6 +71,8 @@ int main(int ac, char **av)
unsigned char sha1[20];
int line_termination = '\n';
+ git_extract_argv0_path(av[0]);
+
setup_git_directory();
while ((1 < ac) && av[1][0] == '-') {
diff --git a/pack-redundant.c b/pack-redundant.c
index e93eb96..48a12bc 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -7,6 +7,7 @@
*/
#include "cache.h"
+#include "exec_cmd.h"
#define BLKSIZE 512
@@ -601,6 +602,8 @@ int main(int argc, char **argv)
unsigned char *sha1;
char buf[42]; /* 40 byte sha1 + \n + \0 */
+ git_extract_argv0_path(argv[0]);
+
setup_git_directory();
for (i = 1; i < argc; i++) {
diff --git a/patch-id.c b/patch-id.c
index 871f1d2..3660ad4 100644
--- a/patch-id.c
+++ b/patch-id.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "exec_cmd.h"
static void flush_current_id(int patchlen, unsigned char *id, git_SHA_CTX *c)
{
@@ -79,6 +80,8 @@ int main(int argc, char **argv)
if (argc != 1)
usage(patch_id_usage);
+ git_extract_argv0_path(argv[0]);
+
generate_id_list();
return 0;
}
diff --git a/unpack-file.c b/unpack-file.c
index bcdc8bb..6dd8ad0 100644
--- a/unpack-file.c
+++ b/unpack-file.c
@@ -1,5 +1,6 @@
#include "cache.h"
#include "blob.h"
+#include "exec_cmd.h"
static char *create_temp_file(unsigned char *sha1)
{
@@ -25,6 +26,8 @@ int main(int argc, char **argv)
{
unsigned char sha1[20];
+ git_extract_argv0_path(argv[0]);
+
if (argc != 2)
usage("git-unpack-file <sha1>");
if (get_sha1(argv[1], sha1))
diff --git a/update-server-info.c b/update-server-info.c
index 7e8209e..7b38fd8 100644
--- a/update-server-info.c
+++ b/update-server-info.c
@@ -1,4 +1,5 @@
#include "cache.h"
+#include "exec_cmd.h"
static const char update_server_info_usage[] =
"git update-server-info [--force]";
@@ -19,6 +20,8 @@ int main(int ac, char **av)
if (i != ac)
usage(update_server_info_usage);
+ git_extract_argv0_path(av[0]);
+
setup_git_directory();
return !!update_server_info(force);
diff --git a/upload-pack.c b/upload-pack.c
index e5adbc0..5db6f93 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -616,6 +616,8 @@ int main(int argc, char **argv)
int i;
int strict = 0;
+ git_extract_argv0_path(argv[0]);
+
for (i = 1; i < argc; i++) {
char *arg = argv[i];
diff --git a/var.c b/var.c
index f1eb314..7362ed8 100644
--- a/var.c
+++ b/var.c
@@ -4,6 +4,7 @@
* Copyright (C) Eric Biederman, 2005
*/
#include "cache.h"
+#include "exec_cmd.h"
static const char var_usage[] = "git var [-l | <variable>]";
@@ -56,6 +57,8 @@ int main(int argc, char **argv)
usage(var_usage);
}
+ git_extract_argv0_path(argv[0]);
+
setup_git_directory_gently(&nongit);
val = NULL;
--
1.6.1.87.g15624
^ permalink raw reply related
* [PATCH 7/7 v2] Windows: Revert to default paths and convert them by RUNTIME_PREFIX
From: Steffen Prohaska @ 2009-01-18 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Johannes Sixt, Steffen Prohaska
In-Reply-To: <1232280015-8144-7-git-send-email-prohaska@zib.de>
The RUNTIME_PREFIX mechanism allows us to use the default paths on
Windows too. Defining RUNTIME_PREFIX explicitly requests for
translation of paths relative to the executable at runtime.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Makefile | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index fbe52c9..74ecd77 100644
--- a/Makefile
+++ b/Makefile
@@ -789,6 +789,7 @@ ifneq (,$(findstring MINGW,$(uname_S)))
SNPRINTF_RETURNS_BOGUS = YesPlease
NO_SVN_TESTS = YesPlease
NO_PERL_MAKEMAKER = YesPlease
+ RUNTIME_PREFIX = YesPlease
NO_POSIX_ONLY_PROGRAMS = YesPlease
NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
COMPAT_CFLAGS += -D__USE_MINGW_ACCESS -DNOGDI -Icompat -Icompat/regex -Icompat/fnmatch
@@ -797,9 +798,6 @@ ifneq (,$(findstring MINGW,$(uname_S)))
COMPAT_OBJS += compat/mingw.o compat/fnmatch/fnmatch.o compat/regex/regex.o compat/winansi.o
EXTLIBS += -lws2_32
X = .exe
- gitexecdir = ../libexec/git-core
- template_dir = ../share/git-core/templates/
- ETC_GITCONFIG = ../etc/gitconfig
endif
ifneq (,$(findstring arm,$(uname_M)))
ARM_SHA1 = YesPlease
--
1.6.1.87.g15624
^ permalink raw reply related
* [PATCH 1/7 v2] Move computation of absolute paths from Makefile to runtime (in preparation for RUNTIME_PREFIX)
From: Steffen Prohaska @ 2009-01-18 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Johannes Sixt, Steffen Prohaska
In-Reply-To: <1232280015-8144-1-git-send-email-prohaska@zib.de>
This commit prepares the Makefile for relocatable binaries (called
RUNTIME_PREFIX). Such binaries will be able to be moved together
with the system configuration files to a different directory,
requiring to compute the prefix at runtime.
In a first step, we make all paths relative in the Makefile and
teach system_path() to add the prefix instead. We used to compute
absolute paths in the Makefile and passed them to C as defines. We
now pass relative paths to C and call system_path() to add the
prefix at runtime.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Makefile | 42 ++++++++++++++++++++++++++----------------
builtin-help.c | 4 ++--
exec_cmd.c | 12 ++++++++----
3 files changed, 36 insertions(+), 22 deletions(-)
diff --git a/Makefile b/Makefile
index 2b873fa..1d2060a 100644
--- a/Makefile
+++ b/Makefile
@@ -179,28 +179,32 @@ STRIP ?= strip
# Among the variables below, these:
# gitexecdir
# template_dir
+# mandir
+# infodir
# htmldir
# ETC_GITCONFIG (but not sysconfdir)
-# can be specified as a relative path ../some/where/else (which must begin
-# with ../); this is interpreted as relative to $(bindir) and "git" at
+# can be specified as a relative path some/where/else;
+# this is interpreted as relative to $(prefix) and "git" at
# runtime figures out where they are based on the path to the executable.
# This can help installing the suite in a relocatable way.
prefix = $(HOME)
-bindir = $(prefix)/bin
-mandir = $(prefix)/share/man
-infodir = $(prefix)/share/info
-gitexecdir = $(prefix)/libexec/git-core
+bindir_relative = bin
+bindir = $(prefix)/$(bindir_relative)
+mandir = share/man
+infodir = share/info
+gitexecdir = libexec/git-core
sharedir = $(prefix)/share
-template_dir = $(sharedir)/git-core/templates
-htmldir=$(sharedir)/doc/git-doc
+template_dir = share/git-core/templates
+htmldir = share/doc/git-doc
ifeq ($(prefix),/usr)
sysconfdir = /etc
+ETC_GITCONFIG = $(sysconfdir)/gitconfig
else
sysconfdir = $(prefix)/etc
+ETC_GITCONFIG = etc/gitconfig
endif
lib = lib
-ETC_GITCONFIG = $(sysconfdir)/gitconfig
# DESTDIR=
# default configuration for gitweb
@@ -1086,6 +1090,7 @@ ETC_GITCONFIG_SQ = $(subst ','\'',$(ETC_GITCONFIG))
DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
+bindir_relative_SQ = $(subst ','\'',$(bindir_relative))
mandir_SQ = $(subst ','\'',$(mandir))
infodir_SQ = $(subst ','\'',$(infodir))
gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
@@ -1251,7 +1256,12 @@ git.o git.spec \
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) $<
exec_cmd.o: exec_cmd.c GIT-CFLAGS
- $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' $<
+ $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
+ '-DGIT_EXEC_PATH="$(gitexecdir_SQ)"' \
+ '-DBINDIR="$(bindir_relative_SQ)"' \
+ '-DPREFIX="$(prefix_SQ)"' \
+ $<
+
builtin-init-db.o: builtin-init-db.c GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' $<
@@ -1407,17 +1417,17 @@ remove-dashes:
### Installation rules
-ifeq ($(firstword $(subst /, ,$(template_dir))),..)
-template_instdir = $(bindir)/$(template_dir)
-else
+ifeq ($(abspath $(template_dir)),$(template_dir))
template_instdir = $(template_dir)
+else
+template_instdir = $(prefix)/$(template_dir)
endif
export template_instdir
-ifeq ($(firstword $(subst /, ,$(gitexecdir))),..)
-gitexec_instdir = $(bindir)/$(gitexecdir)
-else
+ifeq ($(abspath $(gitexecdir)),$(gitexecdir))
gitexec_instdir = $(gitexecdir)
+else
+gitexec_instdir = $(prefix)/$(gitexecdir)
endif
gitexec_instdir_SQ = $(subst ','\'',$(gitexec_instdir))
export gitexec_instdir
diff --git a/builtin-help.c b/builtin-help.c
index f076efa..9b57a74 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -329,7 +329,7 @@ static void setup_man_path(void)
* old_path, the ':' at the end will let 'man' to try
* system-wide paths after ours to find the manual page. If
* there is old_path, we need ':' as delimiter. */
- strbuf_addstr(&new_path, GIT_MAN_PATH);
+ strbuf_addstr(&new_path, system_path(GIT_MAN_PATH));
strbuf_addch(&new_path, ':');
if (old_path)
strbuf_addstr(&new_path, old_path);
@@ -375,7 +375,7 @@ static void show_man_page(const char *git_cmd)
static void show_info_page(const char *git_cmd)
{
const char *page = cmd_to_page(git_cmd);
- setenv("INFOPATH", GIT_INFO_PATH, 1);
+ setenv("INFOPATH", system_path(GIT_INFO_PATH), 1);
execlp("info", "info", "gitman", page, NULL);
}
diff --git a/exec_cmd.c b/exec_cmd.c
index cdd35f9..b7e7b60 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -9,11 +9,15 @@ static const char *argv0_path;
const char *system_path(const char *path)
{
- if (!is_absolute_path(path) && argv0_path) {
- struct strbuf d = STRBUF_INIT;
- strbuf_addf(&d, "%s/%s", argv0_path, path);
- path = strbuf_detach(&d, NULL);
+ static const char *prefix = PREFIX;
+
+ if (is_absolute_path(path)) {
+ return path;
}
+
+ struct strbuf d = STRBUF_INIT;
+ strbuf_addf(&d, "%s/%s", prefix, path);
+ path = strbuf_detach(&d, NULL);
return path;
}
--
1.6.1.87.g15624
^ permalink raw reply related
* [PATCH 0/7 v2] RUNTIME_PREFIX
From: Steffen Prohaska @ 2009-01-18 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Johannes Sixt, Steffen Prohaska
This series is a replacement for
http://article.gmane.org/gmane.comp.version-control.git/105109
improved according to the comments by Dscho and Hannes.
Steffen
Steffen Prohaska (6):
Move computation of absolute paths from Makefile to runtime (in
preparation for RUNTIME_PREFIX)
git_extract_argv0_path(): Move check for valid argv0 from caller to
callee
Add calls to git_extract_argv0_path() in programs that call
git_config_*
Modify setup_path() to only add git_exec_path() to PATH
Compute prefix at runtime if RUNTIME_PREFIX is set
Windows: Revert to default paths and convert them by RUNTIME_PREFIX
Steve Haslam (1):
Refactor git_set_argv0_path() to git_extract_argv0_path()
Makefile | 49 +++++++++++++++++++------------
builtin-help.c | 4 +-
daemon.c | 2 +
exec_cmd.c | 77 ++++++++++++++++++++++++++++++++++++++++++++------
exec_cmd.h | 2 +-
fast-import.c | 3 ++
git.c | 18 ++---------
hash-object.c | 3 ++
http-push.c | 2 +
imap-send.c | 3 ++
index-pack.c | 3 ++
merge-index.c | 3 ++
merge-tree.c | 3 ++
mktag.c | 3 ++
mktree.c | 3 ++
pack-redundant.c | 3 ++
patch-id.c | 3 ++
unpack-file.c | 3 ++
update-server-info.c | 3 ++
upload-pack.c | 2 +
var.c | 3 ++
21 files changed, 150 insertions(+), 45 deletions(-)
^ permalink raw reply
* [PATCH 6/7 v2] Compute prefix at runtime if RUNTIME_PREFIX is set
From: Steffen Prohaska @ 2009-01-18 12:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Johannes Sixt, Steffen Prohaska
In-Reply-To: <1232280015-8144-6-git-send-email-prohaska@zib.de>
This commit adds support for relocatable binaries (called
RUNTIME_PREFIX). Such binaries can be moved together with the
system configuration files to a different directory, as long as the
relative paths from the binary to the configuration files is
preserved. This functionality is essential on Windows where we
deliver git binaries with an installer that allows to freely choose
the installation location.
If RUNTIME_PREFIX is unset we use the static prefix. This will be
the default on Unix. Thus, the behavior on Unix will remain
identical to the old implementation, which used to add the prefix
in the Makefile.
If RUNTIME_PREFIX is set the prefix is computed from the location
of the executable. In this case, system_path() tries to strip
known directories that executables can be located in from the path
of the executable. If the path is successfully stripped it is used
as the prefix. For example, if the executable is
"/msysgit/bin/git" and BINDIR is "bin", then the prefix computed is
"/msysgit".
If the runtime prefix computation fails, we fall back to the static
prefix specified in the makefile. This can be the case if the
executable is not installed at a known location. Note that our
test system sets GIT_CONFIG_NOSYSTEM to tell git to ignore global
configuration files during testing. Hence testing does not trigger
the fall back.
Note that RUNTIME_PREFIX only works on Windows, though adding
support on Unix should not be too hard. The implementation
requires argv0_path to be set to an absolute path. argv0_path must
point to the directory of the executable. We use assert() to
verify this in debug builds. On Windows, the wrapper for main()
(see compat/mingw.h) guarantees that argv0_path is correctly
initialized. On Unix, further work is required before
RUNTIME_PREFIX can be enabled.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Makefile | 3 +++
exec_cmd.c | 44 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 1d2060a..fbe52c9 100644
--- a/Makefile
+++ b/Makefile
@@ -1031,6 +1031,9 @@ ifdef INTERNAL_QSORT
COMPAT_CFLAGS += -DINTERNAL_QSORT
COMPAT_OBJS += compat/qsort.o
endif
+ifdef RUNTIME_PREFIX
+ COMPAT_CFLAGS += -DRUNTIME_PREFIX
+endif
ifdef NO_PTHREADS
THREADED_DELTA_SEARCH =
diff --git a/exec_cmd.c b/exec_cmd.c
index d9408db..5f59880 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -9,12 +9,56 @@ static const char *argv0_path;
const char *system_path(const char *path)
{
+#ifdef RUNTIME_PREFIX
+ static const char *prefix = 0;
+#else
static const char *prefix = PREFIX;
+#endif
if (is_absolute_path(path)) {
return path;
}
+#ifdef RUNTIME_PREFIX
+ assert(argv0_path);
+ assert(is_absolute_path(argv0_path));
+
+ if (!prefix) {
+ const char *strip[] = {
+ GIT_EXEC_PATH,
+ BINDIR,
+ 0
+ };
+ const char **s;
+
+ for (s = strip; *s; s++) {
+ const char *sargv = argv0_path + strlen(argv0_path);
+ const char *ss = *s + strlen(*s);
+ while (argv0_path < sargv && *s < ss
+ && (*sargv == *ss ||
+ (is_dir_sep(*sargv) && is_dir_sep(*ss)))) {
+ sargv--;
+ ss--;
+ }
+ if (*s == ss) {
+ struct strbuf d = STRBUF_INIT;
+ /* We also skip the trailing directory separator. */
+ assert(sargv - argv0_path - 1 >= 0);
+ strbuf_add(&d, argv0_path, sargv - argv0_path - 1);
+ prefix = strbuf_detach(&d, NULL);
+ break;
+ }
+ }
+ }
+
+ if (!prefix) {
+ prefix = PREFIX;
+ fprintf(stderr, "RUNTIME_PREFIX requested, "
+ "but prefix computation failed. "
+ "Using static fallback '%s'.\n", prefix);
+ }
+#endif
+
struct strbuf d = STRBUF_INIT;
strbuf_addf(&d, "%s/%s", prefix, path);
path = strbuf_detach(&d, NULL);
--
1.6.1.87.g15624
^ permalink raw reply related
* Re: is gitosis secure?
From: Florian Weimer @ 2009-01-18 11:48 UTC (permalink / raw)
To: git
In-Reply-To: <1228813453.28186.73.camel@maia.lan>
* Sam Vilain:
> Restricted unix shells are a technology which has been proven secure for
> decades now.
Huh? Things like scponly and rssh had their share of bugs, so I can
see that there is some concern. (And restricted shells used to be
circumvented by things like Netscape's print dialog.)
^ permalink raw reply
* Re: is gitosis secure?
From: Boyd Stephen Smith Jr. @ 2009-01-18 12:50 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <873afgsul8.fsf@mid.deneb.enyo.de>
[-- Attachment #1: Type: text/plain, Size: 1651 bytes --]
On Sunday 18 January 2009, Florian Weimer <fw@deneb.enyo.de> wrote
about 'Re: is gitosis secure?':
>* Sam Vilain:
>> Restricted unix shells are a technology which has been proven secure
>> for decades now.
>Huh? Things like scponly and rssh had their share of bugs, so I can
>see that there is some concern. (And restricted shells used to be
>circumvented by things like Netscape's print dialog.)
From my understanding, a restricted shell is a difficult thing to escape
from unless a user is able to run binaries that they have written. FWIW,
I don't remember sftp or scponly having this particular vulnerability.
Even if a user is allowed to run scripts they have written, escaping from a
chroot is more difficult, but per-user chroots have their own
administrative overhead. They also might be escaped in the case of a
simultaneous privilege escalation bug (allowing the attacker to be root in
the chroot) and kernel bug (or "chroot feature") that gave chrooted root
to write outside the chroot (for example, to a file they would be
reasonably sure would be executed).
I can't speak directly to gitosis' security. If users are allowed to, e.g.
change the hooks in their repository, there may be an issue there. I
certainly haven't done any sort of audit to the source code AND I do not
hold any security certification--or even job experience in a security
field, yet.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] http-push: update memory allocation for http headers
From: Ray Chuan @ 2009-01-18 13:16 UTC (permalink / raw)
To: git
In 753bc91 (Remove the requirement opaquelocktoken uri scheme), the
header strings were with the removal "opaquelocktoken:" (16
characters).
Unfortunately, this was without the corresponding change in memory
allocation. In this patch we update these allocations.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
http-push.c | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/http-push.c b/http-push.c
index a4b7d08..a6522dd 100644
--- a/http-push.c
+++ b/http-push.c
@@ -595,7 +595,7 @@ static int refresh_lock(struct remote_lock *lock)
lock->refreshing = 1;
- if_header = xmalloc(strlen(lock->token) + 25);
+ if_header = xmalloc(strlen(lock->token) + 9);
sprintf(if_header, "If: (<%s>)", lock->token);
sprintf(timeout_header, "Timeout: Second-%ld", lock->timeout);
dav_headers = curl_slist_append(dav_headers, if_header);
@@ -1306,7 +1306,7 @@ static int unlock_remote(struct remote_lock *lock)
struct curl_slist *dav_headers = NULL;
int rc = 0;
- lock_token_header = xmalloc(strlen(lock->token) + 31);
+ lock_token_header = xmalloc(strlen(lock->token) + 15);
sprintf(lock_token_header, "Lock-Token: <%s>",
lock->token);
dav_headers = curl_slist_append(dav_headers, lock_token_header);
@@ -1730,7 +1730,7 @@ static int update_remote(unsigned char *sha1,
struct remote_lock *lock)
struct buffer out_buffer = { STRBUF_INIT, 0 };
struct curl_slist *dav_headers = NULL;
- if_header = xmalloc(strlen(lock->token) + 25);
+ if_header = xmalloc(strlen(lock->token) + 9);
sprintf(if_header, "If: (<%s>)", lock->token);
dav_headers = curl_slist_append(dav_headers, if_header);
@@ -1949,7 +1949,7 @@ static void update_remote_info_refs(struct
remote_lock *lock)
remote_ls("refs/", (PROCESS_FILES | RECURSIVE),
add_remote_info_ref, &buffer.buf);
if (!aborted) {
- if_header = xmalloc(strlen(lock->token) + 25);
+ if_header = xmalloc(strlen(lock->token) + 9);
sprintf(if_header, "If: (<%s>)", lock->token);
dav_headers = curl_slist_append(dav_headers, if_header);
--
1.6.0.4
^ permalink raw reply related
* Re: is gitosis secure?
From: Florian Weimer @ 2009-01-18 13:25 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901180650.06605.bss@iguanasuicide.net>
* Boyd Stephen Smith, Jr.:
> On Sunday 18 January 2009, Florian Weimer <fw@deneb.enyo.de> wrote
> about 'Re: is gitosis secure?':
>>* Sam Vilain:
>>> Restricted unix shells are a technology which has been proven secure
>>> for decades now.
>>Huh? Things like scponly and rssh had their share of bugs, so I can
>>see that there is some concern. (And restricted shells used to be
>>circumvented by things like Netscape's print dialog.)
>
> From my understanding, a restricted shell is a difficult thing to escape
> from unless a user is able to run binaries that they have written. FWIW,
> I don't remember sftp or scponly having this particular vulnerability.
scponly issues due to interpretation conflicts:
CVE-2002-1469 scponly does not properly verify the path when finding the (1) scp or ...
CVE-2004-1162 The unison command in scponly before 4.0 does not properly restrict ...
CVE-2005-4533 Argument injection vulnerability in scponlyc in scponly 4.1 and ...
CVE-2007-6350 scponly 4.6 and earlier allows remote authenticated users to bypass ...
CVE-2007-6415 scponly 4.6 and earlier allows remote authenticated users to bypass ...
rssh has fewer such issues, only CVE-2004-1161 seems to be intrinsic
to the program's purpose (but some of the other issues might be used
as circumvention devices, too).
That's why I think it's not totally outlandish to assume that
restricted shells are usually not very helpful for
compartmentalization purposes.
^ permalink raw reply
* Re: [PATCH 2/2] http-push: remove MOVE step after PUT when sending objects to server
From: Johannes Schindelin @ 2009-01-18 13:32 UTC (permalink / raw)
To: Ray Chuan; +Cc: Junio C Hamano, git
In-Reply-To: <be6fef0d0901171919ub28dda7ref6443abec3627aa@mail.gmail.com>
Hi,
On Sun, 18 Jan 2009, Ray Chuan wrote:
> On Sun, Jan 18, 2009 at 12:48 AM, Junio C Hamano <gitster@pobox.com> wrote:
>
> > "Ray Chuan" <rctay89@gmail.com> writes:
> >
> >> A concern raised was repository corruption in the event of failure
> >> during PUT. "put && move" won't afford any more protection than using
> >> simply "put", since info/refs is not updated if a PUT fails, so there
> >> is no cause for concern.
> >
> > That's a completely bogus reasoning. Normal operation inside the
> > repository that was pushed into won't look at info/refs at all.
>
> i mentioned this "repository corruption" issue as it was raised
> previously by Johannes (towards the bottom):
>
> http://article.gmane.org/gmane.comp.version-control.git/106031
,.. and Junio just raised a new concern. The repository as it is on the
server could very well be served by other means, i.e. git:// and rsync://,
and there could be cron jobs and interactive Git sessions trying to work
with it.
The point is: the repository inside the document root of the web server is
still a valid repository.
And the assumption is that whenever you have a file that looks like a
valid object/pack inside a valid repository, that it does not need
replacing.
So even when optimizing the uncommon (HTTP push is 2nd class citizen), we
have to keep the common workflow intact (1st class citizens _are_ push by
file system, ssh or git://).
Which unfortunately means that put && move must stay.
The same reasoning explains why http-push has to ignore the info/refs file
when looking for common refs, BTW.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] revision walker: include a detached HEAD in --all
From: Johannes Schindelin @ 2009-01-18 13:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Johannes Sixt, git
In-Reply-To: <7v8wp917c3.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 17 Jan 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > When HEAD is detached, --all should list it, too, logically, as a
> > detached HEAD is by definition a temporary, unnamed branch.
> >
> > It is especially necessary to list it when garbage collecting, as
> > the detached HEAD would be trashed.
> >
> > Noticed by Thomas Rast.
> >
> > Note that this affects creating bundles with --all; I contend that it
> > is a good change to add the HEAD, so that cloning from such a bundle
> > will give you a current branch. However, I had to fix t5701 as it
> > assumed that --all does not imply HEAD.
>
> Sorry, but I do not understand.
>
> > diff --git a/t/t5701-clone-local.sh b/t/t5701-clone-local.sh
> > index 8dfaaa4..14413f8 100755
> > --- a/t/t5701-clone-local.sh
> > +++ b/t/t5701-clone-local.sh
> > @@ -11,8 +11,8 @@ test_expect_success 'preparing origin repository' '
> > git clone --bare . x &&
> > test "$(GIT_CONFIG=a.git/config git config --bool core.bare)" = true &&
> > test "$(GIT_CONFIG=x/config git config --bool core.bare)" = true
> > - git bundle create b1.bundle --all HEAD &&
> > - git bundle create b2.bundle --all &&
> > + git bundle create b1.bundle master HEAD &&
> > + git bundle create b2.bundle master &&
>
> Because --all did not imply HEAD, "--all HEAD" used to be the way to say
> "everything and HEAD". Now --all does imply HEAD, but it should still be
> a valid way to say "everything, by the way, do not forget HEAD".
>
> Does the first one need to be changed to "master HEAD"? If "--all HEAD"
> makes the rest of the test unhappy because HEAD is listed twice, perhaps
> that is an independent bug that needs to be fixed?
I changed it away from --all because I am a fan of being explicit. We
want a bundle here that has master and HEAD in it. This being a test
case, being lazy is so wrong here. You should describe what you actually
want, not use a set of parameters that just happens to work (by chance as
we saw).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] revision walker: include a detached HEAD in --all
From: Johannes Schindelin @ 2009-01-18 14:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Thomas Rast, Johannes Sixt, git
In-Reply-To: <7v3afh15pi.fsf@gitster.siamese.dyndns.org>
Hi,
On Sat, 17 Jan 2009, Junio C Hamano wrote:
> Subject: [PATCH] bundle: allow the same ref to be given more than once
>
> "git bundle create x master master" used to create a bundle that lists
> the same branch (master) twice. Cloning from such a bundle resulted in
> a needless warning "warning: Duplicated ref: refs/remotes/origin/master".
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> bundle.c | 2 ++
> object.c | 19 +++++++++++++++++++
> object.h | 1 +
> 3 files changed, 22 insertions(+), 0 deletions(-)
Yes, that would be good. You have my ACK on that if you want.
Another thing I am thinking about on and off:
You cannot really use bundles as a replacement for regular transports
(e.g. when you administrator does not let you ssh or git:// out, and you
do not have an HTTP server available [*1*]).
Suppose you have two branches, 'master' and 'side'. Now you make changes
to 'master' and send the complete repository as a bundle to your friend.
Now you delete the branch 'side', and send the next bundle (created with
--all implying HEAD, and --since=$(stat -c %Y <first-bundle>)).
Then your friend has no idea if 'side' was deleted or untouched.
So I think we'd need some option for "create bundle" to list all specified
refs, and if they have not really changed, their SHA-1s as prerequisites,
too. Maybe "--full-bundle", or just "--full"?
Another problem: suppose you have a branch, called 'private', that you
excluded from your bundles. Now you happened to make changes to it, and
by mistake, the branch gets included in the incremental bundle. No
problem for you, as your friend lacks the prerequisites to reconstruct it.
But unfortunately, your friend cannot even pull 'master' from it, because
of our overzealous verification process which refuses all fetches when
some prerequisites are missing locally, even if they are not even needed.
This problem is much harder to solve, I think, and maybe we just want to
leave it: as bundles are just fed into index-pack --fix-thin, which has no
idea what objects can be skipped. Maybe there is no clean solution to
that to begin with.
Ciao,
Dscho
[*1*] When people are stuck behind such a stupidly restrictive firewall,
often people come with "helpful" suggestions to use a VPN, or to publish
your private repository, or get an external machine to HTTP proxy their
connections. I find it outright mean to waste the time of people who
already have a big problem.
However, I believe that a mail based bundle exchange should be a
relatively easy way out for those situations, once it works.
^ permalink raw reply
* Re: [PATCH] mergetool: put the cursor on the editable file for Vim
From: SZEDER Gábor @ 2009-01-18 14:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: markus.heidelberg, git
In-Reply-To: <7v7i4t4crp.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 17, 2009 at 05:35:22PM -0800, Junio C Hamano wrote:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> > When resolving conflicts, you only need to edit the $MERGED file. Put
> > the cursor automatically into its window for vimdiff and gvimdiff to
> > avoid doing <C-w>l every time.
>
> I think this is sensible.
>
> I do not use vim, and I do not know if the patch does what it claims to
> do, though.
It does.
Tested-by: SZEDER Gábor <szeder@ira.uka.de>
^ permalink raw reply
* Re: is gitosis secure?
From: Boyd Stephen Smith Jr. @ 2009-01-18 14:19 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
In-Reply-To: <87skngoifj.fsf@mid.deneb.enyo.de>
[-- Attachment #1: Type: text/plain, Size: 2114 bytes --]
On Sunday 18 January 2009, Florian Weimer <fw@deneb.enyo.de> wrote
about 'Re: is gitosis secure?':
>* Boyd Stephen Smith, Jr.:
>> On Sunday 18 January 2009, Florian Weimer <fw@deneb.enyo.de> wrote
>>
>> about 'Re: is gitosis secure?':
>>>* Sam Vilain:
>>>> Restricted unix shells are a technology which has been proven secure
>>>> for decades now.
>>>Huh? Things like scponly and rssh had their share of bugs, so I can
>>>see that there is some concern. (And restricted shells used to be
>>
>> From my understanding, a restricted shell is a difficult thing to
>> escape from unless a user is able to run binaries that they have
>> written. FWIW, I don't remember sftp or scponly having this particular
>> vulnerability.
>
>scponly issues due to interpretation conflicts:
Not sure all these apply, but I beleive some of them do, and I want to
leave the CVE numbers in case someone wants to look them up.
>CVE-2002-1469
>CVE-2004-1162
>CVE-2005-4533
>CVE-2007-6350
>CVE-2007-6415
>CVE-2004-1161
--- End of CVEs to investigate ---
>That's why I think it's not totally outlandish to assume that
>restricted shells are usually not very helpful for
>compartmentalization purposes.
I mostly agree with that statement. I make the assumption that, if the
user can login via ssh (even under "only" a restricted shell) they can do
anything a user in the same groups can do. I might be overestimating most
people, but I don't think I'm underestimating anyone. I do *hope* that I
get local privilege escalations patched before they are exploited, but I
can't guarantee that. (I'm not sure there's really anyway to guarantee
that, and I'd hate to upgrade a backup offline then replace the running
instance. Especially if I had to go back to when the local privilege
escalation was introduced [not just when it was "discovered"].)
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] http-push: update memory allocation for http headers
From: Mike Hommey @ 2009-01-18 14:20 UTC (permalink / raw)
To: Ray Chuan; +Cc: git
In-Reply-To: <be6fef0d0901180516q19327c18oa1d7ccc36ce3a87@mail.gmail.com>
On Sun, Jan 18, 2009 at 09:16:04PM +0800, Ray Chuan wrote:
> In 753bc91 (Remove the requirement opaquelocktoken uri scheme), the
> header strings were with the removal "opaquelocktoken:" (16
> characters).
>
> Unfortunately, this was without the corresponding change in memory
> allocation. In this patch we update these allocations.
>
> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
> ---
It would be better to just turn the whole thing to use strbuf, and/or
extend the patch set I sent earlier today to handle webdav.
Mike
^ permalink raw reply
* [PATCH 0/4] Clarifying the refspec documentation
From: Anders Melchiorsen @ 2009-01-18 14:36 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
This is a partial resend of some small updates to the git-push
refspec documentation. I have removed the parts of the patch
series that had comments last time, and will rework those later.
Meanwhile, I think that these simple modification do help in
making things more readable. Once you understand the refspec, it
is hard to realize how hard those few paragraphs are to digest.
Anders Melchiorsen (4):
Documentation: git push repository can also be a remote
Documentation: remove a redundant elaboration
Documentation: mention branches rather than heads
Documentation: avoid using undefined parameters
Documentation/git-push.txt | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
^ permalink raw reply
* [PATCH 4/4] Documentation: avoid using undefined parameters
From: Anders Melchiorsen @ 2009-01-18 14:36 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
In-Reply-To: <1232289418-25627-4-git-send-email-mail@cup.kalibalik.dk>
The <ref> parameter has not been introduced, so rewrite to
avoid it.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index a7a6f4c..7b27dc6 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -50,8 +50,8 @@ even if it does not result in a fast forward update.
+
`tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`.
+
-A parameter <ref> without a colon pushes the <ref> from the source
-repository to the destination repository under the same name.
+A lonely <src> parameter (without a colon and a destination) pushes
+the <src> to the same name in the destination repository.
+
Pushing an empty <src> allows you to delete the <dst> ref from
the remote repository.
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 1/4] Documentation: git push repository can also be a remote
From: Anders Melchiorsen @ 2009-01-18 14:36 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
In-Reply-To: <1232289418-25627-1-git-send-email-mail@cup.kalibalik.dk>
This is copied from pull-fetch-param.txt and helps the reader
to not get stuck in the URL section.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 3321966..8bfa7cb 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -28,7 +28,9 @@ OPTIONS
-------
<repository>::
The "remote" repository that is destination of a push
- operation. See the section <<URLS,GIT URLS>> below.
+ operation. This parameter can be either a URL
+ (see the section <<URLS,GIT URLS>> below) or the name
+ of a remote (see the section <<REMOTES,REMOTES>> below).
<refspec>...::
The canonical format of a <refspec> parameter is
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 2/4] Documentation: remove a redundant elaboration
From: Anders Melchiorsen @ 2009-01-18 14:36 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
In-Reply-To: <1232289418-25627-2-git-send-email-mail@cup.kalibalik.dk>
The comment in parentheses is wrong, as one has to leave out both the
colon and <dst>. This situation is covered by the section a few lines
down:
A parameter <ref> without a colon pushes the <ref> from the source
repository to the destination repository under the same name.
So, just remove the parentheses.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 8bfa7cb..6d3c711 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -44,8 +44,7 @@ tip of `master` branch); see linkgit:git-rev-parse[1]) that you
want to push. The <dst> side represents the destination location.
+
The local ref that matches <src> is used
-to fast forward the remote ref that matches <dst> (or, if no <dst> was
-specified, the same ref that <src> referred to locally). If
+to fast forward the remote ref that matches <dst>. If
the optional leading plus `+` is used, the remote ref is updated
even if it does not result in a fast forward update.
+
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
* [PATCH 3/4] Documentation: mention branches rather than heads
From: Anders Melchiorsen @ 2009-01-18 14:36 UTC (permalink / raw)
To: gitster; +Cc: git, Anders Melchiorsen
In-Reply-To: <1232289418-25627-3-git-send-email-mail@cup.kalibalik.dk>
Most of the git push page talks about branches, so make it consistent
also in this paragraph.
Signed-off-by: Anders Melchiorsen <mail@cup.kalibalik.dk>
---
Documentation/git-push.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index 6d3c711..a7a6f4c 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -57,8 +57,8 @@ Pushing an empty <src> allows you to delete the <dst> ref from
the remote repository.
+
The special refspec `:` (or `+:` to allow non-fast forward updates)
-directs git to push "matching" heads: for every head that exists on
-the local side, the remote side is updated if a head of the same name
+directs git to push "matching" branches: for every branch that exists on
+the local side, the remote side is updated if a branch of the same name
already exists on the remote side. This is the default operation mode
if no explicit refspec is found (that is neither on the command line
nor in any Push line of the corresponding remotes file---see below).
--
1.6.0.2.514.g23abd3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox