* Re: Can I prevent someone clone my git repository?
From: Johannes Schindelin @ 2009-01-08 16:06 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miklos Vajna, Junio C Hamano, Emily Ren, git
In-Reply-To: <20090108155622.GC16840@spearce.org>
Hi,
On Thu, 8 Jan 2009, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > If you want it, here is an initial patch without tests. Indeed, it
> > has not been tested at all.
> >
> > -- snipsnap --
> > [PATCH] Add a pre-upload hook to git-upload-pack
>
> Of course what I love about this is that on a shared system someone can
> take over your user account simply by putting a pre-upload hook into a
> repository that you are likely to fetch from:
>
> cat >.git/hooks/pre-upload
> #!/bin/sh
> cp /bin/sh /tmp/$USER.sh
> chmod u+s,a+x /tmp/$USER.sh
> ^D
> chmod a+x .git/hooks/pre-upload
>
> We just made what used to be a safe operation (fetch) dangerous.
> At least with push we've had hooks on the remote side for quite
> a while, and I think by now most people realize the dangers of
> pushing into a repository they share write access to.
>
> Yikes.
Ouch. You are correct, of course. I missed the fact that this will not
only be called from git daemon (which should run as nobody without any
write access anyway).
Ciao,
Dscho
^ permalink raw reply
* Re: Can I prevent someone clone my git repository?
From: Shawn O. Pearce @ 2009-01-08 15:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Junio C Hamano, Emily Ren, git
In-Reply-To: <alpine.DEB.1.00.0901081648550.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> If you want it, here is an initial patch without tests. Indeed, it has
> not been tested at all.
>
> -- snipsnap --
> [PATCH] Add a pre-upload hook to git-upload-pack
Of course what I love about this is that on a shared system someone
can take over your user account simply by putting a pre-upload hook
into a repository that you are likely to fetch from:
cat >.git/hooks/pre-upload
#!/bin/sh
cp /bin/sh /tmp/$USER.sh
chmod u+s,a+x /tmp/$USER.sh
^D
chmod a+x .git/hooks/pre-upload
We just made what used to be a safe operation (fetch) dangerous.
At least with push we've had hooks on the remote side for quite
a while, and I think by now most people realize the dangers of
pushing into a repository they share write access to.
Yikes.
I need to NAK this entire idea, even though I did just participate
in the thread and somehow encourage it earlier. I haven't had any
caffeine yet today. I blame the lack of drugs on my prior poor
decision making. ;-)
--
Shawn.
^ permalink raw reply
* Re: Can I prevent someone clone my git repository?
From: Johannes Schindelin @ 2009-01-08 15:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Miklos Vajna, Junio C Hamano, Emily Ren, git
In-Reply-To: <20090108152934.GA16840@spearce.org>
Hi,
On Thu, 8 Jan 2009, Shawn O. Pearce wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Thu, 8 Jan 2009, Miklos Vajna wrote:
> >
> > > On Thu, Jan 08, 2009 at 12:27:59PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > > like git://your-host/repository.git
> > > >
> > > > If the people are on different IPs, a hook can restrict who may clone,
> > > > since commit v1.6.1-rc1~109.
> > >
> > > Hmm, but I think there is no hook called "pre-send" or so that could
> > > return status code 1 to prevent receiving, so that commit on its own
> > > does not does what Emily needs here.
> >
> > Oops. I assumed there is a pre-upload hook, but apparently I was wrong.
> >
> > Would be easy to introduce that hook, though...
>
> Well, sure, but Emily is asking about "no clone".
>
> Does that mean that users can ask for incremental updates, but not
> initial clones where there is nothing in common?
>
> If so then any sort of hook needs an input parameter and needs
> to be called after the commit negotation is complete, so the hook
> can be told "the other side has some stuff" or "the other side has
> nothing at all".
>
> FWIW I was just yesterday talking to a co-worker about adding this
> sort of behavior to Gerrit2. Cloning the Linux kernel over its
> internal sshd is quite a bit slower than doing it over native git,
> so we were talking about blocking initial clones. Everything in
> a Gerrit server should be opensource and available over git://,
> so its just a limit to save server resources.
If you want it, here is an initial patch without tests. Indeed, it has
not been tested at all.
-- snipsnap --
[PATCH] Add a pre-upload hook to git-upload-pack
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
upload-pack.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index e5adbc0..bca0428 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -140,6 +140,27 @@ static int do_rev_list(int fd, void *create_full_pack)
return 0;
}
+static int pre_upload_hook(int is_clone)
+{
+ struct child_process proc;
+ const char *name = git_path("hooks/pre-upload");
+ const char *argv[3];
+ int i = 0;
+
+ if (access(name, X_OK) < 0)
+ return 0;
+
+ memset(&proc, 0, sizeof(proc));
+ argv[i++] = name;
+ if (is_clone)
+ argv[i++] = "clone";
+ argv[i++] = NULL;
+ proc.argv = argv;
+ proc.no_stdin = 1;
+ proc.stdout_to_stderr = 1;
+ return run_command(&proc);
+}
+
static void create_pack_file(void)
{
struct async rev_list;
@@ -153,6 +174,9 @@ static void create_pack_file(void)
const char *argv[10];
int arg = 0;
+ if (pre_upload_hook(create_full_pack))
+ die("upload denied by pre-upload hook");
+
rev_list.proc = do_rev_list;
/* .data is just a boolean: any non-NULL value will do */
rev_list.data = create_full_pack ? &rev_list : NULL;
^ permalink raw reply related
* Plans to put together an Info manual?
From: Tim Visher @ 2009-01-08 15:47 UTC (permalink / raw)
To: git
I did a _teensy_ bit of googling and nosing around on the home page,
so forgive me if this has been brought up before or if it in fact
already exists.
I wast just wondering A) If there is an info manual for Git, B) If
there isn't, is one planned?
I'm personally a big fan of Info manuals over traditional man pages
but I have no experience with creating them or anything like that.
However, this might be another nice place for people who aren't at all
familiar with C (read: me) to jump in and help out with development.
--
In Christ,
Timmy V.
http://burningones.com/
http://five.sentenc.es/ - Spend less time on e-mail
^ permalink raw reply
* Re: [PATCH] Wrap inflateInit to retry allocation after releasing pack memory
From: Linus Torvalds @ 2009-01-08 15:35 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, R. Tyler Ballance, Nicolas Pitre,
Jan Krüger, Git ML, kb
In-Reply-To: <7vbpui8j6f.fsf@gitster.siamese.dyndns.org>
On Wed, 7 Jan 2009, Junio C Hamano wrote:
>
> Thanks, but "needs a buffer output buffer" made me scratch my head
> somewhat.
That was just me editing it.
It was originally "needs an output buffer" and then I was supposed to edit
it to "needs a buffer" (because it can be either output or input, and in
the case of git it's usually actually the input that was partial).
And then I messed up, and it became that.
Linus
^ permalink raw reply
* Re: [PATCH] Wrap inflateInit to retry allocation after releasing pack memory
From: Shawn O. Pearce @ 2009-01-08 15:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Junio C Hamano, R. Tyler Ballance, Nicolas Pitre, Jan Krüger,
Git ML, kb
In-Reply-To: <alpine.LFD.2.00.0901071941210.3283@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Let's do this (more complete) wrapping instead, ok?
Ack.
> This one _just_ wraps things, btw - it doesn't do the "retry on low memory
> error" part, at least not yet. I think that's an independent issue from
> the reporting.
I still think we should try to reduce pack memory usage when we get
oom from zlib and retry the current operation once. We do it almost
everywhere else and it works relatively well.
We may also want to consider dropping (e.g. halving) the window
size and/or limit when we run out of memory. We'll run slower but
if the OS has denied us further resources it may be a ulimit thing
on a shared system, and we should try harder to work with what we
have available to us.
--
Shawn.
^ permalink raw reply
* Re: Funny: git -p submodule summary
From: Johannes Schindelin @ 2009-01-08 15:30 UTC (permalink / raw)
To: Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0901081601240.30769@pacific.mpi-cbg.de>
Hi,
On Thu, 8 Jan 2009, Johannes Schindelin wrote:
> Just try this with a submodule that has more changes than fit on a
> screen:
>
> $ git -p submodule summary
>
> In my tests, it consistently fscks up my console.
Update: even if the changes do fit on a screen, the console is fscked up
(I have to stty echo to get it back to normal).
Ciao,
Dscho
^ permalink raw reply
* Re: Can I prevent someone clone my git repository?
From: Shawn O. Pearce @ 2009-01-08 15:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Junio C Hamano, Emily Ren, git
In-Reply-To: <alpine.DEB.1.00.0901081541041.30769@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 8 Jan 2009, Miklos Vajna wrote:
>
> > On Thu, Jan 08, 2009 at 12:27:59PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > like git://your-host/repository.git
> > >
> > > If the people are on different IPs, a hook can restrict who may clone,
> > > since commit v1.6.1-rc1~109.
> >
> > Hmm, but I think there is no hook called "pre-send" or so that could
> > return status code 1 to prevent receiving, so that commit on its own
> > does not does what Emily needs here.
>
> Oops. I assumed there is a pre-upload hook, but apparently I was wrong.
>
> Would be easy to introduce that hook, though...
Well, sure, but Emily is asking about "no clone".
Does that mean that users can ask for incremental updates, but not
initial clones where there is nothing in common?
If so then any sort of hook needs an input parameter and needs
to be called after the commit negotation is complete, so the hook
can be told "the other side has some stuff" or "the other side has
nothing at all".
FWIW I was just yesterday talking to a co-worker about adding this
sort of behavior to Gerrit2. Cloning the Linux kernel over its
internal sshd is quite a bit slower than doing it over native git,
so we were talking about blocking initial clones. Everything in
a Gerrit server should be opensource and available over git://,
so its just a limit to save server resources.
--
Shawn.
^ permalink raw reply
* Funny: git -p submodule summary
From: Johannes Schindelin @ 2009-01-08 15:07 UTC (permalink / raw)
To: Jeff King, git
Hi list,
Just try this with a submodule that has more changes than fit on a screen:
$ git -p submodule summary
In my tests, it consistently fscks up my console. I wonder if this is
related to ea27a18(spawn pager via run_command interface).
*reverts that commit* Yep, that fixes it.
Ciao,
Dscho
^ permalink raw reply
* Re: Can I prevent someone clone my git repository?
From: Johannes Schindelin @ 2009-01-08 14:42 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Junio C Hamano, Emily Ren, git
In-Reply-To: <20090108143257.GX21154@genesis.frugalware.org>
Hi,
On Thu, 8 Jan 2009, Miklos Vajna wrote:
> On Thu, Jan 08, 2009 at 12:27:59PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > like git://your-host/repository.git
> >
> > If the people are on different IPs, a hook can restrict who may clone,
> > since commit v1.6.1-rc1~109.
>
> Hmm, but I think there is no hook called "pre-send" or so that could
> return status code 1 to prevent receiving, so that commit on its own
> does not does what Emily needs here.
Oops. I assumed there is a pre-upload hook, but apparently I was wrong.
Would be easy to introduce that hook, though...
Ciao,
Dscho
^ permalink raw reply
* Re: Can I prevent someone clone my git repository?
From: Miklos Vajna @ 2009-01-08 14:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Emily Ren, git
In-Reply-To: <alpine.DEB.1.00.0901081227170.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
On Thu, Jan 08, 2009 at 12:27:59PM +0100, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > like git://your-host/repository.git
>
> If the people are on different IPs, a hook can restrict who may clone,
> since commit v1.6.1-rc1~109.
Hmm, but I think there is no hook called "pre-send" or so that could
return status code 1 to prevent receiving, so that commit on its own
does not does what Emily needs here.
Or have I missed something?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] allow 8bit data in email body sent by send-email
From: Andre Przywara @ 2009-01-08 13:50 UTC (permalink / raw)
To: git; +Cc: Andre Przywara
Hi,
when sending patch files via git send-email, the perl script assumes
7bit characters only. If there are other bytes in the body (foreign language
characters in names or translations), some servers (like vger.kernel.org)
reject the mail because of thät. This patch always adds an 8bit header line
to each mail.
If someone thinks this has any side-effects, tell me, I am open to suggestions.
Regards,
André.
Signed-off-by: Andre Przywara <andre.przywara@amd.com>
Andre Przywara
AMD-Operating System Research Center (OSRC), Dresden, Germany
Tel: +49 351 277-84917
****to satisfy European Law for business letters:
Advanced Micro Devices GmbH
Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen
Geschaeftsfuehrer: Jochen Polster; Thomas M. McCoy; Giuliano Meroni
Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen
Registergericht Muenchen, HRB Nr. 43632
---
git-send-email.perl | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 77ca8fe..68a462c 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -793,6 +793,7 @@ To: $to${ccline}
Subject: $subject
Date: $date
Message-Id: $message_id
+Content-Transfer-Encoding: 8bit
X-Mailer: git-send-email $gitversion
";
if ($thread && $reply_to) {
--
1.5.5
^ permalink raw reply related
* You've got an E-card
From: Unknown, Karen @ 2009-01-08 12:52 UTC (permalink / raw)
To: git
Karen chose for you a digital postcard.
To view your eCard, click on the following link:
http://greetingsupersite.com/?cardnum=10e7114323537c2c72bea4e52eba2
This card was sent from UltimateEcards.com!
^ permalink raw reply
* [PATCH/RFC v4 2/2] entry.c: create_directories(): only create/check each directory once!
From: Kjetil Barvik @ 2009-01-08 11:32 UTC (permalink / raw)
To: git; +Cc: Kjetil Barvik
In-Reply-To: <1231414356-6982-1-git-send-email-barvik@broadpark.no>
When we do an 'git checkout' after some time we end up in the
'checkout_entry()' function inside entry.c, and from here we call the
'create_directories()' function to make sure that all the directories
exists for the possible new file or entry.
The 'create_directories()' function happily started to check that all
path component exists. This resulted in tons and tons of calls to
lstat() or stat() when we checkout files nested deep inside a
directory.
We try to avoid this by remembering the last created directory.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
:100644 100644 768ba38... ec1297f... M cache.h
:100644 100644 aa2ee46... 1d5fc85... M entry.c
:100644 100644 28e2759... 0a03e65... M unpack-trees.c
cache.h | 1 +
entry.c | 57 +++++++++++++++++++++++++++++++++++++++++++++----------
unpack-trees.c | 1 +
3 files changed, 48 insertions(+), 11 deletions(-)
diff --git a/cache.h b/cache.h
index 768ba3825f3015828381490b0c387177a4f71578..ec1297ff5621cc9eb7fce51cc025f18a030ac9ea 100644
--- a/cache.h
+++ b/cache.h
@@ -718,6 +718,7 @@ struct checkout {
refresh_cache:1;
};
+extern void clear_created_dirs_cache(void);
extern int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *topath);
#define LSTAT_DIR (1u << 0)
diff --git a/entry.c b/entry.c
index aa2ee46a84033585d8e07a585610c5a697af82c2..1d5fc85b5f4b02bcdb862745777f7bc086b70c63 100644
--- a/entry.c
+++ b/entry.c
@@ -1,18 +1,50 @@
#include "cache.h"
#include "blob.h"
-static void create_directories(const char *path, const struct checkout *state)
+static char buf[PATH_MAX];
+static int buf_len = 0;
+
+static inline int
+greatest_match_last_created_dir(int len, const char *path)
{
- int len = strlen(path);
- char *buf = xmalloc(len + 1);
- const char *slash = path;
+ int max_len, match_len = 0, i = 0;
- while ((slash = strchr(slash+1, '/')) != NULL) {
- struct stat st;
- int stat_status;
+ max_len = len < buf_len ? len : buf_len;
+ while (i < max_len && path[i] == buf[i]) {
+ if (path[i] == '/') match_len = i;
+ i++;
+ }
+ if (i == buf_len && len > buf_len && path[buf_len] == '/')
+ match_len = buf_len;
+ return match_len;
+}
+
+void clear_created_dirs_cache(void)
+{
+ buf[0] = 0;
+ buf_len = 0;
+}
+
+static void
+create_directories(int path_len, const char *path, const struct checkout *state)
+{
+ int path_len_max, buf_i, len, stat_status;
+ struct stat st;
- len = slash - path;
- memcpy(buf, path, len);
+ /* Check the cache for previously created directories (and
+ * components) within this function. There is no need to
+ * re-create directory components more than once!
+ */
+ path_len_max = path_len < PATH_MAX ? path_len : PATH_MAX;
+ buf_i = len = greatest_match_last_created_dir(path_len_max, path);
+ while (buf_i < path_len_max) {
+ do {
+ buf[buf_i] = path[buf_i];
+ buf_i++;
+ } while (buf_i < path_len_max && path[buf_i] != '/');
+ if (buf_i >= path_len_max)
+ break;
+ len = buf_i;
buf[len] = 0;
if (len <= state->base_dir_len)
@@ -45,7 +77,9 @@ static void create_directories(const char *path, const struct checkout *state)
die("cannot create directory at %s", buf);
}
}
- free(buf);
+ /* Update the cache of already created directories */
+ buf[len] = 0;
+ buf_len = len;
}
static void remove_subtree(const char *path)
@@ -201,6 +235,7 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
memcpy(path, state->base_dir, len);
strcpy(path + len, ce->name);
+ len += ce_namelen(ce);
if (!lstat(path, &st)) {
unsigned changed = ce_match_stat(ce, &st, CE_MATCH_IGNORE_VALID);
@@ -229,6 +264,6 @@ int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *t
return error("unable to unlink old '%s' (%s)", path, strerror(errno));
} else if (state->not_new)
return 0;
- create_directories(path, state);
+ create_directories(len, path, state);
return write_entry(ce, path, state, 0);
}
diff --git a/unpack-trees.c b/unpack-trees.c
index 28e275981a21b033459ef9c7e420cce4bf7e5513..0a03e65f9c9d869ab2d8b3c337f032ff2b8e7b2f 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -119,6 +119,7 @@ static int check_updates(struct unpack_trees_options *o)
}
}
+ clear_created_dirs_cache();
for (i = 0; i < index->cache_nr; i++) {
struct cache_entry *ce = index->cache[i];
--
1.6.1.rc1.49.g7f705
^ permalink raw reply related
* [PATCH/RFC v4 1/2] Optimised, faster, more effective symlink/directory detection
From: Kjetil Barvik @ 2009-01-08 11:32 UTC (permalink / raw)
To: git; +Cc: Kjetil Barvik
In-Reply-To: <1231414356-6982-1-git-send-email-barvik@broadpark.no>
Changes includes the following:
- The cache functionality is more effective. Previously when A/B/C/D
was in the cache and A/B/C/E/file.c was called for, there was no
match at all from the cache. Now we use the fact that the paths
"A", "A/B" and "A/B/C" is already tested, and we only need to do an
lstat() call on "A/B/C/E".
- We only cache/store the last path regardless of it's type. Since the
cache functionality is always used with alphabetically sorted names
(at least it seams so for me), there is no need to store both the
last symlink-leading path and the last real-directory path. Note
that if the cache is not called with (mostly) alphabetically sorted
names, neither the old, nor this new one, would be very effective.
- We also can cache the fact that a directory does not exist.
Previously we could end up doing lots of lstat() calls for a removed
directory which previously contained lots of files. Since we
already have simplified the cache functionality and only store the
last path (see above), this new functionality was easy to add.
- Previously, when symlink A/B/C/S was cached/stored in the
symlink-leading path, and A/B/C/file.c was called for, it was not
easy to use the fact that we already known that the paths "A", "A/B"
and "A/B/C" is real directories. Since we now only store one single
path (the last one), we also get similar logic for free regarding
the new "non-exsisting-directory-cache".
- Avoid copying the first path components of the name 2 zillions times
when we tests new path components. Since we always cache/store the
last path, we can copy each component as we test those directly into
the cache. Previously we ended up doing a memcpy() for the full
path/name right before each lstat() call, and when updating the
cache for each time we have tested an new path component.
- We also use less memory, that is PATH_MAX bytes less memory on the
stack and PATH_MAX bytes less memory on the heap.
- Introduce a 3rd argument, 'unsigned int track_flags', to the
cache-test function, check_lstat_cache(). This new argument can be
used to tell the cache functionality which types of directories
should be cached.
- Also introduce a 'void clear_lstat_cache(void)' function, which
should be used to clean the cache before usage. If for instance,
you have changed the types of directories which should be cached,
the cache could contain a path which was not wanted.
Signed-off-by: Kjetil Barvik <barvik@broadpark.no>
---
:100644 100644 719de8b... 870961e... M builtin-add.c
:100644 100644 a8f75ed... d3d001a... M builtin-apply.c
:100644 100644 5604977... 8907219... M builtin-update-index.c
:100644 100644 231c06d... 768ba38... M cache.h
:100644 100644 ae96c64... c9caa0e... M diff-lib.c
:100644 100644 5a5e781... a68b11e... M symlinks.c
:100644 100644 54f301d... 28e2759... M unpack-trees.c
builtin-add.c | 1 +
builtin-apply.c | 1 +
builtin-update-index.c | 1 +
cache.h | 22 ++++++++-
diff-lib.c | 1 +
symlinks.c | 120 ++++++++++++++++++++++++++++++-----------------
unpack-trees.c | 5 +-
7 files changed, 104 insertions(+), 47 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 719de8b0f2d2d831f326d948aa18700e5c474950..870961e8ca4e3d6f9333020083d0a232bccd542c 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -225,6 +225,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, builtin_add_options,
builtin_add_usage, 0);
+ clear_symlink_cache();
if (patch_interactive)
add_interactive = 1;
if (add_interactive)
diff --git a/builtin-apply.c b/builtin-apply.c
index a8f75ed3ed411d8cf7a3ec9dfefef7407c50f447..d3d001a96be6e502d6338af4467f7c313370d78e 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -3154,6 +3154,7 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
if (apply_default_whitespace)
parse_whitespace_option(apply_default_whitespace);
+ clear_symlink_cache();
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
char *end;
diff --git a/builtin-update-index.c b/builtin-update-index.c
index 560497750586ec61be4e34de6dedd9c307129817..8907219fb9cb438113e29ee17854edb5dd4baa4d 100644
--- a/builtin-update-index.c
+++ b/builtin-update-index.c
@@ -581,6 +581,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
if (entries < 0)
die("cache corrupted");
+ clear_symlink_cache();
for (i = 1 ; i < argc; i++) {
const char *path = argv[i];
const char *p;
diff --git a/cache.h b/cache.h
index 231c06d7726b575f6e522d5b0c0fe43557e8c651..768ba3825f3015828381490b0c387177a4f71578 100644
--- a/cache.h
+++ b/cache.h
@@ -719,7 +719,27 @@ struct checkout {
};
extern int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *topath);
-extern int has_symlink_leading_path(int len, const char *name);
+
+#define LSTAT_DIR (1u << 0)
+#define LSTAT_NOENT (1u << 1)
+#define LSTAT_SYMLINK (1u << 2)
+#define LSTAT_LSTATERR (1u << 3)
+#define LSTAT_ERR (1u << 4)
+extern unsigned int check_lstat_cache(int len, const char *name,
+ unsigned int track_flags);
+extern void clear_lstat_cache(void);
+static inline unsigned int has_symlink_leading_path(int len, const char *name)
+{
+ return check_lstat_cache(len, name, LSTAT_SYMLINK|LSTAT_DIR) &
+ LSTAT_SYMLINK;
+}
+#define clear_symlink_cache() clear_lstat_cache()
+static inline unsigned int has_symlink_or_noent_leading_path(int len, const char *name)
+{
+ return check_lstat_cache(len, name, LSTAT_SYMLINK|LSTAT_NOENT|LSTAT_DIR) &
+ (LSTAT_SYMLINK|LSTAT_NOENT);
+}
+#define clear_symlink_or_noent_cache() clear_lstat_cache()
extern struct alternate_object_database {
struct alternate_object_database *next;
diff --git a/diff-lib.c b/diff-lib.c
index ae96c64ca209f4df9008198e8a04b160bed618c7..c9caa0e6ef0f4a8ee8b850869ef6d0f52b712385 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -69,6 +69,7 @@ int run_diff_files(struct rev_info *revs, unsigned int option)
diff_unmerged_stage = 2;
entries = active_nr;
symcache[0] = '\0';
+ clear_symlink_cache();
for (i = 0; i < entries; i++) {
struct stat st;
unsigned int oldmode, newmode;
diff --git a/symlinks.c b/symlinks.c
index 5a5e781a15d7d9cb60797958433eca896b31ec85..a68b11e2dbd875bc26b4fe0b87490dd64305cdd0 100644
--- a/symlinks.c
+++ b/symlinks.c
@@ -1,64 +1,96 @@
#include "cache.h"
-struct pathname {
- int len;
- char path[PATH_MAX];
-};
+static char cache_path[PATH_MAX];
+static int cache_len = 0;
+static unsigned int cache_flags = 0;
-/* Return matching pathname prefix length, or zero if not matching */
-static inline int match_pathname(int len, const char *name, struct pathname *match)
+static inline int greatest_match_lstat_cache(int len, const char *name)
{
- int match_len = match->len;
- return (len > match_len &&
- name[match_len] == '/' &&
- !memcmp(name, match->path, match_len)) ? match_len : 0;
-}
+ int max_len, match_len = 0, i = 0;
-static inline void set_pathname(int len, const char *name, struct pathname *match)
-{
- if (len < PATH_MAX) {
- match->len = len;
- memcpy(match->path, name, len);
- match->path[len] = 0;
+ max_len = len < cache_len ? len : cache_len;
+ while (i < max_len && name[i] == cache_path[i]) {
+ if (name[i] == '/') match_len = i;
+ i++;
}
+ if (i == cache_len && len > cache_len && name[cache_len] == '/')
+ match_len = cache_len;
+ return match_len;
}
-int has_symlink_leading_path(int len, const char *name)
+/*
+ * Check if name 'name' of length 'len' has a symlink leading
+ * component, or if the directory exists and is real, or not.
+ *
+ * To speed up the check, some information is allowed to be cached.
+ * This is indicated by the 'track_flags' argument.
+ */
+unsigned int
+check_lstat_cache(int len, const char *name, unsigned int track_flags)
{
- static struct pathname link, nonlink;
- char path[PATH_MAX];
+ int match_len, last_slash, max_len;
+ unsigned int match_flags, ret_flags, save_flags;
struct stat st;
- char *sp;
- int known_dir;
- /*
- * See if the last known symlink cache matches.
+ /* Check if match from the cache for 2 "excluding" path types.
*/
- if (match_pathname(len, name, &link))
- return 1;
+ match_len = last_slash = greatest_match_lstat_cache(len, name);
+ match_flags = cache_flags & track_flags & (LSTAT_NOENT|LSTAT_SYMLINK);
+ if (match_flags && match_len == cache_len)
+ return match_flags;
- /*
- * Get rid of the last known directory part
+ /* Okay, no match from the cache so far, so now we have to
+ * check the rest of the path components.
*/
- known_dir = match_pathname(len, name, &nonlink);
-
- while ((sp = strchr(name + known_dir + 1, '/')) != NULL) {
- int thislen = sp - name ;
- memcpy(path, name, thislen);
- path[thislen] = 0;
+ ret_flags = LSTAT_DIR;
+ max_len = len < PATH_MAX ? len : PATH_MAX;
+ while (match_len < max_len) {
+ do {
+ cache_path[match_len] = name[match_len];
+ match_len++;
+ } while (match_len < max_len && name[match_len] != '/');
+ if (match_len >= max_len)
+ break;
+ last_slash = match_len;
+ cache_path[last_slash] = '\0';
- if (lstat(path, &st))
- return 0;
- if (S_ISDIR(st.st_mode)) {
- set_pathname(thislen, path, &nonlink);
- known_dir = thislen;
+ if (lstat(cache_path, &st)) {
+ ret_flags = LSTAT_LSTATERR;
+ if (errno == ENOENT)
+ ret_flags |= LSTAT_NOENT;
+ } else if (S_ISDIR(st.st_mode)) {
continue;
- }
- if (S_ISLNK(st.st_mode)) {
- set_pathname(thislen, path, &link);
- return 1;
+ } else if (S_ISLNK(st.st_mode)) {
+ ret_flags = LSTAT_SYMLINK;
+ } else {
+ ret_flags = LSTAT_ERR;
}
break;
}
- return 0;
+
+ /* At the end update the cache. Note that max 3 different
+ * path types can be cached for the moment!
+ */
+ save_flags = ret_flags & track_flags &
+ (LSTAT_NOENT|LSTAT_SYMLINK|LSTAT_DIR);
+ if (save_flags && last_slash > 0 && last_slash < PATH_MAX) {
+ cache_path[last_slash] = '\0';
+ cache_len = last_slash;
+ cache_flags = save_flags;
+ } else {
+ clear_lstat_cache();
+ }
+ return ret_flags;
+}
+
+/*
+ * Before usage of the check_lstat_cache() function one should call
+ * clear_lstat_cache() (at an appropriate place) to make sure that the
+ * cache is clean.
+ */
+void clear_lstat_cache(void)
+{
+ cache_path[0] = '\0';
+ cache_len = 0;
+ cache_flags = 0;
}
diff --git a/unpack-trees.c b/unpack-trees.c
index 54f301da67be879c80426bc21776427fdd38c02e..28e275981a21b033459ef9c7e420cce4bf7e5513 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -61,7 +61,7 @@ static void unlink_entry(struct cache_entry *ce)
char *cp, *prev;
char *name = ce->name;
- if (has_symlink_leading_path(ce_namelen(ce), ce->name))
+ if (has_symlink_or_noent_leading_path(ce_namelen(ce), ce->name))
return;
if (unlink(name))
return;
@@ -105,6 +105,7 @@ static int check_updates(struct unpack_trees_options *o)
cnt = 0;
}
+ clear_symlink_or_noent_cache();
for (i = 0; i < index->cache_nr; i++) {
struct cache_entry *ce = index->cache[i];
@@ -584,7 +585,7 @@ static int verify_absent(struct cache_entry *ce, const char *action,
if (o->index_only || o->reset || !o->update)
return 0;
- if (has_symlink_leading_path(ce_namelen(ce), ce->name))
+ if (has_symlink_or_noent_leading_path(ce_namelen(ce), ce->name))
return 0;
if (!lstat(ce->name, &st)) {
--
1.6.1.rc1.49.g7f705
^ permalink raw reply related
* [PATCH/RFC v4 0/2] git checkout: optimise away lots of lstat() calls
From: Kjetil Barvik @ 2009-01-08 11:32 UTC (permalink / raw)
To: git; +Cc: Kjetil Barvik
I have just started to clone some interesting Linux git trees to watch
the development more closely, and therefore also started to use git. I
noticed that 'git checkout' takes some time, and especially that the
'git checkout' command does lots and lots of lstat() calls.
After some more investigation and thinking, I have made 2 patches and
been able to optimise away over 42% of all lstat() calls in some cases
for the 'git checkout' command. I have not tested other git porcelain
commands for reduced lstat() calls, but I would guess that the more
effective 'lstat_cache()' compared to 'has_leading_symlink_cache()',
should also give better numbers in other cases.
Both patches is against git master, and the git 'make test' test suite
still passes after each patch.
To document the improvement, below is some numbers, which compares
before and after the 2 patches. To reproduce the numbers:
- git clone the Linux git tree to be able to get the Linux tags
'v2.6.25' and 'v2.6.27'.
- git checkout -b my-v2.6.27 v2.6.27
- git checkout -b my-v2.6.25 v2.6.25
Then, when the current branch is 'my-v2.6.25' do:
strace -o strace_to27 -T git checkout -q my-v2.6.27
And then you pretty print and collect stats from the 'strace_to27'
file. If someone wants a copy of the strace_stat.pl script, which I
made/used to do the pretty printing, then give me a hint.
Below is the stats/numbers from the current git version (before the 2
patches). Notice that we do an lstat() call on the "arch" directory
over 6000 times!
TOTAL 185151 100.000% OK:165544 NOT: 19607 11.136001 sec 60 usec/call
lstat64 120954 65.327% OK:107013 NOT: 13941 5.388727 sec 45 usec/call
strings 120954 tot 30163 uniq 4.010 /uniq 5.388727 sec 45 usec/call
files 61491 tot 28712 uniq 2.142 /uniq 2.740520 sec 45 usec/call
dirs 45522 tot 1436 uniq 31.701 /uniq 1.994448 sec 44 usec/call
errors 13941 tot 5189 uniq 2.687 /uniq 0.653759 sec 47 usec/call
6297 5.206% OK: 6297 NOT: 0 "arch"
4544 3.757% OK: 4544 NOT: 0 "drivers"
1816 1.501% OK: 1816 NOT: 0 "arch/arm"
1499 1.239% OK: 1499 NOT: 0 "include"
912 0.754% OK: 912 NOT: 0 "arch/powerpc"
764 0.632% OK: 764 NOT: 0 "fs"
746 0.617% OK: 746 NOT: 0 "drivers/net"
662 0.547% OK: 662 NOT: 0 "net"
652 0.539% OK: 325 NOT: 327 "arch/sparc/include"
636 0.526% OK: 636 NOT: 0 "drivers/media"
606 0.501% OK: 606 NOT: 0 "include/linux"
533 0.441% OK: 533 NOT: 0 "arch/sh"
522 0.432% OK: 260 NOT: 262 "arch/powerpc/include"
488 0.403% OK: 243 NOT: 245 "arch/sh/include"
413 0.341% OK: 413 NOT: 0 "arch/sparc"
390 0.322% OK: 390 NOT: 0 "arch/x86"
383 0.317% OK: 383 NOT: 0 "Documentation"
370 0.306% OK: 184 NOT: 186 "arch/ia64/include"
366 0.303% OK: 366 NOT: 0 "drivers/media/video"
348 0.288% OK: 173 NOT: 175 "arch/arm/include"
Here is the stats/numbers after applying the 2 patches. Notice how
nice the top 20 entries list now looks!
TOTAL 133655 100.000% OK:121615 NOT: 12040 10.429999 sec 78 usec/call
lstat64 69603 52.077% OK: 63218 NOT: 6385 3.419920 sec 49 usec/call
strings 69603 tot 30163 uniq 2.308 /uniq 3.419920 sec 49 usec/call
files 61491 tot 28712 uniq 2.142 /uniq 3.034869 sec 49 usec/call
dirs 1727 tot 1164 uniq 1.484 /uniq 0.075681 sec 44 usec/call
errors 6385 tot 5189 uniq 1.230 /uniq 0.309370 sec 48 usec/call
4 0.006% OK: 4 NOT: 0 ".gitignore"
4 0.006% OK: 4 NOT: 0 ".mailmap"
4 0.006% OK: 4 NOT: 0 "CREDITS"
4 0.006% OK: 4 NOT: 0 "Documentation/00-INDEX"
4 0.006% OK: 4 NOT: 0 "Documentation/ABI/testing/sysfs-block"
4 0.006% OK: 4 NOT: 0 "Documentation/ABI/testing/sysfs-firmware-acpi"
4 0.006% OK: 4 NOT: 0 "Documentation/CodingStyle"
4 0.006% OK: 4 NOT: 0 "Documentation/DMA-API.txt"
4 0.006% OK: 4 NOT: 0 "Documentation/DMA-mapping.txt"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/Makefile"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/gadget.tmpl"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/kernel-api.tmpl"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/kernel-locking.tmpl"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/procfs-guide.tmpl"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/procfs_example.c"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/rapidio.tmpl"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/s390-drivers.tmpl"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/uio-howto.tmpl"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/videobook.tmpl"
4 0.006% OK: 4 NOT: 0 "Documentation/DocBook/writing_usb_driver.tmpl"
Note that the overall used system time as recorded from 'strace -T',
does not drop so much that the reduced lstat() time should indicate
for _this_ particular test run. This is because now each unlink()
call takes much more time, at least for me on an slow ide disk (using
ext3) on a laptop.
A simple test gives me an overall improvement of 2.937 seconds: real
time drops from 28.195s (best of 5 runs with 'time git ...'), to
25.381s (best of 5 runs).
I have also noticed that inside the unlink_entry() function in file
unpack-trees.c, one could often end up calling rmdir() lots and lots
of times on none-empty directories. Maybe one should schedule each
directory for removal by an appropriate function, and then at the end
call a new function to clean all the directories at once?
Comments?
----
Changes since v3:
= inside patch 1/2
- readability: rename 'greatest_common_cache_path_prefix()' to
'greatest_match_lstat_cache()' and corresponding line edits
= inside patch 2/2
- readability: renames of several variables and one function
- reuse original names for 'buf' and 'len' (makes the patch touch
less lines)
- simplified the update of the cache
- no need to clear the cache inside remove_subtree()
- small cleanups of comments and commit message
Changes since v2:
= inside patch 1/2
[[Following is updates after comments from Linus Torvalds - Thanks!]]
- simplified the interface: introduce 2 static inline functions
has_symlink_leading_path() and has_symlink_or_noent_leading_path()
- similar, introduce 2 defines: clear_symlink_cache() and
clear_symlink_or_noent_cache()
- reorganise the patches: previous patch 2/4 and 4/4 is put into
this one
- update the commit message accordingly
- keep the symlinks.c file
= inside patch 2/2
- was patch 3/4 in v2
- always null terminate the dirs_path array
- update the patch with some of the comments regarding patch 1/4
from Junio C Hamano
Changes since v1:
= inside patch 1/4
- always null terminate the cache_path array
- added a paragraph to the commit message for this patch
- small cleanup on 2 comments, and a small line indentation change
[[Following is updates after comments from Junio C Hamano - Thanks!]]
- removed the 'static inline update_path_cache()' function
- replaced the else-part of the above inline function with a call
to the 'clear_lstat_cache()' function.
- deleted the '|| errno == ENOTDIR' part inside the big while-loop
inside check_lstat_cache(), and updated the named BIT-fields
accordingly
= inside patch 2/4
- moved a paragraph out from the commit message for this patch and
into this cover-letter
[[Following is updates after comments from Junio C Hamano - Thanks!]]
- Removed the '|LSTAT_NOTDIR' part from the call to lstat_cache()
inside function 'check_removed()' inside file diff-lib.c
Kjetil Barvik (2):
Optimised, faster, more effective symlink/directory detection
entry.c: create_directories(): only create/check each directory once!
builtin-add.c | 1 +
builtin-apply.c | 1 +
builtin-update-index.c | 1 +
cache.h | 23 +++++++++-
diff-lib.c | 1 +
entry.c | 57 ++++++++++++++++++----
symlinks.c | 120 ++++++++++++++++++++++++++++++-----------------
unpack-trees.c | 6 ++-
8 files changed, 152 insertions(+), 58 deletions(-)
^ permalink raw reply
* Re: Can I prevent someone clone my git repository?
From: Johannes Schindelin @ 2009-01-08 11:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Emily Ren, git
In-Reply-To: <7vr63e42ke.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 8 Jan 2009, Junio C Hamano wrote:
> The git-daemon transport deliberately omits authentication, and you
> cannot restrict when they come over the git native transport using a URL
> like git://your-host/repository.git
If the people are on different IPs, a hook can restrict who may clone,
since commit v1.6.1-rc1~109.
Ciao,
Dscho
^ permalink raw reply
* Re: collapsing commits with rebase
From: Johannes Schindelin @ 2009-01-08 11:07 UTC (permalink / raw)
To: Geoff Russell; +Cc: git
In-Reply-To: <93c3eada0901071759u2496835dy134d92613bf4244b@mail.gmail.com>
Hi,
On Thu, 8 Jan 2009, Geoff Russell wrote:
> On Thu, Jan 8, 2009 at 11:15 AM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > Alternatively, something like this should work for you:
> >
> > $ git checkout A
> > $ git read-tree -u -m D
> > $ git commit -m "My message"
> > $ git cherry-pick E
> > $ git cherry-pick F
>
> Plan B is looking good, because I'd generally like the commit message to
> be the concatenation of the messages for B,C and D.
Replace the commit call by this:
$ for commit in B C D
do
git cat-file commit $commit | sed '1,/^$/d'
# possibly add an empty line between the commit messages,
# git commit will strip away empty lines at the end.
done |
git commit -F -
Hth,
Dscho
^ permalink raw reply
* Re: Problems with large compressed binaries when converting from svn
From: Johan Herland @ 2009-01-08 10:01 UTC (permalink / raw)
To: Øyvind Harboe; +Cc: git
In-Reply-To: <c09652430901060455l5179888ep3c51ff4e3dd5a6ef@mail.gmail.com>
On Tuesday 06 January 2009, Øyvind Harboe wrote:
> I'm converting from svn and I've run into a
> problem with tar.gz and tar.bz2 compressed files.
>
> (This is a separate but only slightly related to previous post).
>
> In subversion we committed large tar.bz2/gz files. These files would
> change relatively rarely, but only very slightly. The trouble with the
> tar.bz2 format is that if the first byte changes, then the rest of the
> file will also be different. .zip does not have this problem, but .zip
> isn't a very friendly format for our purposes.
>
> Later on the tar.bz2/gz files started to change fairly often, but
> harddrives get bigger much more quickly than the .svn repository grows so
> we just kept doing things the same way rather than reeducate and
> reengineer the procedures.
>
> With .git we need to handle this differently somehow.
>
> Does git have some capability to store diffs of compressed files
> efficiently?
>
> The only other alternative I can think of is to commit uncompressed
> .tar files which is a bit of a bump in the road, but I suppose could be
> made to work.
Git can automate this for you. Take a look at the gitattributes(5) man page,
specifically the "filter" attribute. You should be able to set up filter
drivers for .tar.gz files that use "clean=gunzip" and "smudge=gzip" (and a
similar filter driver for .tar.bz2 files).
If I've understood this right (I haven't used this myself) your checkouts
should now have .tar.gz and .tar.bz2 files, even though Git only
stores .tar files internally (thus improving compression across versions
dramatically).
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH RFC] mailinfo: correctly handle multiline 'Subject:' header
From: Alexander Potashev @ 2009-01-08 10:08 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Junio C Hamano, git
In-Reply-To: <1230316721-14339-1-git-send-email-kirr@mns.spb.ru>
On 21:38 Fri 26 Dec , Kirill Smelkov wrote:
> When native language (RU) is in use, subject header usually contains several
> parts, e.g.
>
> Subject: [Navy-patches] [PATCH]
> =?utf-8?b?0JjQt9C80LXQvdGR0L0g0YHQv9C40YHQvtC6INC/0LA=?=
> =?utf-8?b?0LrQtdGC0L7QsiDQvdC10L7QsdGF0L7QtNC40LzRi9GFINC00LvRjyA=?=
> =?utf-8?b?0YHQsdC+0YDQutC4?=
>
> t/t5100/info0012 | 5 ++++
> t/t5100/msg0012 | 7 ++++++
> t/t5100/patch0012 | 30 +++++++++++++++++++++++++++++
> t/t5100/sample.mbox | 52 +++++++++++++++++++++++++++++++++++++++++++++++++++
> 6 files changed, 112 insertions(+), 2 deletions(-)
The testcases are too long, a minimal mbox with encoded "Subject:" would
be enough to test the mailinfo parser, it's all the you need to test
here.
^ permalink raw reply
* Re: Comments on Presentation Notes Request.
From: Jeff King @ 2009-01-08 9:56 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Tim Visher, git
In-Reply-To: <alpine.LNX.1.00.0901071654530.19665@iabervon.org>
On Wed, Jan 07, 2009 at 05:30:04PM -0500, Daniel Barkalow wrote:
> > So yes, you are much more likely to salvage useful (if not all) data
> > from developer repositories in the event of a crash. But I still think
> > it's crazy not to have a backup strategy for your DVCS repo.
>
> I think it's very important to have a backup strategy, but it's nice that
> the developers can get work done while the server is still down.
I think everything you said in your email was correct, and I agree with
it, but I just wanted to clarify one thing about what I said.
I really _do_ think you are better off in a disaster or backup situation
with a DVCS. Both this past year and 2007, Junio dropped off the face of
the git planet for a few weeks, and everyone seamlessly switched to
Shawn as maintainer. So I think of the DVCS model almost more as "high
availablity": even if you model your workflow around a central server,
it's easy to route around the failure.
It's just that I don't think these features totally _replace_ backups as
a concept. And I feel like that notion creeps up now and again in the
centralized versus distributed holy wars.
So I think we agree; I just wasn't sure if I gave the wrong impression
from my first email.
-Peff
^ permalink raw reply
* Re: collapsing commits with rebase
From: Geoff Russell @ 2009-01-08 9:49 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Miklos Vajna, git
In-Reply-To: <200901072039.12631.bss@iguanasuicide.net>
On 1/8/09, Boyd Stephen Smith Jr. <bss@iguanasuicide.net> wrote:
> On Wednesday 2009 January 07 20:32:24 Miklos Vajna wrote:
> >On Wed, Jan 07, 2009 at 08:11:32PM -0600, "Boyd Stephen Smith Jr."
> <bss@iguanasuicide.net> wrote:
> >> git merge -s sha(D)
> >
> >You probably mean --squash here, -s stands for --strategy - and I *hope*
> >you don't have git-sha(D) in your PATH, as a custom merge strategy. ;-)
>
Many thanks, now I have plenty of ways to think about!
Cheers,
Geoff.
^ permalink raw reply
* Re: Can I prevent someone clone my git repository?
From: Johannes Sixt @ 2009-01-08 9:41 UTC (permalink / raw)
To: Emily Ren; +Cc: Junio C Hamano, git
In-Reply-To: <856bfe0e0901080133q68d0008ao1abf9d235e70279e@mail.gmail.com>
Emily Ren schrieb:
> Could you give me a detailed steps on how to wrap git daemon by tcpd?
Sorry, no, I haven't done that myself. I would look into /etc/xinetd.d/*
how tcpd is used with other protocols and merge that information with the
examples in the man page of git daemon.
-- Hannes
^ permalink raw reply
* Re: Can I prevent someone clone my git repository?
From: Emily Ren @ 2009-01-08 9:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4965C07D.705@viscovery.net>
Hannes,
Could you give me a detailed steps on how to wrap git daemon by tcpd?
Junio,
I think gitosis can control readonly or writable, it can't control if
it's can be cloned. Am I right?
Thanks,
Emily
On Thu, Jan 8, 2009 at 4:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Junio C Hamano schrieb:
>> The git-daemon transport deliberately omits authentication, and you cannot
>> restrict when they come over the git native transport using a URL like
>> git://your-host/repository.git
>
> But you can wrap git daemon by tcpd and configure hosts.allow and
> hosts.deny (with all its caveats), if this suits your needs.
>
> -- Hannes
>
^ permalink raw reply
* Re: [PATCH] tutorial.txt renamed
From: Brian Foster @ 2009-01-08 9:21 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Brian Gernhardt, Christian Couder, Joey Hess
In-Reply-To: <7vljtnbpha.fsf@gitster.siamese.dyndns.org>
On Wednesday 07 January 2009 07:27:13 Junio C Hamano wrote:
> Brian Gernhardt <benji@silverinsanity.com> writes:
> > This is the README file for the project, so it should advise looking
> > at the Documentation directory as neither the man pages or git command
> > are likely installed at this point.
>
> I think that is a sane suggestion. It is better to keep the number of
> prerequisites to the minimum for the user in order to follow README (and
> INSTALL, of course).
It is indeed a sane suggestion. However, there is no (obvious?)
harm in *also* mentioning that ‘git help tutorial’ should also
display the tutorial. Something like “If git has been correctly
installed, then this tutorial can also be read with the command
‘git help tutorial’.”
cheers!
-blf-
--
“How many surrealists does it take to | Brian Foster
change a lightbulb? Three. One calms | somewhere in south of France
the warthog, and two fill the bathtub | Stop E$$o (ExxonMobil)!
with brightly-coloured machine tools.” | http://www.stopesso.com
^ 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