* [PATCH] send-pack: reword non-fast-forward error message.
From: Junio C Hamano @ 2005-12-22 20:41 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Johannes Schindelin
In-Reply-To: <7vek45lyor.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Andreas Ericsson <ae@op5.se> writes:
>
>> Junio C Hamano wrote:
>>> In a sense, both are "pull first?" situation, and it probably is
>>> more confusing to give different messages to the user in these
>>> two cases. From the end-user point of view they are the same
>>> "remote is not strict subset.".
>>
>> In non-git'ish, does this mean "you're not up to date, so pull before
>> pushing" ? If so, why not say so? I'm sure it could prevent a fair few
>> problems for users (not least those new to scm's).
That is reasonable. How about this?
-- >8 --
Wnen refusing to push a head, we said cryptic "remote 'branch'
object X does not exist on local" or "remote ref 'branch' is not
a strict subset of local ref 'branch'". That was gittish.
Since the most likely reason this happens is because the pushed
head was not up-to-date, clarify the error message to say that
straight, and suggest pulling first.
First noticed by Johannes and seconded by Andreas.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
send-pack.c | 30 ++++++++++++++----------------
1 files changed, 14 insertions(+), 16 deletions(-)
69310a34cb6dcca32b08cf3ea9e91ab19354a874
diff --git a/send-pack.c b/send-pack.c
index 5bc2f01..0d41f9a 100644
--- a/send-pack.c
+++ b/send-pack.c
@@ -231,23 +231,21 @@ static int send_pack(int in, int out, in
if (!force_update &&
!is_zero_sha1(ref->old_sha1) &&
!ref->force) {
- if (!has_sha1_file(ref->old_sha1)) {
- error("remote '%s' object %s does not "
- "exist on local",
- ref->name, sha1_to_hex(ref->old_sha1));
- ret = -2;
- continue;
- }
-
- /* We assume that local is fsck-clean. Otherwise
- * you _could_ have an old tag which points at
- * something you do not have, which may or may not
- * be a commit.
- */
- if (!ref_newer(ref->peer_ref->new_sha1,
+ if (!has_sha1_file(ref->old_sha1) ||
+ !ref_newer(ref->peer_ref->new_sha1,
ref->old_sha1)) {
- error("remote ref '%s' is not a strict "
- "subset of local ref '%s'.", ref->name,
+ /* We do not have the remote ref, or
+ * we know that the remote ref is not
+ * an ancestor of what we are trying to
+ * push. Either way this can be losing
+ * commits at the remote end and likely
+ * we were not up to date to begin with.
+ */
+ error("remote '%s' is not a strict "
+ "subset of local ref '%s'. "
+ "maybe you are not up-to-date and "
+ "need to pull first?",
+ ref->name,
ref->peer_ref->name);
ret = -2;
continue;
--
1.0.GIT
^ permalink raw reply related
* Re: [PATCH] sha1_to_hex: properly terminate the SHA1
From: Junio C Hamano @ 2005-12-22 20:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0512221854550.20025@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> sha1_to_hex() returns a pointer to a static buffer. Some of its users
> modify that buffer by appending a newline character. Other users rely
> on the fact that you can call
>
> printf("%s", sha1_to_hex(sha1));
>
> Just to be on the safe side, terminate the SHA1 in sha1_to_hex().
Good catch, thanks. The worst one is:
diff.c:727: memcpy(one_sha1, sha1_to_hex(one->sha1), 41);
^ permalink raw reply
* Re: [PATCH] send-pack: reword non-fast-forward error message.
From: Johannes Schindelin @ 2005-12-22 20:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vu0d0j24z.fsf_-_@assigned-by-dhcp.cox.net>
Hi,
On Thu, 22 Dec 2005, Junio C Hamano wrote:
> That is reasonable. How about this?
I like it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] whatchanged: customize diff-tree output
From: Alex Riesen @ 2005-12-22 21:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0512221200190.7112@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Thu, Dec 22, 2005 12:16:00 +0100:
> > I'm certainly ok with the short format by default. And making it
> > configurable per repo sounds fine, although at the same time I wonder if
> > that perhaps confuses people more (something that works in one project one
> > way works subtly differently in another project..)
>
> I cannot think of a saner way to have an overridable policy. Just provide
> a template config, and you're done. Everyone gets those flags per default,
> and if someone does not like it: go ahead, change it yourself!
>
> Besides, you are usually calling git-whatchanged in your private working
> tree, where not many people can change the config.
>
That's the point, isn't it? A script from ~user1/bin, which calls
git-whatchanged suddenly stops working in ~user2/repo.
Besides, how can user1 know what he has to specify to git-whatchanged
(I assume the command line overrides .git/config) so that his script
works everywhere?
Maybe such configuration better left to environment variables?
^ permalink raw reply
* Re: [PATCH] git-clone-pack: do not silently overwrite an existing branch 'origin'
From: Junio C Hamano @ 2005-12-22 21:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0512221859110.20025@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When cloning a repository which already contains a branch called 'origin',
> do not silently overwrite it with the remote 'master' ref.
If we consider the "origin is special and is used to track
upstream" convention pretty much ingrained, then unconditionally
overwriting origin without saying anything is the right
approach. After all, you do not care what upstream your
upstream is keeping track of, and you would want to use 'origin'
for the usual purpose of keeping track of upstream.
Otherwise, if we do not treat "origin" specially, we could
do something like this. If "origin" exists, then we do not
overwrite upon clone, nor subsequent fetch.
I have a mild aversion to this change, though. I'd much prefer
the third approach I am too lazy to code, which lets you say
what local branch name instead of 'origin' to keep track of
upstream from 'git clone' command line.
---
diff --git a/git-clone.sh b/git-clone.sh
index 280cc2e..edebee7 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -206,17 +206,22 @@ then
refs/heads/*)
head_points_at=`expr "$head_points_at" : 'refs/heads/\(.*\)'`
mkdir -p .git/remotes &&
- echo >.git/remotes/origin \
- "URL: $repo
-Pull: $head_points_at:origin" &&
- cp ".git/refs/heads/$head_points_at" .git/refs/heads/origin &&
+ echo "URL: $repo" >.git/remotes/origin &&
+ if test -f ".git/refs/heads/origin"
+ then
+ echo "Pull: $head_points_at:"
+ else
+ echo "Pull: $head_points_at:origin"
+ cp ".git/refs/heads/$head_points_at" \
+ .git/refs/heads/origin &&
+ fi >>.git/remotes/origin &&
find .git/refs/heads -type f -print |
while read ref
do
- head=`expr "$ref" : '.git/refs/heads/\(.*\)'` &&
- test "$head_points_at" = "$head" ||
- test "origin" = "$head" ||
- echo "Pull: ${head}:${head}"
+ head=`expr "$ref" : '.git/refs/heads/\(.*\)'` &&
+ test "$head_points_at" = "$head" ||
+ test "origin" = "$head" ||
+ echo "Pull: ${head}:${head}"
done >>.git/remotes/origin
esac
^ permalink raw reply related
* [PATCH] Introduce core.sharedrepository
From: Johannes Schindelin @ 2005-12-22 22:13 UTC (permalink / raw)
To: git, junkio
This is the second attempt, after Junio convinced me that my simple approach
to set umask was misguided.
If the config variable 'core.sharedrepository' is set, the directories
$GIT_DIR/objects/
$GIT_DIR/objects/??
$GIT_DIR/objects/pack
$GIT_DIR/refs
$GIT_DIR/refs/heads
$GIT_DIR/refs/heads/tags
are set group writable (and g+s, since the git group may be not the primary
group of all users).
Since all files are written as lock files first,
and then moved to their destination, they do not have to be group writable.
Indeed, if this leads to problems you found a bug.
Note that -- as in my first attempt -- the config variable is set in the
function which checks the repository format. If this were done in
git_default_config instead, a lot of programs would need to be modified
to call git_config(git_default_config) first.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
cache.h | 1 +
setup.c | 4 ++++
sha1_file.c | 21 +++++++++++++++++++++
3 files changed, 26 insertions(+), 0 deletions(-)
1a164f16e90378ba66e70e6082266645d3b45c57
diff --git a/cache.h b/cache.h
index cb87bec..0f875dd 100644
--- a/cache.h
+++ b/cache.h
@@ -159,6 +159,7 @@ extern void rollback_index_file(struct c
extern int trust_executable_bit;
extern int only_use_symrefs;
extern int diff_rename_limit_default;
+extern int shared_repository;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/setup.c b/setup.c
index d3556ed..3de372e 100644
--- a/setup.c
+++ b/setup.c
@@ -1,5 +1,7 @@
#include "cache.h"
+int shared_repository = 0;
+
const char *prefix_path(const char *prefix, int len, const char *path)
{
const char *orig = path;
@@ -180,6 +182,8 @@ int check_repository_format_version(cons
{
if (strcmp(var, "core.repositoryformatversion") == 0)
repository_format_version = git_config_int(var, value);
+ else if (strcmp(var, "core.sharedrepository") == 0)
+ shared_repository = git_config_bool(var, value);
return 0;
}
diff --git a/sha1_file.c b/sha1_file.c
index d451a94..e109a07 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -48,6 +48,21 @@ int get_sha1_hex(const char *hex, unsign
return 0;
}
+static int make_group_writable(const char *path)
+{
+ struct stat st;
+
+ if (lstat(path, &st) < 0)
+ return -1;
+ if (st.st_mode & S_IWUSR)
+ st.st_mode |= S_IWGRP;
+ if (S_ISDIR(st.st_mode))
+ st.st_mode |= S_ISGID;
+ if (chmod(path, st.st_mode) < 0)
+ return -2;
+ return 0;
+}
+
int safe_create_leading_directories(char *path)
{
char *pos = path;
@@ -64,6 +79,10 @@ int safe_create_leading_directories(char
*pos = '/';
return -1;
}
+ if (shared_repository && make_group_writable(path)) {
+ *pos = '/';
+ return -2;
+ }
*pos++ = '/';
}
return 0;
@@ -1241,6 +1260,8 @@ static int link_temp_to_file(const char
if (dir) {
*dir = 0;
mkdir(filename, 0777);
+ if (shared_repository && make_group_writable(filename))
+ return -2;
*dir = '/';
if (!link(tmpfile, filename))
return 0;
--
1.0.GIT
^ permalink raw reply related
* [PATCH] git-init-db: initialize shared repositories with --shared
From: Johannes Schindelin @ 2005-12-22 22:19 UTC (permalink / raw)
To: git, junkio
Now you can say
git-init-db --shared
if you want other users to be able to push into that repository.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
So, I lied in my last message. This patch actually changes the
modes of the $GIT_DIR/{objects,objects/pack,refs,refs/heads,
refs/tags} directories.
I just forgot to commit this before sending the patch :-(
cache.h | 1 +
init-db.c | 36 ++++++++++++++++++++++++++----------
sha1_file.c | 2 +-
3 files changed, 28 insertions(+), 11 deletions(-)
e60956946509622bda221cea567f841568f4cd20
diff --git a/cache.h b/cache.h
index 0f875dd..63acc72 100644
--- a/cache.h
+++ b/cache.h
@@ -184,6 +184,7 @@ extern const unsigned char null_sha1[20]
int git_mkstemp(char *path, size_t n, const char *template);
+int make_group_writable(const char *path);
int safe_create_leading_directories(char *path);
char *safe_strncpy(char *, const char *, size_t);
char *enter_repo(char *path, int strict);
diff --git a/init-db.c b/init-db.c
index c58b92d..b66b5cd 100644
--- a/init-db.c
+++ b/init-db.c
@@ -9,7 +9,7 @@
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates/"
#endif
-static void safe_create_dir(const char *dir)
+static void safe_create_dir(const char *dir, int share)
{
if (mkdir(dir, 0777) < 0) {
if (errno != EEXIST) {
@@ -17,6 +17,11 @@ static void safe_create_dir(const char *
exit(1);
}
}
+
+ if (shared_repository && share && make_group_writable(dir)) {
+ fprintf(stderr, "Could not make %s writable by group\n", dir);
+ exit(2);
+ }
}
static int copy_file(const char *dst, const char *src, int mode)
@@ -32,6 +37,11 @@ static int copy_file(const char *dst, co
}
status = copy_fd(fdi, fdo);
close(fdo);
+
+ if (shared_repository && !status && (mode & 0200) &&
+ make_group_writable(dst))
+ return -1;
+
return status;
}
@@ -48,7 +58,7 @@ static void copy_templates_1(char *path,
* with the way the namespace under .git/ is organized, should
* be really carefully chosen.
*/
- safe_create_dir(path);
+ safe_create_dir(path, 0);
while ((de = readdir(dir)) != NULL) {
struct stat st_git, st_template;
int namelen;
@@ -176,11 +186,11 @@ static void create_default_files(const c
* Create .git/refs/{heads,tags}
*/
strcpy(path + len, "refs");
- safe_create_dir(path);
+ safe_create_dir(path, 1);
strcpy(path + len, "refs/heads");
- safe_create_dir(path);
+ safe_create_dir(path, 1);
strcpy(path + len, "refs/tags");
- safe_create_dir(path);
+ safe_create_dir(path, 1);
/* First copy the templates -- we might have the default
* config file there, in which case we would want to read
@@ -220,7 +230,7 @@ static void create_default_files(const c
}
static const char init_db_usage[] =
-"git-init-db [--template=<template-directory>]";
+"git-init-db [--template=<template-directory>] [--shared]";
/*
* If you want to, you can share the DB area with any number of branches.
@@ -239,6 +249,8 @@ int main(int argc, char **argv)
char *arg = argv[1];
if (!strncmp(arg, "--template=", 11))
template_dir = arg+11;
+ else if (!strcmp(arg, "--shared"))
+ shared_repository = 1;
else
die(init_db_usage);
}
@@ -251,7 +263,7 @@ int main(int argc, char **argv)
git_dir = DEFAULT_GIT_DIR_ENVIRONMENT;
fprintf(stderr, "defaulting to local storage area\n");
}
- safe_create_dir(git_dir);
+ safe_create_dir(git_dir, 0);
/* Check to see if the repository version is right.
* Note that a newly created repository does not have
@@ -270,10 +282,14 @@ int main(int argc, char **argv)
path = xmalloc(len + 40);
memcpy(path, sha1_dir, len);
- safe_create_dir(sha1_dir);
+ safe_create_dir(sha1_dir, 1);
strcpy(path+len, "/pack");
- safe_create_dir(path);
+ safe_create_dir(path, 1);
strcpy(path+len, "/info");
- safe_create_dir(path);
+ safe_create_dir(path, 0);
+
+ if (shared_repository)
+ git_config_set("core.sharedRepository", "true");
+
return 0;
}
diff --git a/sha1_file.c b/sha1_file.c
index e109a07..10d63f1 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -48,7 +48,7 @@ int get_sha1_hex(const char *hex, unsign
return 0;
}
-static int make_group_writable(const char *path)
+int make_group_writable(const char *path)
{
struct stat st;
--
1.0.GIT
^ permalink raw reply related
* Re: [PATCH] whatchanged: customize diff-tree output
From: Johannes Schindelin @ 2005-12-22 22:24 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20051222210620.GA4679@steel.home>
Hi,
On Thu, 22 Dec 2005, Alex Riesen wrote:
> A script from ~user1/bin, which calls git-whatchanged suddenly stops
> working in ~user2/repo.
> [...]
>
> Maybe such configuration better left to environment variables?
And that makes the script not stop how?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-clone-pack: do not silently overwrite an existing branch 'origin'
From: Johannes Schindelin @ 2005-12-22 22:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu0d0hm53.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 22 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > When cloning a repository which already contains a branch called 'origin',
> > do not silently overwrite it with the remote 'master' ref.
>
> If we consider the "origin is special and is used to track
> upstream" convention pretty much ingrained, then unconditionally
> overwriting origin without saying anything is the right
> approach. After all, you do not care what upstream your
> upstream is keeping track of, and you would want to use 'origin'
> for the usual purpose of keeping track of upstream.
As I said, I use git to keep track of a few CVS projects. I like to fetch
all branches, one being the upstream branch, so that I can compare what
changes not yet in upstream.
> I have a mild aversion to this change, though.
So don't.
> I'd much prefer the third approach I am too lazy to code, which lets you
> say what local branch name instead of 'origin' to keep track of upstream
> from 'git clone' command line.
---
[PATCH] git-clone: Support changing the origin branch with -o
Earlier, git-clone stored upstream's master in the branch named 'origin',
possibly overwriting an existing such branch.
Now you can change it by calling git-clone with '-o <other_name>'.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
Totally untested, but obviously correct :-)
It still overwrites any existing ref of the same name silently.
git-clone.sh | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 280cc2e..87ad477 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -67,6 +67,7 @@ use_local=no
local_shared=no
no_checkout=
upload_pack=
+origin=origin
while
case "$#,$1" in
0,*) break ;;
@@ -75,6 +76,8 @@ while
*,-s|*,--s|*,--sh|*,--sha|*,--shar|*,--share|*,--shared)
local_shared=yes; use_local=yes ;;
*,-q|*,--quiet) quiet=-q ;;
+ 1,-o) usage;;
+ *,-o) origin="$2"; shift;;
1,-u|1,--upload-pack) usage ;;
*,-u|*,--upload-pack)
shift
@@ -208,14 +211,14 @@ then
mkdir -p .git/remotes &&
echo >.git/remotes/origin \
"URL: $repo
-Pull: $head_points_at:origin" &&
- cp ".git/refs/heads/$head_points_at" .git/refs/heads/origin &&
+Pull: $head_points_at:$origin" &&
+ cp ".git/refs/heads/$head_points_at" .git/refs/heads/$origin &&
find .git/refs/heads -type f -print |
while read ref
do
head=`expr "$ref" : '.git/refs/heads/\(.*\)'` &&
test "$head_points_at" = "$head" ||
- test "origin" = "$head" ||
+ test "$origin" = "$head" ||
echo "Pull: ${head}:${head}"
done >>.git/remotes/origin
esac
^ permalink raw reply related
* Re: [PATCH] Introduce core.sharedrepository
From: Junio C Hamano @ 2005-12-22 22:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512222313070.12044@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> +static int make_group_writable(const char *path)
> +{
> + struct stat st;
> +
> + if (lstat(path, &st) < 0)
> + return -1;
> + if (st.st_mode & S_IWUSR)
> + st.st_mode |= S_IWGRP;
> + if (S_ISDIR(st.st_mode))
> + st.st_mode |= S_ISGID;
> + if (chmod(path, st.st_mode) < 0)
> + return -2;
> + return 0;
> +}
Perhaps g+sx not just g+s on directories.
> +
> int safe_create_leading_directories(char *path)
> {
> char *pos = path;
> @@ -64,6 +79,10 @@ int safe_create_leading_directories(char
> *pos = '/';
> return -1;
> }
> + if (shared_repository && make_group_writable(path)) {
> + *pos = '/';
> + return -2;
> + }
Wouldn't this safe_create_leading_directories("/pub/git.git/objects")
try chmod "/pub" and fail?
^ permalink raw reply
* Re: [PATCH] Introduce core.sharedrepository
From: Johannes Schindelin @ 2005-12-22 22:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vaceshi18.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 22 Dec 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > +static int make_group_writable(const char *path)
> > +{
> > + struct stat st;
> > +
> > + if (lstat(path, &st) < 0)
> > + return -1;
> > + if (st.st_mode & S_IWUSR)
> > + st.st_mode |= S_IWGRP;
> > + if (S_ISDIR(st.st_mode))
> > + st.st_mode |= S_ISGID;
> > + if (chmod(path, st.st_mode) < 0)
> > + return -2;
> > + return 0;
> > +}
>
> Perhaps g+sx not just g+s on directories.
Okay:
if (S_ISDIR(st.st_mode))
st.st_mode |= S_ISGID | S_IXGRP;
> > +
> > int safe_create_leading_directories(char *path)
> > {
> > char *pos = path;
> > @@ -64,6 +79,10 @@ int safe_create_leading_directories(char
> > *pos = '/';
> > return -1;
> > }
> > + if (shared_repository && make_group_writable(path)) {
> > + *pos = '/';
> > + return -2;
> > + }
>
> Wouldn't this safe_create_leading_directories("/pub/git.git/objects")
> try chmod "/pub" and fail?
Yes.
How about an "else" in front of the "if"? Like so:
if (mkdir(path, 0777) < 0)
if (errno != EEXIST) {
*pos = '/';
return -1;
}
else if (shared_repository && make_group_writable(path)) {
*pos = '/';
return -2;
}
You want me to resend the patch?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce core.sharedrepository
From: Johannes Schindelin @ 2005-12-22 23:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512222356540.12681@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Thu, 22 Dec 2005, Johannes Schindelin wrote:
> if (mkdir(path, 0777) < 0)
> if (errno != EEXIST) {
> *pos = '/';
> return -1;
> }
> else if (shared_repository && make_group_writable(path)) {
> *pos = '/';
> return -2;
> }
D'oh! Time to head to bed now:
if (mkdir(path, 0777) < 0) {
if (errno != EEXIST) {
*pos = '/';
return -1;
}
} else if (shared_repository && make_group_writable(path)) {
*pos = '/';
return -2;
}
Ciao,
Dscho
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Ben Clifford @ 2005-12-22 3:46 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Junio C Hamano, git
In-Reply-To: <46a038f90512202115o652d8e00v86182302513d1319@mail.gmail.com>
> Could git-shell also be used by a SourceForge-like project, offering
> per-developer git repositories? If they are using the (BSDish?)
> convention of not having a group per user this could backfire.
>
> Does any unix these days _not_ use a group per user?
At least two reasonably sized shops that I have worked with previously do
not have group-per-user (and I think two others but I cannot remember
about those) - they have centrally administered user accounts and just
have groups like 'i am in department X', or 'I am allowed to write into
$SOMEPROJECT cvs'.
But that's not a per-unix decision, its a per-organisation administrative
decision.
In any case, their usage of groups wrt shared CVS would not have a problem
with a 77x mask, though there might be problems (I haven't thought about
it enough) with the setgid(?) bit on directories - we used to hit this
occasionally in CVS when a directory would end up being created with a
user's primary group rather than the 'I am allowed to write into CVS'
group. There is too much wine in me at the moment to work out if its also
a problem for git...
--
^ permalink raw reply
* [PATCH] git-daemon --base-path
From: Petr Baudis @ 2005-12-23 1:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Tommi Virtanen expressed a wish on #git to be able to use short and elegant
git URLs by making git-daemon 'root' in a given directory. This patch
implements this, causing git-daemon to interpret all paths relative to
the given base path if any is given.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-daemon.txt | 11 ++++++++++-
daemon.c | 21 ++++++++++++++++++++-
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 2a8f371..ac67ac2 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -8,7 +8,8 @@ git-daemon - A really simple server for
SYNOPSIS
--------
'git-daemon' [--verbose] [--syslog] [--inetd | --port=n] [--export-all]
- [--timeout=n] [--init-timeout=n] [--strict-paths] [directory...]
+ [--timeout=n] [--init-timeout=n] [--strict-paths]
+ [--base-path=path] [directory...]
DESCRIPTION
-----------
@@ -35,6 +36,14 @@ OPTIONS
git-daemon will refuse to start when this option is enabled and no
whitelist is specified.
+--base-path::
+ Remap all the path requests as relative to the given path.
+ This is sort of "GIT root" - if you run git-daemon with
+ '--base-path=/srv/git' on example.com, then if you later try to pull
+ 'git://example.com/hello.git', `git-daemon` will interpret the path
+ as '/srv/git/hello.git'. Home directories (the '~login' notation)
+ access is disabled.
+
--export-all::
Allow pulling from all directories that look like GIT repositories
(have the 'objects' and 'refs' subdirectories), even if they
diff --git a/daemon.c b/daemon.c
index 539f6e8..3bd1426 100644
--- a/daemon.c
+++ b/daemon.c
@@ -15,7 +15,8 @@ static int verbose;
static const char daemon_usage[] =
"git-daemon [--verbose] [--syslog] [--inetd | --port=n] [--export-all]\n"
-" [--timeout=n] [--init-timeout=n] [--strict-paths] [directory...]";
+" [--timeout=n] [--init-timeout=n] [--strict-paths]\n"
+" [--base-path=path] [directory...]";
/* List of acceptable pathname prefixes */
static char **ok_paths = NULL;
@@ -24,6 +25,9 @@ static int strict_paths = 0;
/* If this is set, git-daemon-export-ok is not required */
static int export_all_trees = 0;
+/* Take all paths relative to this one if non-NULL */
+static char *base_path = NULL;
+
/* Timeout, and initial timeout */
static unsigned int timeout = 0;
static unsigned int init_timeout = 0;
@@ -138,6 +142,17 @@ static char *path_ok(char *dir)
return NULL;
}
+ if (base_path) {
+ static char rpath[PATH_MAX];
+ if (*dir != '/') {
+ /* Forbid possible base-path evasion using ~paths. */
+ logerror("'%s': Non-absolute path denied (base-path active)");
+ return NULL;
+ }
+ snprintf(rpath, PATH_MAX, "%s%s", base_path, dir);
+ dir = rpath;
+ }
+
path = enter_repo(dir, strict_paths);
if (!path) {
@@ -639,6 +654,10 @@ int main(int argc, char **argv)
strict_paths = 1;
continue;
}
+ if (!strncmp(arg, "--base-path=", 12)) {
+ base_path = arg+12;
+ continue;
+ }
if (!strcmp(arg, "--")) {
ok_paths = &argv[i+1];
break;
^ permalink raw reply related
* Re: git /objects directory created 755 by default?
From: Junio C Hamano @ 2005-12-23 4:19 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <43AA9BE6.7000601@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Ahh. Sorry. We use this method a lot, really, but always only for
> running gitk and archaeology tools to check newly pushed changes, so the
> write-shared repo is only write-shared for remote users, and the local
> one never does a commit.
Do you need a working tree to run gitk?
^ permalink raw reply
* Re: [PATCH] git-daemon --base-path
From: Junio C Hamano @ 2005-12-23 4:19 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051223012739.29168.55858.stgit@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> Tommi Virtanen expressed a wish on #git to be able to use short and elegant
> git URLs by making git-daemon 'root' in a given directory. This patch
> implements this, causing git-daemon to interpret all paths relative to
> the given base path if any is given.
This is much nicer than chrooting or having a symlink hanging
under /. Another possibility would be to have ~git/ a symlink
to such directory and make it a whitelist -- then you do not
need this patch. The URL would be "git://ho.st/~git/xxx" which
is short-and-sweet.
> + snprintf(rpath, PATH_MAX, "%s%s", base_path, dir);
> + dir = rpath;
> + }
We probably would want to verify base_path exists and is without
excess trailing slash when parsing arguments, if we are going to
do this.
^ permalink raw reply
* Re: [PATCH] whatchanged: customize diff-tree output
From: Junio C Hamano @ 2005-12-23 4:19 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Linus Torvalds, git
In-Reply-To: <20051222210620.GA4679@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> That's the point, isn't it? A script from ~user1/bin, which calls
> git-whatchanged suddenly stops working in ~user2/repo.
For scripted use you can give command line arguments yourself to
whatchanged and you can bypass the repoconfig. I do not think
whatchanged is meant for scripted use, though --- it is such a
simple script, and if you want to build on it to do something
more elaborate, I think you would be better off writing those
rev-list and diff-tree in your script.
^ permalink raw reply
* git-checkout and SUBDIRECTORY_OK='Yes'
From: Jon Nelson @ 2005-12-23 4:20 UTC (permalink / raw)
To: git
Is it safe to set SUBDIRECTORY_OK='Yes' in git-checkout.sh?
What about the other *.sh that don't already set it?
--
Jon Nelson <jnelson-git@jamponi.net>
^ permalink raw reply
* Re: git-checkout and SUBDIRECTORY_OK='Yes'
From: Junio C Hamano @ 2005-12-23 4:58 UTC (permalink / raw)
To: Jon Nelson; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512222217040.6812@gheavc.wnzcbav.cig>
Jon Nelson <jnelson-git@jamponi.net> writes:
> Is it safe to set SUBDIRECTORY_OK='Yes' in git-checkout.sh?
Personally, I do not like this kind of question. If it were
known to be safe we would have set it so already.
Ah, I must be tired. Sorry. Let's try again.
git-checkout does two very different things, and what they
should do when run from subdirectory are probably quite
different.
It does not make any sense to run the one that switches the
current head from anywhere other than the toplevel:
git-checkout [-f] <branch>
git-checkout [-b <branch>] <committish>
We could of course chdir to top and do the whole-tree checkout
in git-checkout, but the point is the operation does not make
sense on a partial tree.
The other form is to update the index file and working tree file
selectively:
git-checkout <treeish> <file>... ;# out of tree to index and file
git-checkout -- <file>... ;# out of index to file
This form _does_ make sense to run from subdirectory; and I
myself often wish we supported this.
Before SUBDIRECTORY_OK was introduced, git-*.sh commands were
carefully inspected and the ones that do not make much sense to
be run in subdirectories were marked with sh-setup. So if you
do not see SUBDIRECTORY_OK, it is very likely that you need some
real work (like the analysis above to think what should happen
when run from a subdirectory, and actually coding it).
This patch *might* work, or it may not. Please let us know.
diff --git a/git-checkout.sh b/git-checkout.sh
index 36308d2..1219ea0 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -1,6 +1,7 @@
#!/bin/sh
USAGE='[-f] [-b <new_branch>] [<branch>] [<paths>...]'
+SUBDIRECTORY_OK=Sometimes
. git-sh-setup
old=$(git-rev-parse HEAD)
@@ -95,6 +96,14 @@ else
fi
fi
+# We are switching branches and checking out trees, so
+# we *NEED* to be at the toplevel.
+cdup=$(git-rev-parse --show-cdup)
+if test ! -z "$cdup"
+then
+ cd "$cdup"
+fi
+
[ -z "$new" ] && new=$old
# If we don't have an old branch that we're switching to,
diff --git a/rev-parse.c b/rev-parse.c
index bb4949a..0c951af 100644
--- a/rev-parse.c
+++ b/rev-parse.c
@@ -216,6 +216,18 @@ int main(int argc, char **argv)
puts(prefix);
continue;
}
+ if (!strcmp(arg, "--show-cdup")) {
+ const char *pfx = prefix;
+ while (pfx) {
+ pfx = strchr(pfx, '/');
+ if (pfx) {
+ pfx++;
+ printf("../");
+ }
+ }
+ putchar('\n');
+ continue;
+ }
if (!strcmp(arg, "--git-dir")) {
const char *gitdir = getenv(GIT_DIR_ENVIRONMENT);
static char cwd[PATH_MAX];
^ permalink raw reply related
* [ANNOUNCE] GIT 1.0.3
From: Junio C Hamano @ 2005-12-23 8:11 UTC (permalink / raw)
To: git, linux-kernel
Only trivial fixes and cosmetics, there is nothing to see here,
except the versioning scheme has been updated.
Starting in 0.99.7 days and continuing until yesterday,
maintenance releases were named with letter suffixes, like
0.99.7a, 0.99.7b,... Some people seem to have had trouble with
grasping the concept [*1*] ;-)
So the numbering scheme switched to a boring decimal:
- The maintenance releases that follow 1.0.0 are named 1.0.1,
1.0.2, 1.0.3,..., and contain only bugfixes [*2*].
- The next release that follows 1.0.0 is 1.1.0, which, unlike
1.0.X, is allowed to have enhancements.
- If one builds and installs from a random revision on the
"master" branch or "pu" branch after 1.0.0 happens but before
1.1.0 happens, "git --version" would say 1.0.GIT. There will
not be such an intermediate state on the "maint" branch.
I'll slow down until early next year and will not make a formal
roadmap for 1.1.0 and onwards for now, but I've reviewed the
TODO items and updated them here:
http://kernel.org/git/?p=git/git.git;a=blob;hb=todo;f=TODO
I have not prioritized them quite yet, other than dropping a
couple of obviously unneeded or done items.
[Footnote]
*1* No, I did not model these release naming after military
jets, as somebody privately suggested me in an e-mail. I had an
impression that letter updates over there are more often
enhancements and/or repurposing to prolong the service life than
bugfixes. I mimicked ancient Linux versions with letter
suffixes, but come to think of it, they were more enhancements
than fixes, I suspect.
*2* Inevitably there are borderline cases. One could argue that
the [IPV6address] syntax is a fix: "earlier we ought to have
handled it". The file:// URL failure case detection could be
called enhancements: "we never said we support file:// URL".
shortlog since 1.0.0b which should have been 1.0.2
--------------------------------------------------
Alex Riesen:
\n usage in stderr output
Johannes Schindelin:
git-format-patch should show the correct version
sha1_to_hex: properly terminate the SHA1
Junio C Hamano:
send-pack: reword non-fast-forward error message.
Nick Hengeveld:
Fix for http-fetch from file:// URLs
Pavel Roskin:
sanity check in add_packed_git()
^ permalink raw reply
* Re: [PATCH] Introduce core.sharedrepository
From: Junio C Hamano @ 2005-12-23 9:10 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512230003560.12795@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> D'oh! Time to head to bed now:
Likewise.
I've merged up your patches yesterday after some churning and
they are in the pu branch. I hope I did not break them too much
;-).
^ permalink raw reply
* Re: [PATCH] Introduce core.sharedrepository
From: Johannes Schindelin @ 2005-12-23 10:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqz89o0y.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 23 Dec 2005, Junio C Hamano wrote:
> I've merged up your patches yesterday after some churning and
> they are in the pu branch. I hope I did not break them too much
> ;-).
Looks good. Will test.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Introduce core.sharedrepository
From: Johannes Schindelin @ 2005-12-23 11:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512231141410.28090@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Fri, 23 Dec 2005, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 23 Dec 2005, Junio C Hamano wrote:
>
> > I've merged up your patches yesterday after some churning and
> > they are in the pu branch. I hope I did not break them too much
> > ;-).
>
> Looks good. Will test.
Tested. Looks even better.
Ciao,
Dscho
^ permalink raw reply
* Re: git /objects directory created 755 by default?
From: Andreas Ericsson @ 2005-12-23 12:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslsllz17.fsf@totally-fudged-out-message-id>
Junio C Hamano wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>
>>Ahh. Sorry. We use this method a lot, really, but always only for
>>running gitk and archaeology tools to check newly pushed changes, so the
>>write-shared repo is only write-shared for remote users, and the local
>>one never does a commit.
>
>
> Do you need a working tree to run gitk?
>
No, but it makes for a nice shorthand, especially since most of our
projects are riddled with sub-repos.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] send-pack: reword non-fast-forward error message.
From: Andreas Ericsson @ 2005-12-23 12:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vu0d0j24z.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>
>>Andreas Ericsson <ae@op5.se> writes:
>>
>>
>>>Junio C Hamano wrote:
>>>
>>>>In a sense, both are "pull first?" situation, and it probably is
>>>>more confusing to give different messages to the user in these
>>>>two cases. From the end-user point of view they are the same
>>>>"remote is not strict subset.".
>>>
>>>In non-git'ish, does this mean "you're not up to date, so pull before
>>>pushing" ? If so, why not say so? I'm sure it could prevent a fair few
>>>problems for users (not least those new to scm's).
>
>
> That is reasonable. How about this?
>
Me likes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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