* [PATCH 3/5] Client side support for user-relative paths.
From: Andreas Ericsson @ 2005-11-17 19:37 UTC (permalink / raw)
To: git
With this patch, the client side passes identical paths for these two:
ssh://host.xz/~junio/repo
host.xz:~junio/repo
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
connect.c | 53 ++++++++++++++++++++++++++++++++---------------------
1 files changed, 32 insertions(+), 21 deletions(-)
applies-to: cd3bc724fea293b623abee6b0b4995560dd9f32e
c460d84cc8431089ddf6a888a418826ff8248509
diff --git a/connect.c b/connect.c
index c2badc7..73187a1 100644
--- a/connect.c
+++ b/connect.c
@@ -454,34 +454,45 @@ static int git_tcp_connect(int fd[2], co
int git_connect(int fd[2], char *url, const char *prog)
{
char command[1024];
- char *host, *path;
- char *colon;
+ char *host, *path = url;
+ char *colon = NULL;
int pipefd[2][2];
pid_t pid;
- enum protocol protocol;
+ enum protocol protocol = PROTO_LOCAL;
- host = NULL;
- path = url;
- colon = strchr(url, ':');
- protocol = PROTO_LOCAL;
- if (colon) {
- *colon = 0;
+ host = strstr(url, "://");
+ if(host) {
+ *host = '\0';
+ protocol = get_protocol(url);
+ host += 3;
+ path = strchr(host, '/');
+ }
+ else {
host = url;
- path = colon+1;
- protocol = PROTO_SSH;
- if (!memcmp(path, "//", 2)) {
- char *slash = strchr(path + 2, '/');
- if (slash) {
- int nr = slash - path - 2;
- memmove(path, path+2, nr);
- path[nr] = 0;
- protocol = get_protocol(url);
- host = path;
- path = slash;
- }
+ if ((colon = strchr(host, ':'))) {
+ protocol = PROTO_SSH;
+ *colon = '\0';
+ path = colon + 1;
}
}
+ if (!path || !*path)
+ die("No path specified. See 'man git-pull' for valid url syntax");
+
+ /*
+ * null-terminate hostname and point path to ~ for URL's like this:
+ * ssh://host.xz/~user/repo
+ */
+ if (protocol != PROTO_LOCAL && host != url) {
+ char *ptr = path;
+ if (path[1] == '~')
+ path++;
+ else
+ path = strdup(ptr);
+
+ *ptr = '\0';
+ }
+
if (protocol == PROTO_GIT)
return git_tcp_connect(fd, prog, host, path);
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 5/5] git-daemon support for user-relative paths.
From: Andreas Ericsson @ 2005-11-17 19:37 UTC (permalink / raw)
To: git
Dropped a fair amount of reundant code in favour of the library code
in path.c
Added option --strict-paths with documentation, with backwards
compatibility for whitelist entries with symlinks.
Everything that worked earlier still works insofar as I have
remembered testing it.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
Documentation/git-daemon.txt | 16 ++++
Documentation/pull-fetch-param.txt | 7 +-
daemon.c | 136 ++++++++++++++----------------------
3 files changed, 72 insertions(+), 87 deletions(-)
applies-to: d1e53de141c477b0b7dd2c6bd5897ea6239a7b20
4c4049426e6202bdb1429f5aeb4e5429df41c015
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 3783858..972e0e1 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -29,9 +29,15 @@ This is ideally suited for read-only upd
OPTIONS
-------
++--strict-paths::
+ Match paths exactly (i.e. don't allow "/foo/repo" when the real path is
+ "/foo/repo.git" or "/foo/repo/.git") and don't do user-relative paths.
+ git-daemon will refuse to start when this option is enabled and no
+ whitelist is specified.
+
--export-all::
Allow pulling from all directories that look like GIT repositories
- (have the 'objects' subdirectory and a 'HEAD' file), even if they
+ (have the 'objects' and 'refs' subdirectories), even if they
do not have the 'git-daemon-export-ok' file.
--inetd::
@@ -57,9 +63,15 @@ OPTIONS
--verbose::
Log details about the incoming connections and requested files.
+<directory>::
+ A directory to add to the whitelist of allowed directories. Unless
+ --strict-paths is specified this will also include subdirectories
+ of each named directory.
+
Author
------
-Written by Linus Torvalds <torvalds@osdl.org> and YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
+Written by Linus Torvalds <torvalds@osdl.org>, YOSHIFUJI Hideaki
+<yoshfuji@linux-ipv6.org> and the git-list <git@vger.kernel.org>
Documentation
--------------
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index a7628aa..6413d52 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -9,15 +9,16 @@
- http://host.xz/path/to/repo.git/
- https://host.xz/path/to/repo.git/
- git://host.xz/path/to/repo.git/
+- git://host.xz/~user/path/to/repo.git/
- ssh://host.xz/path/to/repo.git/
- ssh://host.xz/~user/path/to/repo.git/
- ssh://host.xz/~/path/to/repo.git
===============================================================
+
SSH Is the default transport protocol and also supports an
- scp-like syntax. Both syntaxes support username expansion.
- The following three are identical to the last three above,
- respectively:
+ scp-like syntax. Both syntaxes support username expansion,
+ as does the native git protocol. The following three are
+ identical to the last three above, respectively:
+
===============================================================
- host.xz:/path/to/repo.git/
diff --git a/daemon.c b/daemon.c
index 2b81152..ac4c94b 100644
--- a/daemon.c
+++ b/daemon.c
@@ -15,10 +15,11 @@ static int verbose;
static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all]\n"
-" [--timeout=n] [--init-timeout=n] [directory...]";
+" [--timeout=n] [--init-timeout=n] [--strict-paths] [directory...]";
/* List of acceptable pathname prefixes */
static char **ok_paths = NULL;
+static int strict_paths = 0;
/* If this is set, git-daemon-export-ok is not required */
static int export_all_trees = 0;
@@ -81,69 +82,56 @@ static void loginfo(const char *err, ...
va_end(params);
}
-static int path_ok(const char *dir)
+static char *path_ok(char *dir)
{
- const char *p = dir;
- char **pp;
- int sl, ndot;
+ char *path = enter_repo(dir, strict_paths);
- /* The pathname here should be an absolute path. */
- if ( *p++ != '/' )
- return 0;
-
- sl = 1; ndot = 0;
-
- for (;;) {
- if ( *p == '.' ) {
- ndot++;
- } else if ( *p == '\0' ) {
- /* Reject "." and ".." at the end of the path */
- if ( sl && ndot > 0 && ndot < 3 )
- return 0;
-
- /* Otherwise OK */
- break;
- } else if ( *p == '/' ) {
- /* Refuse "", "." or ".." */
- if ( sl && ndot < 3 )
- return 0;
- sl = 1;
- ndot = 0;
- } else {
- sl = ndot = 0;
- }
- p++;
+ if (!path) {
+ logerror("'%s': unable to chdir or not a git archive", dir);
+ return NULL;
}
if ( ok_paths && *ok_paths ) {
- int ok = 0;
+ char **pp = NULL;
int dirlen = strlen(dir);
+ int pathlen = strlen(path);
for ( pp = ok_paths ; *pp ; pp++ ) {
int len = strlen(*pp);
- if ( len <= dirlen &&
- !strncmp(*pp, dir, len) &&
- (dir[len] == '/' || dir[len] == '\0') ) {
- ok = 1;
- break;
+ /* because of symlinks we must match both what the
+ * user passed and the canonicalized path, otherwise
+ * the user can send a string matching either a whitelist
+ * entry or an actual directory exactly and still not
+ * get through */
+ if (len <= pathlen && !memcmp(*pp, path, len)) {
+ if (path[len] == '\0' || (!strict_paths && path[len] == '/'))
+ return path;
+ }
+ if (len <= dirlen && !memcmp(*pp, dir, len)) {
+ if (dir[len] == '\0' || (!strict_paths && dir[len] == '/'))
+ return path;
}
}
-
- if ( !ok )
- return 0; /* Path not in whitelist */
+ }
+ else {
+ /* be backwards compatible */
+ if (!strict_paths)
+ return path;
}
- return 1; /* Path acceptable */
+ logerror("'%s': not in whitelist", path);
+ return NULL; /* Fallthrough. Deny by default */
}
-static int set_dir(const char *dir)
+static int upload(char *dir)
{
- if (!path_ok(dir)) {
- errno = EACCES;
- return -1;
- }
+ /* Timeout as string */
+ char timeout_buf[64];
+ const char *path;
- if ( chdir(dir) )
+ loginfo("Request for '%s'", dir);
+
+ if (!(path = path_ok(dir)))
return -1;
/*
@@ -152,45 +140,17 @@ static int set_dir(const char *dir)
* We want a readable HEAD, usable "objects" directory, and
* a "git-daemon-export-ok" flag that says that the other side
* is ok with us doing this.
+ *
+ * path_ok() uses enter_repo() and does whitelist checking.
+ * We only need to make sure the repository is exported.
*/
+
if (!export_all_trees && access("git-daemon-export-ok", F_OK)) {
+ logerror("'%s': repository not exported.", path);
errno = EACCES;
return -1;
}
- if (access("objects/", X_OK) || access("HEAD", R_OK)) {
- errno = EINVAL;
- return -1;
- }
-
- /* If all this passed, we're OK */
- return 0;
-}
-
-static int upload(char *dir)
-{
- /* Try paths in this order */
- static const char *paths[] = { "%s", "%s/.git", "%s.git", "%s.git/.git", NULL };
- const char **pp;
- /* Enough for the longest path above including final null */
- int buflen = strlen(dir)+10;
- char *dirbuf = xmalloc(buflen);
- /* Timeout as string */
- char timeout_buf[64];
-
- loginfo("Request for '%s'", dir);
-
- for ( pp = paths ; *pp ; pp++ ) {
- snprintf(dirbuf, buflen, *pp, dir);
- if ( !set_dir(dirbuf) )
- break;
- }
-
- if ( !*pp ) {
- logerror("Cannot set directory '%s': %s", dir, strerror(errno));
- return -1;
- }
-
/*
* We'll ignore SIGTERM from now on, we have a
* good client.
@@ -200,7 +160,7 @@ static int upload(char *dir)
snprintf(timeout_buf, sizeof timeout_buf, "--timeout=%u", timeout);
/* git-upload-pack only ever reads stuff, so this is safe */
- execlp("git-upload-pack", "git-upload-pack", "--strict", timeout_buf, ".", NULL);
+ execlp("git-upload-pack", "git-upload-pack", "--strict", timeout_buf, path, NULL);
return -1;
}
@@ -216,7 +176,7 @@ static int execute(void)
if (len && line[len-1] == '\n')
line[--len] = 0;
- if (!strncmp("git-upload-pack /", line, 17))
+ if (!strncmp("git-upload-pack ", line, 16))
return upload(line+16);
logerror("Protocol error: '%s'", line);
@@ -617,6 +577,10 @@ int main(int argc, char **argv)
init_timeout = atoi(arg+15);
continue;
}
+ if (!strcmp(arg, "--strict-paths")) {
+ strict_paths = 1;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
@@ -631,6 +595,14 @@ int main(int argc, char **argv)
if (log_syslog)
openlog("git-daemon", 0, LOG_DAEMON);
+ if (strict_paths && (!ok_paths || !*ok_paths)) {
+ if (!inetd_mode)
+ die("git-daemon: option --strict-paths requires a whitelist");
+
+ logerror("option --strict-paths requires a whitelist");
+ exit (1);
+ }
+
if (inetd_mode) {
fclose(stderr); //FIXME: workaround
return execute();
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 1/5] Library code for user-relative paths, take three.
From: Andreas Ericsson @ 2005-11-17 19:37 UTC (permalink / raw)
To: git
See the threads "User-relative paths", "[RFC] GIT paths" and
"[PATCH 0/4] User-relative paths, take two" for previous discussions
on this topic.
This patch provides the work-horse of the user-relative paths feature,
using Linus' idea of a blind chdir() and getcwd() which makes it
remarkably simple.
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
cache.h | 1 +
path.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 73 insertions(+), 0 deletions(-)
applies-to: 8ff699dffc817e92fb2101f538f84c38d5ed0a0f
416ee0a4f47244471b52b9dc8aca3e984b20445f
diff --git a/cache.h b/cache.h
index 99afa2c..d8be06b 100644
--- a/cache.h
+++ b/cache.h
@@ -192,6 +192,7 @@ extern int diff_rename_limit_default;
/* Return a statically allocated filename matching the sha1 signature */
extern char *mkpath(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
+extern char *enter_repo(char *path, int strict);
extern char *git_path(const char *fmt, ...) __attribute__((format (printf, 1, 2)));
extern char *sha1_file_name(const unsigned char *sha1);
extern char *sha1_pack_name(const unsigned char *sha1);
diff --git a/path.c b/path.c
index 495d17c..5b61709 100644
--- a/path.c
+++ b/path.c
@@ -11,6 +11,7 @@
* which is what it's designed for.
*/
#include "cache.h"
+#include <pwd.h>
static char pathname[PATH_MAX];
static char bad_path[] = "/bad-path/";
@@ -89,3 +90,74 @@ char *safe_strncpy(char *dest, const cha
return dest;
}
+
+static char *current_dir()
+{
+ return getcwd(pathname, sizeof(pathname));
+}
+
+/* Take a raw path from is_git_repo() and canonicalize it using Linus'
+ * idea of a blind chdir() and getcwd(). */
+static const char *canonical_path(char *path, int strict)
+{
+ char *dir = path;
+
+ if(strict && *dir != '/')
+ return NULL;
+
+ if(*dir == '~') { /* user-relative path */
+ struct passwd *pw;
+ char *slash = strchr(dir, '/');
+
+ dir++;
+ /* '~/' and '~' (no slash) means users own home-dir */
+ if(!*dir || *dir == '/')
+ pw = getpwuid(getuid());
+ else {
+ if (slash) {
+ *slash = '\0';
+ pw = getpwnam(dir);
+ *slash = '/';
+ }
+ else
+ pw = getpwnam(dir);
+ }
+
+ /* make sure we got something back that we can chdir() to */
+ if(!pw || chdir(pw->pw_dir) < 0)
+ return NULL;
+
+ if(!slash || !slash[1]) /* no path following username */
+ return current_dir();
+
+ dir = slash + 1;
+ }
+
+ /* ~foo/path/to/repo is now path/to/repo and we're in foo's homedir */
+ if(chdir(dir) < 0)
+ return NULL;
+
+ return current_dir();
+}
+
+char *enter_repo(char *path, int strict)
+{
+ if(!path)
+ return NULL;
+
+ if(!canonical_path(path, strict)) {
+ if(strict || !canonical_path(mkpath("%s.git", path), strict))
+ return NULL;
+ }
+
+ /* This is perfectly safe, and people tend to think of the directory
+ * where they ran git-init-db as their repository, so humour them. */
+ (void)chdir(".git");
+
+ if(access("objects", X_OK) == 0 && access("refs", X_OK) == 0) {
+ putenv("GIT_DIR=.");
+ return current_dir();
+ }
+
+ return NULL;
+}
---
0.99.9.GIT
^ permalink raw reply related
* [PATCH 0/5] User-relative paths, take three.
From: Andreas Ericsson @ 2005-11-17 19:36 UTC (permalink / raw)
To: Git Mailing List
See the threads "User-relative paths", "[RFC] GIT paths" and
"[PATCH 0/4] User-relative paths, take two" for previous discussions
on this topic.
Perhaps this has simmered enough by now.
I've tested cloning, pulling and pushing with every possible valid and
invalid url'ish notation I could think of, including local.
Everything works, in spite of my not-so-stellar track record. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH 4/5] Documentation update for user-relative paths.
From: Andreas Ericsson @ 2005-11-17 19:37 UTC (permalink / raw)
To: git
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
Documentation/pull-fetch-param.txt | 29 ++++++++++++++++++++++++-----
1 files changed, 24 insertions(+), 5 deletions(-)
applies-to: bf9b22933b23acc5301a1e1adce47f70dd5f4ede
96781c24c886e2a563b5fb95bc9ec1073f92cb97
diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index ddd5823..a7628aa 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -5,11 +5,30 @@
to name the remote repository:
+
===============================================================
-- Rsync URL: rsync://remote.machine/path/to/repo.git/
-- HTTP(s) URL: http://remote.machine/path/to/repo.git/
-- git URL: git://remote.machine/path/to/repo.git/
-- ssh URL: remote.machine:/path/to/repo.git/
-- Local directory: /path/to/repo.git/
+- rsync://host.xz/path/to/repo.git/
+- http://host.xz/path/to/repo.git/
+- https://host.xz/path/to/repo.git/
+- git://host.xz/path/to/repo.git/
+- ssh://host.xz/path/to/repo.git/
+- ssh://host.xz/~user/path/to/repo.git/
+- ssh://host.xz/~/path/to/repo.git
+===============================================================
++
+ SSH Is the default transport protocol and also supports an
+ scp-like syntax. Both syntaxes support username expansion.
+ The following three are identical to the last three above,
+ respectively:
++
+===============================================================
+- host.xz:/path/to/repo.git/
+- host.xz:~user/path/to/repo.git/
+- host.xz:path/to/repo.git
+===============================================================
++
+ To sync with a local directory, use:
+
+===============================================================
+- /path/to/repo.git/
===============================================================
+
In addition to the above, as a short-hand, the name of a
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH 0/3] Support setting SymrefsOnly=true from scripts
From: Junio C Hamano @ 2005-11-17 19:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20051117120909.GA30496@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> The disadvantage is that I will have to maintain my own template for
> Cogito, which is silly - I would much rather just use GIT's default
> templates and only add the symrefonly option on behalf of Cogito.
That's very true. However I suspect Cogito users are expected
to run cg-admin-init not git-init-db, so admin-init can do
whatever postprocessing necessary after calling init-db? That
way would let you do more than what template would, I presume.
^ permalink raw reply
* Re: master has some toys
From: Junio C Hamano @ 2005-11-17 19:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511171249550.737@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I'd like to wait to have a reaction from other people. I vividly remember
> my eyes falling out of my sockets when somebody reported success on cygwin
> without NO_MMAP. If there is *any* cygwin version which fixes it, we
> should rather make people upgrade, no?
I am not so sure about forcing people upgrade, but we may end up
deciding it is better not to have NO_MMAP as the default. If
that turns out to be the case, I'd prefer to have something like
this instead:
diff --git a/Makefile b/Makefile
index 7ce62e8..215abf0 100644
--- a/Makefile
+++ b/Makefile
@@ -213,6 +213,10 @@ endif
ifeq ($(uname_O),Cygwin)
NO_STRCASESTR = YesPlease
NEEDS_LIBICONV = YesPlease
+ # There are conflicting reports about this.
+ # On some boxes NO_MMAP is needed, and not so elsewhere.
+ # Try uncommenting this if you see things break -- YMMV.
+ # NO_MMAP = YesPlease
NO_IPV6 = YesPlease
X = .exe
endif
^ permalink raw reply related
* Re: [PATCH] Add .git/version
From: Junio C Hamano @ 2005-11-17 19:25 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Martin Atukunda
In-Reply-To: <200511171644.48438.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> [*] Junio: This should be done before Git 1.0 - it is needed to be able
> to change the repository format in the future without taking the risk
> that old git commands possibly corrupt a repo in the new format. This
> has nothing to do with backwards compatibility. Without a version, we
> are forced to be forwards compatible ;-)
> Needed in init-db.c is a "echo 1 >.git/version"; and the mentioned check
> in the tools against this version.
I agree with the general direction.
- Futureproofing is good.
- We want repository-format-version but that may be too
long. Just saying version is a bit confusing. Abbreviating
it to repository-version makes it sound as if somebody took a
snapshot (i.e. tar-tree $commit). Whatever name we choose,
let's pick a one not so confusing.
- Not having .git/version (or whatever name) signals the tools
our repository is in the original format. This will keep the
existing repositories happy. What this means is that the
tools need to check for the absense of .git/version in this
round. When we change the repository format, we will have
.git/version file that records it.
- You can run git-init-db on an existing repository. This is
sometimes handy if you added a new hook in the template suite
and want to copy it over (it never overwrites but happily
copies what you do not have). This mechanism needs to be
told about the version file -- specifically, it should check
version in the template area and refuse to do use that
template if it does not match the repository. Similarly,
when creating a repository from scratch, it should not copy
the version file from templates.
^ permalink raw reply
* [PATCH] Add .git/version (Take 2)
From: Martin Atukunda @ 2005-11-17 19:18 UTC (permalink / raw)
To: git
In-Reply-To: <20051117190848.GA5745@igloo.ds.co.ug>
Currently the version number can be considered version 1, so this patch
just sets it to that. This patch supercedes my earlier attempt that
erroneously used the git version number as the repo format version.
Signed-Off-By: Martin Atukunda <matlads@dsmagic.com>
---
init-db.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
applies-to: d1bb16b919a119cca6ee001f755f83251a2c2964
31e78e387d708da5e09f40436d5fdc9e9ec5e16c
diff --git a/init-db.c b/init-db.c
index bd88291..e403dac 100644
--- a/init-db.c
+++ b/init-db.c
@@ -9,6 +9,8 @@
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates/"
#endif
+#define REPO_VERSION 1
+
static void safe_create_dir(const char *dir)
{
if (mkdir(dir, 0777) < 0) {
@@ -19,6 +21,17 @@ static void safe_create_dir(const char *
}
}
+static void record_repo_version(const char *path)
+{
+ FILE *verfile = fopen(path, "w");
+ if (!verfile)
+ die ("Can not write to %s?", path);
+
+ fprintf(verfile, "%d\n", REPO_VERSION);
+
+ fclose(verfile);
+}
+
static int copy_file(const char *dst, const char *src, int mode)
{
int fdi, fdo, status;
@@ -212,6 +225,10 @@ static void create_default_files(const c
fprintf(stderr, "Ignoring file modes\n");
}
}
+
+ /* record the version of the git repo */
+ strcpy(path + len, "version");
+ record_repo_version(path);
}
static const char init_db_usage[] =
---
0.99.9.GIT
--
Due to a shortage of devoted followers, the production of great leaders has been discontinued.
^ permalink raw reply related
* Re: [PATCH] Add .git/version
From: Martin Atukunda @ 2005-11-17 19:08 UTC (permalink / raw)
To: git
In-Reply-To: <200511171741.23147.Josef.Weidendorfer@gmx.de>
On Thu, Nov 17, 2005 at 05:41:23PM +0100, Josef Weidendorfer wrote:
> On Thursday 17 November 2005 17:33, Andreas Ericsson wrote:
> > > Why? Ideally, the git commands first should check if they can handle the
> > > repository format. If they can not handle the version, they should bail
> > > out with an error [*]
> > > Now suppose we want to release Git 2 without change the repository
> > > format at all. Thus, even if Git 1 tool *would* work with repositories
> > > created by Git 2, they will fail in the version check!
> > >
> >
> > Not that I have an opinion on these changes, but Netscape 7 still
> > handles HTTP 1.1. Just because we up the major-number for git doesn't
> > mean we have to do the same for the repository format version.
>
> Of course we do not want that.
> My comment was about this, as the proposed patch installed a
> .git/version file with the git version in it, which would lead to
> this strange result.
>
I agree, I'll resubmit a patch to create a .git/version file that simply
says 1.
which specific git commands would most likely want to know about the
version of the repo format? I could look at them to see what needs to be
changed so that they don't corrupt a repo, or as Johannes said, the use
of this file would become handy only when an incompatible change is
made. In which case, init-db.c just creates it for now, as a simple safe
guard.
- Martin -
--
Due to a shortage of devoted followers, the production of great leaders has been discontinued.
^ permalink raw reply
* Re: [BUG] git-svnimport doesn't import actual code
From: Matthias Urlichs @ 2005-11-17 17:05 UTC (permalink / raw)
To: git
In-Reply-To: <20051117160645.GA26871@lumumba.uhasselt.be>
Hi, Panagiotis Issaris wrote:
> git-svnimport -v svn://svn.berlios.de/rtnet/trunk
That's easy -- you can't svn-pull the trunk that way.
(Note that you got a lot of "skipped" messages...)
Just drop the "trunk", add a "-b branches" if that repository
needs it, and svnimport will handle it.
ASIDE: All the repositories in my import list need that flag, so I am
considering changing the default name from "branch" to "branches".
Objections, anybody?
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
It is impossible to travel faster than light, and certainly not desirable,
as one's hat keeps blowing off.
-- Woody Allen
^ permalink raw reply
* Re: git and cogito update, gitweb problem
From: Junio C Hamano @ 2005-11-17 17:11 UTC (permalink / raw)
To: Nico -telmich- Schottelius; +Cc: git
In-Reply-To: <20051117142324.GD16963@schottelius.org>
Nico -telmich- Schottelius <nico-linux-git@schottelius.org> writes:
> Junio C Hamano [Thu, Nov 10, 2005 at 09:52:36AM -0800]:
>> [...]
>> I think this minimally should fix it [...]
>
> Will try that the next days!
I think gitweb upstream has independently dealing with it in its
recent updates.
^ permalink raw reply
* Re: fix git-pack-redundant crashing sometimes
From: Matthias Urlichs @ 2005-11-17 16:56 UTC (permalink / raw)
To: git
In-Reply-To: <437BC7D1.1070605@etek.chalmers.se>
Hi, Lukas Sandström wrote:
> After doing some maths; actually it is very exponential. 2**n - 1 to be precise.
In the general case, yes. However, you can just sort the packs by date
and sequentially drop all that can be dropped. That's not optimal in the
general case, but for us it should be close enough.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
When was the last time you were drunk?
^ permalink raw reply
* [RFC] Using sticky directories to control access to branches.
From: Carl Baldwin @ 2005-11-17 17:01 UTC (permalink / raw)
To: git
I had a thought this morning. I wanted to use file permissions to
control access to push to a particular branch in a repository in order
to implement some sort of per-branch policy. This assumes that there is
a repository setup into which multiple users can push.
My goals were to be able to...
a) allow only one user (or possibly one group) access to modify a
branch. Do this on per-branch basis.
b) Freeze tags so that they *cannot* be accidentally updated by a push.
My plan to accomplish this was to set the sticky bit (chmod +t) on the
refs/heads and refs/tags directories so that users couldn't bypass
file-permissions by replacing the file with their own. Then grant write
permission to the owner (or possibly a group) to allow updates to that
branch.
I started testing this with git v0.99.9i and found that git push
actually creates a new file and replaces the old branch file with the
new one. The consequence for me is that when I set the sticky bit on
the heads directory then all of the branches restrict access solely to
the owner of the file since only the owner will be able to replace it.
This precludes giving a group write access to the branch. It also
precludes leaving most of the branches open to all users by default.
Now, git was probably designed to do this on purpose because it is the
safest way to update a branch in an automic way. But, I wonder if there
is another way. Maybe, git could make a temporary backup of the branch
doing something like this:
% cp refs/heads/master{,.$randomstring}
(on success, go ahead and edit refs/heads/master in place)
(on success, remove refs/heads/master.$randomstring
Something like this could still be pretty safe but would allow
per-branch access restrictions using unix file permissions.
Carl
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: Carl.N.Baldwin@hp.com
Fort Collins, CO 80525 home: Carl@ecBaldwin.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
^ permalink raw reply
* Re: [PATCH] Add .git/version
From: Josef Weidendorfer @ 2005-11-17 16:41 UTC (permalink / raw)
To: git
In-Reply-To: <437CB0CA.6070306@op5.se>
On Thursday 17 November 2005 17:33, Andreas Ericsson wrote:
> > Why? Ideally, the git commands first should check if they can handle the
> > repository format. If they can not handle the version, they should bail
> > out with an error [*]
> > Now suppose we want to release Git 2 without change the repository
> > format at all. Thus, even if Git 1 tool *would* work with repositories
> > created by Git 2, they will fail in the version check!
> >
>
> Not that I have an opinion on these changes, but Netscape 7 still
> handles HTTP 1.1. Just because we up the major-number for git doesn't
> mean we have to do the same for the repository format version.
Of course we do not want that.
My comment was about this, as the proposed patch installed a
.git/version file with the git version in it, which would lead to
this strange result.
Josef
^ permalink raw reply
* Re: [PATCH] Add .git/version
From: Andreas Ericsson @ 2005-11-17 16:33 UTC (permalink / raw)
To: git
In-Reply-To: <200511171644.48438.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
> On Thursday 17 November 2005 14:25, Martin Atukunda wrote:
>
> As .git/version is part of the repository, it should contain the version
> of the repository format used. Do you really want to link the version
> of the repository format with the version of git which created the
> repository? It think it is better to detach a repository version from
> version of git.
>
> Why? Ideally, the git commands first should check if they can handle the
> repository format. If they can not handle the version, they should bail
> out with an error [*]
> Now suppose we want to release Git 2 without change the repository
> format at all. Thus, even if Git 1 tool *would* work with repositories
> created by Git 2, they will fail in the version check!
>
Not that I have an opinion on these changes, but Netscape 7 still
handles HTTP 1.1. Just because we up the major-number for git doesn't
mean we have to do the same for the repository format version.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [QUESTION] Access to a huge GIT repository.
From: Linus Torvalds @ 2005-11-17 16:23 UTC (permalink / raw)
To: Franck; +Cc: Git Mailing List
In-Reply-To: <cda58cb80511170236p4a7e2baay@mail.gmail.com>
On Thu, 17 Nov 2005, Franck wrote:
>
> Sorry, I forget to tell that I have already tried what you suggested
> at first (except that I did not do a 'git repack -a -d') but it didn't
> work out (and that the reason why I tried the "kill father object"
> thing).
If that didn't work, then you can't kill the father object: it will not
only just get rid of one single object, but it will make fsck unhappy that
your tree is incomplete.
What you probably _can_ do is to find whatever top-most commit you want
(say, the v2.6.0 commit), and use grafting to make that have no parents.
Then you can do git-prune to get rid of everything under it.
> Since I forgot the repack thing, I retried again, and it did
> last more than 4 hours to cpmplete all git commands.
Sounds like the original archive was fully unpacked. That really does get
very very slow after a while.
> After that I run
> gitk --all to check that all old branch's objects have been removed
> but I can see all of them.
Note that if the branches are still there, git prune won't do anything to
them (and git repack will pack them all). You need to remove the branches
_first_, so that git repack and prune sees that their objects aren't
needed.
But yes, if the tree is actually based on some full CVS history and really
goes back all the way to 1995, then you can't prune it (since all branches
are actually part of the history from the very top), and you'd need to
graft away part of it like above.
Linus
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Johannes Schindelin @ 2005-11-17 16:22 UTC (permalink / raw)
To: Nick Hengeveld; +Cc: Andrew Wozniak, git
In-Reply-To: <20051117155709.GD3968@reactrix.com>
Hi,
On Thu, 17 Nov 2005, Nick Hengeveld wrote:
> On Thu, Nov 17, 2005 at 01:00:19PM +0100, Johannes Schindelin wrote:
>
> > Note that I had no success making http-fetch work without USE_CURL_MULTI.
> > So maybe you can compile it, but maybe you experience the same problems as
> > I had.
>
> http-fetch or http-push?
Oops. IIRC it was when I was playing with http-push.
Sorry,
Dscho
^ permalink raw reply
* Re: [PATCH 0/3] Support setting SymrefsOnly=true from scripts
From: Petr Baudis @ 2005-11-17 12:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7v8xvpe6vi.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Wed, Nov 16, 2005 at 02:09:05AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - copy the template; if the commandline specifies where the
> templates are, take them from there otherwise use the
> built-in location.
The disadvantage is that I will have to maintain my own template for
Cogito, which is silly - I would much rather just use GIT's default
templates and only add the symrefonly option on behalf of Cogito.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [BUG] git-svnimport doesn't import actual code
From: Panagiotis Issaris @ 2005-11-17 16:06 UTC (permalink / raw)
To: git
Hi,
When importing a Subversion tree into a GIT tree using git-svnimport I
ended up with a git tree containing the number of expected commits,
complete with logmessages and timestamps, but no files showed up.
Using gitk shows me a large list of commits, but again, no diffs show
up. Using "cg-log -f" shows all the commits, but no files are shown
related to the commits.
This was the command used to import the Subversion repository:
git-svnimport -v svn://svn.berlios.de/rtnet/trunk
Here's a screenshot of gitk viewing the GIT-repository:
http://flickr.com/photos/takis/64214074/
With friendly regards,
Takis
--
OpenPGP key: http://issaris.org/~takis/takis_public_key.txt
fingerprint: 6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 E029
^ permalink raw reply
* Re: "make test" fails with current HEAD
From: Matthias Urlichs @ 2005-11-17 16:03 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511171652020.17402@wbgn013.biozentrum.uni-wuerzburg.de>
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
Hi,
Johannes Schindelin:
> Does not fail here.
>
Does fail here...
> Did you set your GIT_EXEC_PATH?
>
Yes. :-/
I'll dig.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
"Today, the theory of evolution is an accepted fact for everyone but
a fundamentalist minority, whose objections are based not on reasoning
but on doctrinaire adherence to religious principles."
[Dr. James D. Watson, winner of the Nobel prize
for his co-discovery of the structure of DNA]
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Add .git/version
From: Josef Weidendorfer @ 2005-11-17 16:04 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0511171634460.17319@wbgn013.biozentrum.uni-wuerzburg.de>
On Thursday 17 November 2005 16:38, Johannes Schindelin wrote:
> But yes, it might be handy to know at some time. But I think it would make
> sense to add .git/version *then*, because you can distinguish repositories
> before/after the change by testing for .git/version.
No, as old git tools then still could corrupt a repository with a new format,
as they currently do not check any kind of format version; it would work if
the git 1 tools would bail out if a .git/version is found ;-)
Josef
^ permalink raw reply
* Re: recent patch breaks the build ?
From: Nick Hengeveld @ 2005-11-17 15:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Andrew Wozniak, git
In-Reply-To: <Pine.LNX.4.63.0511171258440.2104@wbgn013.biozentrum.uni-wuerzburg.de>
On Thu, Nov 17, 2005 at 01:00:19PM +0100, Johannes Schindelin wrote:
> Note that I had no success making http-fetch work without USE_CURL_MULTI.
> So maybe you can compile it, but maybe you experience the same problems as
> I had.
http-fetch or http-push?
--
For a successful technology, reality must take precedence over public
relations, for nature cannot be fooled.
^ permalink raw reply
* Re: "make test" fails with current HEAD
From: Johannes Schindelin @ 2005-11-17 15:52 UTC (permalink / raw)
To: Matthias Urlichs; +Cc: git
In-Reply-To: <pan.2005.11.17.15.31.56.755022@smurf.noris.de>
Hi,
On Thu, 17 Nov 2005, Matthias Urlichs wrote:
> t4103.sh:
>
> fatal: patch with only garbage at line 30
> * FAIL 7: check binary diff with replacement.
> git-checkout master
> git-apply --check --allow-binary-replacement BF.diff
Does not fail here.
Did you set your GIT_EXEC_PATH?
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Add .git/version
From: Josef Weidendorfer @ 2005-11-17 15:44 UTC (permalink / raw)
To: git; +Cc: Martin Atukunda, Junio C Hamano
In-Reply-To: <11322339372137-git-send-email-matlads@dsmagic.com>
On Thursday 17 November 2005 14:25, Martin Atukunda wrote:
> This patch series attempts to add .git/version support to init-db.c. THis
> is an overview of the patches.
As .git/version is part of the repository, it should contain the version
of the repository format used. Do you really want to link the version
of the repository format with the version of git which created the
repository? It think it is better to detach a repository version from
version of git.
Why? Ideally, the git commands first should check if they can handle the
repository format. If they can not handle the version, they should bail
out with an error [*]
Now suppose we want to release Git 2 without change the repository
format at all. Thus, even if Git 1 tool *would* work with repositories
created by Git 2, they will fail in the version check!
If this is meant to be used in scripts (as your commit comment mentions):
a script should never touch any files in the repository directly, but go
via commands supplied with git. So these scripts should actually check
against the version of installed git. Thus, such a version string should go
into git-var or better simply use the existing "git --version"?
Josef
[*] Junio: This should be done before Git 1.0 - it is needed to be able
to change the repository format in the future without taking the risk
that old git commands possibly corrupt a repo in the new format. This
has nothing to do with backwards compatibility. Without a version, we
are forced to be forwards compatible ;-)
Needed in init-db.c is a "echo 1 >.git/version"; and the mentioned check
in the tools against this version.
^ permalink raw reply
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