* Re: [PATCH] fast-import: Stream very large blobs directly to pack
From: Shawn O. Pearce @ 2010-02-04 2:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git, Nicolas Pitre
In-Reply-To: <7vk4utybur.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> And this is a fix-up for the mismerge. I didn't touch max-pack-size stuff.
>
> fast-import.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/fast-import.c b/fast-import.c
> index ca21082..a6730d0 100644
> --- a/fast-import.c
> +++ b/fast-import.c
> @@ -2800,7 +2800,10 @@ static int parse_one_option(const char *option)
> if (!prefixcmp(option, "max-pack-size=")) {
> option_max_pack_size(option + 14);
> } else if (!prefixcmp(option, "big-file-threshold=")) {
> - big_file_threshold = strtoumax(option + 19, NULL, 0) * 1024 * 1024;
> + unsigned long v;
> + if (!git_parse_ulong(option + 19, &v))
> + return 0;
> + big_file_threshold = v;
Yup, looks good to me.
--
Shawn.
^ permalink raw reply
* Re: pack.packSizeLimit, safety checks
From: Nicolas Pitre @ 2010-02-04 2:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sergio, git
In-Reply-To: <7v1vh1zr10.fsf@alter.siamese.dyndns.org>
On Wed, 3 Feb 2010, Junio C Hamano wrote:
> Nicolas Pitre <nico@fluxnic.net> writes:
>
> > Thing is... I don't know if the --max-pack-size argument is really that
> > used. I'd expect people relying on that feature to use the config
> > variable instead,...
>
> I suspect one of us need to be careful not to forget this thing...
Please hold on. I think I have a better patch.
Nicolas
^ permalink raw reply
* Re: http getpass function in msysgit
From: Junio C Hamano @ 2010-02-04 2:32 UTC (permalink / raw)
To: Frank Li; +Cc: Junio C Hamano, git, msysGit
In-Reply-To: <1976ea661002031756j2c2699b0hf7deb8febdce841b@mail.gmail.com>
Frank Li <lznuaa@gmail.com> writes:
> Can we direct use SSH_ASKPASS for all getpass and don't use GIT_ASKPASS at all?
> The logic will be come simple.
If you _really_ have to ask me,...
I'd suspect people would feel it funny if the only advertised interface
were SSH_*, especially when they don't use OpenSSH at all and setting up
the prompter solely to use git over http. If you use GIT_ASKPASS as the
advertised _primary_ interface to drive the prompter, while falling back
on SSH_ASKPASS as a mere end-user convenience measure, you wouldn't have
that problem. Hence my suggestion.
But in the end it's up to you to decide. I won't be writing this code
;-).
^ permalink raw reply
* Re: pack.packSizeLimit, safety checks
From: Junio C Hamano @ 2010-02-04 2:34 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Sergio, git
In-Reply-To: <alpine.LFD.2.00.1002032130270.1681@xanadu.home>
Nicolas Pitre <nico@fluxnic.net> writes:
>> I suspect one of us need to be careful not to forget this thing...
>
> Please hold on. I think I have a better patch.
Ok, I dropped both fast-import.c mismerge fix and the one you are
responding to.
^ permalink raw reply
* Re: [gitolite] symlink hooks instead of copying them
From: Sitaram Chamarty @ 2010-02-04 3:22 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Teemu Matilainen
In-Reply-To: <20100204014657.GA10114@lapse.rw.madduck.net>
On Thu, Feb 04, 2010 at 02:46:57PM +1300, martin f krafft wrote:
> also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1428 +1300]:
> > I'm ok with symlinking stuff; a couple of "cp" commands
> > would change to "ln" :) Let me try it out (and make sure it
> > works for upgrades also...)
>
> ln -sf even.
yup...
> also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1435 +1300]:
> > I forgot... part of the reason this "copy all hooks over each time
> > you run install" is also to give people an easy way to update the
> > hooks when the repo was *copied* from elsewhere, and not *created*
> > by gitolite in the first place.
> >
> > Basically I'm paranoid about that "update" hook, without which the
> > branch level access control doesn't work at all.
>
> Wouldn't it thus make sense to check during authentication that the
> symlink exists and points to the right file, and to deny access
> completely if that isn't the case?
Yeah I guess that's easy enough really... just need to
include a way to tell the code what is the right file to
point to. (Currently it's all inside $GL_ADMINDIR but in
the APT case that may not be true...?)
> Having a mass-update command for this might be nice, but I suppose
> it's also a trivial shell one-liner...
>
> for i (**/*.git/hooks/update) \
> ln -sf ~git/.gitolite/src/hooks/update $i
>
> (this is zsh, not sure bash can do this yet)
This has to work on systems that don't even have bash (like
plain old sh personality of ksh), leave alone zsh :)
Not saying it's hard; just a "find" in backticks. I'd still
rather put it inside the perl code somewhere that already
gets run anyway, as it is now...
^ permalink raw reply
* [PATCH 1/3] fix multiple issues with t5300
From: Nicolas Pitre @ 2010-02-04 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
First of all, trying to run 'git verify-pack' on packs produced by
the tests using pack.packSizeLimit always failed. After lots of digging
and head scratching, it turns out that the preceeding test simulating
a SHA1 collision did leave the repository quite confused, impacting
subsequent tests.
So let's move that destructive test last, and add tests to run
verify-pack on the output from those packSizeLimit tests to catch such
goofage.
Finally, group those packSizeLimit tests together.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
---
t/t5300-pack-object.sh | 54 ++++++++++++++++++++++++++++++-----------------
1 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
index e2aa254..ac81114 100755
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -280,26 +280,8 @@ test_expect_success \
:'
-test_expect_success \
- 'fake a SHA1 hash collision' \
- 'test -f .git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67 &&
- cp -f .git/objects/9d/235ed07cd19811a6ceb342de82f190e49c9f68 \
- .git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67'
-
-test_expect_success \
- 'make sure index-pack detects the SHA1 collision' \
- 'test_must_fail git index-pack -o bad.idx test-3.pack 2>msg &&
- grep "SHA1 COLLISION FOUND" msg'
-
-test_expect_success \
- 'honor pack.packSizeLimit' \
- 'git config pack.packSizeLimit 200 &&
- packname_4=$(git pack-objects test-4 <obj-list) &&
- test 3 = $(ls test-4-*.pack | wc -l)'
-
test_expect_success 'unpacking with --strict' '
- git config --unset pack.packsizelimit &&
for j in a b c d e f g
do
for i in 0 1 2 3 4 5 6 7 8 9
@@ -392,10 +374,42 @@ test_expect_success 'index-pack with --strict' '
)
'
+test_expect_success 'honor pack.packSizeLimit' '
+ git config pack.packSizeLimit 200 &&
+ packname_10=$(git pack-objects test-10 <obj-list) &&
+ test 3 = $(ls test-10-*.pack | wc -l)
+'
+
+test_expect_success 'verify resulting packs' '
+ git verify-pack test-10-*.pack
+'
+
test_expect_success 'tolerate absurdly small packsizelimit' '
git config pack.packSizeLimit 2 &&
- packname_9=$(git pack-objects test-9 <obj-list) &&
- test $(wc -l <obj-list) = $(ls test-9-*.pack | wc -l)
+ packname_11=$(git pack-objects test-11 <obj-list) &&
+ test $(wc -l <obj-list) = $(ls test-11-*.pack | wc -l)
'
+test_expect_success 'verify resulting packs' '
+ git verify-pack test-11-*.pack
+'
+
+#
+# WARNING!
+#
+# The following test is destructive. Please keep the next
+# two tests at the end of this file.
+#
+
+test_expect_success \
+ 'fake a SHA1 hash collision' \
+ 'test -f .git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67 &&
+ cp -f .git/objects/9d/235ed07cd19811a6ceb342de82f190e49c9f68 \
+ .git/objects/c8/2de19312b6c3695c0c18f70709a6c535682a67'
+
+test_expect_success \
+ 'make sure index-pack detects the SHA1 collision' \
+ 'test_must_fail git index-pack -o bad.idx test-3.pack 2>msg &&
+ grep "SHA1 COLLISION FOUND" msg'
+
test_done
--
1.7.0.rc1.149.g0b0b7
^ permalink raw reply related
* [PATCH 2/3] pack-objects: fix pack generation when using pack_size_limit
From: Nicolas Pitre @ 2010-02-04 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1265255308-20514-1-git-send-email-nico@fluxnic.net>
Current handling of pack_size_limit is quite suboptimal. Let's consider
a list of objects to pack which contain alternatively big and small
objects (which pretty matches reality when big blobs are interlaced
with tree objects). Currently, the code simply close the pack and opens
a new one when the next object in line breaks the size limit.
The current code may degenerate into:
- small tree object => store into pack #1
- big blob object busting the pack size limit => store into pack #2
- small blob but pack #2 is over the limit already => pack #3
- big blob busting the size limit => pack #4
- small tree but pack #4 is over the limit => pack #5
- big blob => pack #6
- small tree => pack #7
- ... and so on.
The reality is that the content of packs 1, 3, 5 and 7 could well be
stored more efficiently (and delta compressed) together in pack #1 if
the big blobs were not forcing an immediate transition to a new pack.
Incidentally this can be fixed pretty easily by simply skipping over
those objects that are too big to fit in the current pack while trying
the whole list of unwritten objects, and then that list considered from
the beginning again when a new pack is opened. This creates much fewer
smallish pack files and help making more predictable test cases for the
test suite.
This change made one of the self sanity checks useless so it is removed
as well. That check was rather redundant already anyway.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
---
builtin-pack-objects.c | 37 +++++++++++++------------------------
1 files changed, 13 insertions(+), 24 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 4a41547..3186035 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -246,7 +246,7 @@ static unsigned long write_object(struct sha1file *f,
type = entry->type;
- /* write limit if limited packsize and not first object */
+ /* apply size limit if limited packsize and not first object */
if (!pack_size_limit || !nr_written)
limit = 0;
else if (pack_size_limit <= write_offset)
@@ -443,11 +443,15 @@ static int write_one(struct sha1file *f,
/* offset is non zero if object is written already. */
if (e->idx.offset || e->preferred_base)
- return 1;
+ return -1;
- /* if we are deltified, write out base object first. */
- if (e->delta && !write_one(f, e->delta, offset))
- return 0;
+ /*
+ * If we are deltified, attempt to write out base object first.
+ * If that fails due to the pack size limit then the current
+ * object might still possibly fit undeltified within that limit.
+ */
+ if (e->delta)
+ write_one(f, e->delta, offset);
e->idx.offset = *offset;
size = write_object(f, e, *offset);
@@ -501,11 +505,9 @@ static void write_pack_file(void)
sha1write(f, &hdr, sizeof(hdr));
offset = sizeof(hdr);
nr_written = 0;
- for (; i < nr_objects; i++) {
- if (!write_one(f, objects + i, &offset))
- break;
- display_progress(progress_state, written);
- }
+ for (i = 0; i < nr_objects; i++)
+ if (write_one(f, objects + i, &offset) == 1)
+ display_progress(progress_state, written);
/*
* Did we write the wrong # entries in the header?
@@ -580,26 +582,13 @@ static void write_pack_file(void)
written_list[j]->offset = (off_t)-1;
}
nr_remaining -= nr_written;
- } while (nr_remaining && i < nr_objects);
+ } while (nr_remaining);
free(written_list);
stop_progress(&progress_state);
if (written != nr_result)
die("wrote %"PRIu32" objects while expecting %"PRIu32,
written, nr_result);
- /*
- * We have scanned through [0 ... i). Since we have written
- * the correct number of objects, the remaining [i ... nr_objects)
- * items must be either already written (due to out-of-order delta base)
- * or a preferred base. Count those which are neither and complain if any.
- */
- for (j = 0; i < nr_objects; i++) {
- struct object_entry *e = objects + i;
- j += !e->idx.offset && !e->preferred_base;
- }
- if (j)
- die("wrote %"PRIu32" objects as expected but %"PRIu32
- " unwritten", written, j);
}
static int locate_object_entry_hash(const unsigned char *sha1)
--
1.7.0.rc1.149.g0b0b7
^ permalink raw reply related
* [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Nicolas Pitre @ 2010-02-04 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1265255308-20514-1-git-send-email-nico@fluxnic.net>
The value passed to --max-pack-size used to count in MiB which was
inconsistent with the corresponding configuration variable as well as
other command arguments which are defined to count in bytes with an
optional unit suffix. This brings --max-pack-size in line with the
rest of Git.
Also, in order not to cause havoc with people used to the previous
megabyte scale, and because this is a sane thing to do anyway, a
minimum size of 1 MiB is enforced to avoid an explosion of pack files.
Adjust and extend test suite accordingly.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
---
Documentation/RelNotes-1.7.0.txt | 8 +++++++-
Documentation/config.txt | 11 +++++++----
Documentation/git-pack-objects.txt | 5 +++--
Documentation/git-repack.txt | 8 +++++---
builtin-pack-objects.c | 11 ++++++-----
t/t5300-pack-object.sh | 14 ++++++++------
6 files changed, 36 insertions(+), 21 deletions(-)
diff --git a/Documentation/RelNotes-1.7.0.txt b/Documentation/RelNotes-1.7.0.txt
index 323ae54..e66945c 100644
--- a/Documentation/RelNotes-1.7.0.txt
+++ b/Documentation/RelNotes-1.7.0.txt
@@ -38,7 +38,7 @@ Notes on behaviour change
whitespaces is reported with zero exit status when run with
--exit-code, and there is no "diff --git" header for such a change.
- * external diff and textconv helpers are now executed using the shell.
+ * External diff and textconv helpers are now executed using the shell.
This makes them consistent with other programs executed by git, and
allows you to pass command-line parameters to the helpers. Any helper
paths containing spaces or other metacharacters now need to be
@@ -46,6 +46,12 @@ Notes on behaviour change
environment, and diff.*.command and diff.*.textconv in the config
file.
+ * The --max-pack-size argument to 'git repack' and 'git pack-objects' was
+ assuming the provided size to be expressed in MiB, unlike the
+ corresponding config variable and other similar options accepting a size
+ value. It is now expecting a size expressed in bytes, with a possible
+ unit suffix of 'k', 'm', or 'g'.
+
Updates since v1.6.6
--------------------
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 36ad992..4c36aa9 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1368,10 +1368,13 @@ you can use linkgit:git-index-pack[1] on the *.pack file to regenerate
the `{asterisk}.idx` file.
pack.packSizeLimit::
- The default maximum size of a pack. This setting only affects
- packing to a file, i.e. the git:// protocol is unaffected. It
- can be overridden by the `\--max-pack-size` option of
- linkgit:git-repack[1].
+ The maximum size of a pack. This setting only affects
+ packing to a file when repacking, i.e. the git:// protocol
+ is unaffected. It can be overridden by the `\--max-pack-size`
+ option of linkgit:git-repack[1]. The minimum size allowed is
+ limited to 1 MiB. The default is unlimited.
+ Common unit suffixes of 'k', 'm', or 'g' are
+ supported.
pager.<cmd>::
Allows turning on or off pagination of the output of a
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index 097a147..ffd5025 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -105,8 +105,9 @@ base-name::
`--window-memory=0` makes memory usage unlimited, which is the
default.
---max-pack-size=<n>::
- Maximum size of each output packfile, expressed in MiB.
+--max-pack-size=[N]::
+ Maximum size of each output pack file. The size can be suffixed with
+ "k", "m", or "g". The minimum size allowed is limited to 1 MiB.
If specified, multiple packfiles may be created.
The default is unlimited, unless the config variable
`pack.packSizeLimit` is set.
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 538895c..e2f2fa2 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -98,10 +98,12 @@ other objects in that pack they already have locally.
`--window-memory=0` makes memory usage unlimited, which is the
default.
---max-pack-size=<n>::
- Maximum size of each output packfile, expressed in MiB.
+--max-pack-size=[N]::
+ Maximum size of each output pack file. The size can be suffixed with
+ "k", "m", or "g". The minimum size allowed is limited to 1 MiB.
If specified, multiple packfiles may be created.
- The default is unlimited.
+ The default is unlimited, unless the config variable
+ `pack.packSizeLimit` is set.
Configuration
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 3186035..dcfe62a 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -77,7 +77,7 @@ static int allow_ofs_delta;
static const char *base_name;
static int progress = 1;
static int window = 10;
-static uint32_t pack_size_limit, pack_size_limit_cfg;
+static unsigned long pack_size_limit, pack_size_limit_cfg;
static int depth = 50;
static int delta_search_threads;
static int pack_to_stdout;
@@ -2192,10 +2192,8 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
continue;
}
if (!prefixcmp(arg, "--max-pack-size=")) {
- char *end;
pack_size_limit_cfg = 0;
- pack_size_limit = strtoul(arg+16, &end, 0) * 1024 * 1024;
- if (!arg[16] || *end)
+ if (!git_parse_ulong(arg+16, &pack_size_limit))
usage(pack_usage);
continue;
}
@@ -2335,9 +2333,12 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
if (!pack_to_stdout && !pack_size_limit)
pack_size_limit = pack_size_limit_cfg;
-
if (pack_to_stdout && pack_size_limit)
die("--max-pack-size cannot be used to build a pack for transfer.");
+ if (pack_size_limit && pack_size_limit < 1024*1024) {
+ warning("minimum pack size limit is 1 MiB");
+ pack_size_limit = 1024*1024;
+ }
if (!pack_to_stdout && thin)
die("--thin cannot be used to build an indexable pack.");
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
index ac81114..c80f3a3 100755
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -16,7 +16,9 @@ test_expect_success \
perl -e "print \"a\" x 4096;" > a &&
perl -e "print \"b\" x 4096;" > b &&
perl -e "print \"c\" x 4096;" > c &&
- git update-index --add a b c &&
+ test-genrandom "seed a" 2097152 > a_big &&
+ test-genrandom "seed b" 2097152 > b_big &&
+ git update-index --add a a_big b b_big c &&
cat c >d && echo foo >>d && git update-index --add d &&
tree=`git write-tree` &&
commit=`git commit-tree $tree </dev/null` && {
@@ -375,19 +377,19 @@ test_expect_success 'index-pack with --strict' '
'
test_expect_success 'honor pack.packSizeLimit' '
- git config pack.packSizeLimit 200 &&
+ git config pack.packSizeLimit 3m &&
packname_10=$(git pack-objects test-10 <obj-list) &&
- test 3 = $(ls test-10-*.pack | wc -l)
+ test 2 = $(ls test-10-*.pack | wc -l)
'
test_expect_success 'verify resulting packs' '
git verify-pack test-10-*.pack
'
-test_expect_success 'tolerate absurdly small packsizelimit' '
- git config pack.packSizeLimit 2 &&
+test_expect_success 'tolerate packsizelimit smaller than biggest object' '
+ git config pack.packSizeLimit 1 &&
packname_11=$(git pack-objects test-11 <obj-list) &&
- test $(wc -l <obj-list) = $(ls test-11-*.pack | wc -l)
+ test 3 = $(ls test-11-*.pack | wc -l)
'
test_expect_success 'verify resulting packs' '
--
1.7.0.rc1.149.g0b0b7
^ permalink raw reply related
* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Shawn O. Pearce @ 2010-02-04 4:00 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <1265255308-20514-3-git-send-email-nico@fluxnic.net>
Nicolas Pitre <nico@fluxnic.net> wrote:
> The value passed to --max-pack-size used to count in MiB which was
> inconsistent with the corresponding configuration variable as well as
> other command arguments which are defined to count in bytes with an
> optional unit suffix. This brings --max-pack-size in line with the
> rest of Git.
...
> Documentation/RelNotes-1.7.0.txt | 8 +++++++-
> Documentation/config.txt | 11 +++++++----
> Documentation/git-pack-objects.txt | 5 +++--
> Documentation/git-repack.txt | 8 +++++---
> builtin-pack-objects.c | 11 ++++++-----
> t/t5300-pack-object.sh | 14 ++++++++------
> 6 files changed, 36 insertions(+), 21 deletions(-)
Shouldn't we also change fast-import.c ?
--
Shawn.
^ permalink raw reply
* Re: [gitolite] repo config for delegated projects
From: martin f krafft @ 2010-02-04 4:08 UTC (permalink / raw)
To: Sitaram Chamarty, git discussion list, Sitaram Chamarty,
Teemu Matilainen
In-Reply-To: <20100204011842.GB497@atcmail.atc.tcs.com>
[-- Attachment #1: Type: text/plain, Size: 423 bytes --]
also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1418 +1300]:
> how about
>
> $DELEGATED_CONFIGS = "hooks.mailinglist,hooks.showrev";
Excellent idea.
--
martin | http://madduck.net/ | http://two.sentenc.es/
now I lay me back to sleep.
the speaker's dull; the subject's deep.
if he should stop before I wake,
give me a nudge for goodness' sake.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [gitolite] symlink hooks instead of copying them
From: martin f krafft @ 2010-02-04 4:13 UTC (permalink / raw)
To: git discussion list; +Cc: Sitaram Chamarty, Teemu Matilainen
In-Reply-To: <20100204032239.GA5429@atcmail.atc.tcs.com>
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1622 +1300]:
> > Wouldn't it thus make sense to check during authentication that
> > the symlink exists and points to the right file, and to deny
> > access completely if that isn't the case?
>
> Yeah I guess that's easy enough really... just need to include
> a way to tell the code what is the right file to point to.
> (Currently it's all inside $GL_ADMINDIR but in the APT case that
> may not be true...?)
How about comparing the hash sums of where you think the file is?
This would also ensure that repo access was disallowed if the hook
hasn't been upgraded without symlinks (though I think the symlinks
are still better than copies, and more expressive too). Does that
fit your level of security-paranoia? ;)
About the APT case — leave that to us. If we distribute gitolite
from /usr/share/gitolite, then we'll probably be patching the entire
source anyway. Obviously, if it proves viable, then it might make
sense to bring back that functionality and have it configurable at
install or runtime.
> This has to work on systems that don't even have bash (like plain
> old sh personality of ksh), leave alone zsh :)
>
> Not saying it's hard; just a "find" in backticks. I'd still
> rather put it inside the perl code somewhere that already gets run
> anyway, as it is now...
No objection.
Thanks!
--
martin | http://madduck.net/ | http://two.sentenc.es/
tempt not a desperate man.
-- william shakespeare
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* rebase vs rebase -i
From: Jay Soffian @ 2010-02-04 4:19 UTC (permalink / raw)
To: git
Why does git rebase use format-patch + am, while rebase -i uses cherry-pick?
Just curious. In particular though, it seems especially odd in this case:
$ git rebase --onto <newbase> <upstream>
vs
$ env GIT_EDITOR=true git rebase -i --onto <newbase> <upstream>
Both in theory produce an identical end-result, while using two
different implementations.
(Here I'm setting GIT_EDITOR=true just to demonstrate that I didn't
change the list of commits in the latter case.)
j.
^ permalink raw reply
* Re: [PATCH 3/3] make --max-pack-size argument to 'git pack-object' count in bytes
From: Junio C Hamano @ 2010-02-04 4:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Nicolas Pitre, Junio C Hamano, git
In-Reply-To: <20100204040046.GR14799@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Nicolas Pitre <nico@fluxnic.net> wrote:
>> The value passed to --max-pack-size used to count in MiB which was
>> inconsistent with the corresponding configuration variable as well as
>> other command arguments which are defined to count in bytes with an
>> optional unit suffix. This brings --max-pack-size in line with the
>> rest of Git.
> ...
>> Documentation/RelNotes-1.7.0.txt | 8 +++++++-
>> Documentation/config.txt | 11 +++++++----
>> Documentation/git-pack-objects.txt | 5 +++--
>> Documentation/git-repack.txt | 8 +++++---
>> builtin-pack-objects.c | 11 ++++++-----
>> t/t5300-pack-object.sh | 14 ++++++++------
>> 6 files changed, 36 insertions(+), 21 deletions(-)
>
> Shouldn't we also change fast-import.c ?
Surely; could you do the honors? I cannot really decide how big the deal
would be to break backward compatibility for max-pack-size myself.
^ permalink raw reply
* [PATCH] Typofixes outside documentation area
From: Junio C Hamano @ 2010-02-04 5:31 UTC (permalink / raw)
To: git
begining -> beginning
canonicalizations -> canonicalization
comand -> command
dewrapping -> unwrapping
dirtyness -> dirtiness
DISCLAMER -> DISCLAIMER
explicitely -> explicitly
feeded -> fed
impiled -> implied
madatory -> mandatory
mimick -> mimic
preceeding -> preceding
reqeuest -> request
substition -> substitution
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-apply.c | 2 +-
builtin-cat-file.c | 5 +++--
builtin-log.c | 2 +-
builtin-prune.c | 2 +-
builtin-show-branch.c | 2 +-
compat/win32/pthread.c | 2 +-
connect.c | 2 +-
contrib/fast-import/import-directories.perl | 2 +-
daemon.c | 2 +-
diff.c | 2 +-
levenshtein.h | 2 +-
path.c | 2 +-
perl/Git.pm | 4 ++--
refs.c | 2 +-
setup.c | 2 +-
test-chmtime.c | 2 +-
transport-helper.c | 2 +-
17 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 2a1004d..3af4ae0 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2006,7 +2006,7 @@ static int find_pos(struct image *img,
return -1;
/*
- * If match_begining or match_end is specified, there is no
+ * If match_beginning or match_end is specified, there is no
* point starting from a wrong line that will never match and
* wander around and wait for a match at the specified end.
*/
diff --git a/builtin-cat-file.c b/builtin-cat-file.c
index 5906842..a933eaa 100644
--- a/builtin-cat-file.c
+++ b/builtin-cat-file.c
@@ -219,9 +219,10 @@ int cmd_cat_file(int argc, const char **argv, const char *prefix)
"exit with zero when there's no error", 'e'),
OPT_SET_INT('p', NULL, &opt, "pretty-print object's content", 'p'),
OPT_SET_INT(0, "batch", &batch,
- "show info and content of objects feeded on stdin", BATCH),
+ "show info and content of objects fed from the standard input",
+ BATCH),
OPT_SET_INT(0, "batch-check", &batch,
- "show info about objects feeded on stdin",
+ "show info about objects fed from the standard input",
BATCH_CHECK),
OPT_END()
};
diff --git a/builtin-log.c b/builtin-log.c
index 8d16832..e0d5caa 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -1089,7 +1089,7 @@ int cmd_format_patch(int argc, const char **argv, const char *prefix)
/*
* We cannot move this anywhere earlier because we do want to
- * know if --root was given explicitly from the comand line.
+ * know if --root was given explicitly from the command line.
*/
rev.show_root_diff = 1;
diff --git a/builtin-prune.c b/builtin-prune.c
index 8459aec..4675f60 100644
--- a/builtin-prune.c
+++ b/builtin-prune.c
@@ -106,7 +106,7 @@ static void prune_object_dir(const char *path)
/*
* Write errors (particularly out of space) can result in
* failed temporary packs (and more rarely indexes and other
- * files begining with "tmp_") accumulating in the object
+ * files beginning with "tmp_") accumulating in the object
* and the pack directories.
*/
static void remove_temporary_files(const char *path)
diff --git a/builtin-show-branch.c b/builtin-show-branch.c
index 9f13caa..35a709e 100644
--- a/builtin-show-branch.c
+++ b/builtin-show-branch.c
@@ -567,7 +567,7 @@ static int git_show_branch_config(const char *var, const char *value, void *cb)
return config_error_nonbool(var);
/*
* default_arg is now passed to parse_options(), so we need to
- * mimick the real argv a bit better.
+ * mimic the real argv a bit better.
*/
if (!default_num) {
default_alloc = 20;
diff --git a/compat/win32/pthread.c b/compat/win32/pthread.c
index 5fc1670..0f949fc 100644
--- a/compat/win32/pthread.c
+++ b/compat/win32/pthread.c
@@ -1,7 +1,7 @@
/*
* Copyright (C) 2009 Andrzej K. Haczewski <ahaczewski@gmail.com>
*
- * DISCLAMER: The implementation is Git-specific, it is subset of original
+ * DISCLAIMER: The implementation is Git-specific, it is subset of original
* Pthreads API, without lots of other features that Git doesn't use.
* Git also makes sure that the passed arguments are valid, so there's
* no need for double-checking.
diff --git a/connect.c b/connect.c
index 20054e4..a37cf6a 100644
--- a/connect.c
+++ b/connect.c
@@ -504,7 +504,7 @@ struct child_process *git_connect(int fd[2], const char *url_orig,
/*
* Don't do destructive transforms with git:// as that
- * protocol code does '[]' dewrapping of its own.
+ * protocol code does '[]' unwrapping of its own.
*/
if (host[0] == '[') {
end = strchr(host + 1, ']');
diff --git a/contrib/fast-import/import-directories.perl b/contrib/fast-import/import-directories.perl
index 5782d80..3a5da4a 100755
--- a/contrib/fast-import/import-directories.perl
+++ b/contrib/fast-import/import-directories.perl
@@ -344,7 +344,7 @@ sub parsekeyvaluepair
Key and value strings may be enclosed in quotes, in which case
whitespace inside the quotes is preserved. Additionally, an equal
-sign may be included in the key by preceeding it with a backslash.
+sign may be included in the key by preceding it with a backslash.
For example:
"key1 "=value1
diff --git a/daemon.c b/daemon.c
index 6c2bd97..3769b6f 100644
--- a/daemon.c
+++ b/daemon.c
@@ -407,7 +407,7 @@ static void parse_host_and_port(char *hostport, char **host,
end = strchr(hostport, ']');
if (!end)
- die("Invalid reqeuest ('[' without ']')");
+ die("Invalid request ('[' without ']')");
*end = '\0';
*host = hostport + 1;
if (!end[1])
diff --git a/diff.c b/diff.c
index 381cc8d..9038057 100644
--- a/diff.c
+++ b/diff.c
@@ -3642,7 +3642,7 @@ static void diffcore_skip_stat_unmatch(struct diff_options *diffopt)
struct diff_filepair *p = q->queue[i];
/*
- * 1. Entries that come from stat info dirtyness
+ * 1. Entries that come from stat info dirtiness
* always have both sides (iow, not create/delete),
* one side of the object name is unknown, with
* the same mode and size. Keep the ones that
diff --git a/levenshtein.h b/levenshtein.h
index 0173abe..4105bf3 100644
--- a/levenshtein.h
+++ b/levenshtein.h
@@ -2,7 +2,7 @@
#define LEVENSHTEIN_H
int levenshtein(const char *string1, const char *string2,
- int swap_penalty, int substition_penalty,
+ int swap_penalty, int substitution_penalty,
int insertion_penalty, int deletion_penalty);
#endif
diff --git a/path.c b/path.c
index 79aa104..e166d53 100644
--- a/path.c
+++ b/path.c
@@ -610,7 +610,7 @@ int daemon_avoid_alias(const char *p)
/*
* This resurrects the belts and suspenders paranoia check by HPA
* done in <435560F7.4080006@zytor.com> thread, now enter_repo()
- * does not do getcwd() based path canonicalizations.
+ * does not do getcwd() based path canonicalization.
*
* sl becomes true immediately after seeing '/' and continues to
* be true as long as dots continue after that without intervening
diff --git a/perl/Git.pm b/perl/Git.pm
index e8df55d..970fe43 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -204,14 +204,14 @@ sub repository {
$dir = $opts{Directory};
unless (-d "$dir/refs" and -d "$dir/objects" and -e "$dir/HEAD") {
- # Mimick git-rev-parse --git-dir error message:
+ # Mimic git-rev-parse --git-dir error message:
throw Error::Simple("fatal: Not a git repository: $dir");
}
my $search = Git->repository(Repository => $dir);
try {
$search->command('symbolic-ref', 'HEAD');
} catch Git::Error::Command with {
- # Mimick git-rev-parse --git-dir error message:
+ # Mimic git-rev-parse --git-dir error message:
throw Error::Simple("fatal: Not a git repository: $dir");
}
diff --git a/refs.c b/refs.c
index 503a8c2..f3fcbe0 100644
--- a/refs.c
+++ b/refs.c
@@ -706,7 +706,7 @@ int for_each_glob_ref_in(each_ref_fn fn, const char *pattern,
has_glob_specials = strpbrk(pattern, "?*[");
if (!has_glob_specials) {
- /* Append impiled '/' '*' if not present. */
+ /* Append implied '/' '*' if not present. */
if (real_pattern.buf[real_pattern.len - 1] != '/')
strbuf_addch(&real_pattern, '/');
/* No need to check for '*', there is none. */
diff --git a/setup.c b/setup.c
index 710e2f3..fac34f7 100644
--- a/setup.c
+++ b/setup.c
@@ -206,7 +206,7 @@ int is_inside_work_tree(void)
}
/*
- * set_work_tree() is only ever called if you set GIT_DIR explicitely.
+ * set_work_tree() is only ever called if you set GIT_DIR explicitly.
* The old behaviour (which we retain here) is to set the work tree root
* to the cwd, unless overridden by the config, the command line, or
* GIT_WORK_TREE.
diff --git a/test-chmtime.c b/test-chmtime.c
index fe476cb..92713d1 100644
--- a/test-chmtime.c
+++ b/test-chmtime.c
@@ -1,7 +1,7 @@
/*
* This program can either change modification time of the given
* file(s) or just print it. The program does not change atime nor
- * ctime (their values are explicitely preserved).
+ * ctime (their values are explicitly preserved).
*
* The mtime can be changed to an absolute value:
*
diff --git a/transport-helper.c b/transport-helper.c
index 1077428..f822972 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -171,7 +171,7 @@ static struct child_process *get_helper(struct transport *transport)
} else if (!strcmp(capname, "connect")) {
data->connect = 1;
} else if (mandatory) {
- die("Unknown madatory capability %s. This remote "
+ die("Unknown mandatory capability %s. This remote "
"helper probably needs newer version of Git.\n",
capname);
}
--
1.7.0.rc1.199.g9253ab
^ permalink raw reply related
* Re: [gitolite] symlink hooks instead of copying them
From: Bill Lear @ 2010-02-04 6:17 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list, Sitaram Chamarty, Teemu Matilainen
In-Reply-To: <20100204014657.GA10114@lapse.rw.madduck.net>
On Thursday, February 4, 2010 at 14:46:57 (+1300) martin f krafft writes:
>also sprach Sitaram Chamarty <sitaram@atc.tcs.com> [2010.02.04.1428 +1300]:
>> I'm ok with symlinking stuff; a couple of "cp" commands
>> would change to "ln" :) Let me try it out (and make sure it
>> works for upgrades also...)
>
>ln -sf even.
Does 'ln -sf' work reliably on all distros? I seem to recall on Ubuntu
7.10 that this was broken.
Bill
^ permalink raw reply
* Re: extra headers in commit objects
From: Mike Hommey @ 2010-02-04 6:24 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Scott Chacon, git
In-Reply-To: <20100203224835.GK14799@spearce.org>
On Wed, Feb 03, 2010 at 02:48:35PM -0800, Shawn O. Pearce wrote:
> > Anyhow, I was saying that _technically_ you can artificially write
> > extra headers into the commit object (though at the time Dulwich
> > didn't support reading them because of how it parsed commit objects -
> > I believe it would actually explode if it saw something it didn't
> > expect). I said I was still going to keep the metadata in my
> > implementation in the message, but he was very interested in hiding
> > his in the commit headers.
>
> Yea, everyone wants to hide that extra metadata. I never get why.
> Even in SVN. Why wouldn't I want to see the bug(s) fixed by
> a commit? Difference of opinion. I also happen to prefer the
> color blue. Dammit, everyone should prefer blue.
Note, though, that such information may change in the future, in which
case you can't rewrite the commit to fit that.
But for all that, there are git-notes, now, aren't there ?
Mike
^ permalink raw reply
* What's cooking in git.git (Feb 2010, #01; Wed, 03)
From: Junio C Hamano @ 2010-02-04 6:28 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
We are passed 1.7.0-rc1; please test "master" branch to avoid giving
regressions to end users. Thanks.
--------------------------------------------------
[Graduated to "master"]
* bw/no-python-autoconf (2010-01-31) 2 commits
(merged to 'next' on 2010-02-01 at 7c70402)
+ configure: Allow --without-python
+ configure: Allow GIT_ARG_SET_PATH to handle --without-PROGRAM
* ms/filter-branch-submodule (2010-01-28) 2 commits
(merged to 'next' on 2010-01-28 at 226cbf8)
+ filter-branch: Add tests for submodules in tree-filter
+ filter-branch: Fix to allow replacing submodules with another content
* sp/maint-fast-import-large-blob (2010-02-01) 1 commit
(merged to 'next' on 2010-02-01 at 04d206f)
+ fast-import: Stream very large blobs directly to pack
(this branch is used by sp/fast-import-large-blob.)
Importing a large blob via fast-import may bust the pack size limit (or
2GB filesize limit found on some filesystems).
* sp/fast-import-large-blob (2010-02-01) 0 commits
(this branch uses sp/maint-fast-import-large-blob.)
And this is to help merging the topic to newer codebase.
--------------------------------------------------
[New Topics]
* jc/typo (2010-02-03) 1 commit
- Typofixes outside documentation area
--------------------------------------------------
[Cooking]
* jn/maint-makedepend (2010-01-26) 5 commits
- Makefile: drop dependency on $(wildcard */*.h)
- Makefile: clean up http-walker.o dependency rules
- Makefile: remove wt-status.h from LIB_H
- Makefile: make sure test helpers are rebuilt when headers change
- Makefile: add missing header file dependencies
(this branch is used by jn/makedepend and jn/master-makedepend.)
These look sensible clean-up that could go to maint later.
* jn/master-makedepend (2010-01-26) 0 commits
(this branch uses jn/maint-makedepend; is used by jn/makedepend.)
This is to help merging the clean-up to "master".
* jn/makedepend (2010-01-31) 9 commits
- Makefile: always remove .depend directories on 'make clean'
- Makefile: tuck away generated makefile fragments in .depend
- Teach Makefile to check header dependencies
- Makefile: list standalone program object files in PROGRAM_OBJS
- Makefile: lazily compute header dependencies
- Makefile: list generated object files in OBJECTS
- Makefile: disable default implicit rules
- Makefile: rearrange dependency rules
- Makefile: transport.o depends on branch.h now
(this branch uses jn/maint-makedepend and jn/master-makedepend.)
And this is to build on top. I don't want to touch build infrastructure
during the pre-release freeze too much to avoid the last minute hassles
that is only discovered when I try to cut RPMs; hence this will stay out
of 'master' until 1.7.0 ships.
* jc/checkout-detached (2010-01-29) 1 commit
- Reword "detached HEAD" notification
* jc/maint-fix-test-perm (2010-01-30) 2 commits
- lib-patch-mode.sh: Fix permission
- t6000lib: Fix permission
* jh/gitweb-caching (2010-01-30) 1 commit
- gitweb: Add an option to force version match
* jn/makefile-script-lib (2010-01-31) 1 commit
- Do not install shell libraries executable
* mv/request-pull-modernize (2010-01-29) 1 commit
- request-pull: avoid mentioning that the start point is a single commit
* cc/reset-keep (2010-01-19) 5 commits
- reset: disallow using --keep when there are unmerged entries
- reset: disallow "reset --keep" outside a work tree
- Documentation: reset: describe new "--keep" option
- reset: add test cases for "--keep" option
- reset: add option "--keep" to "git reset"
I do not think I'd ever use this, and I am not convinced I can sell this
to users as a great new feature without confusing them unnecessarily, but
perhaps queuing it to pu to give it wider visibility may help somebody
coming up with a better way to defend the feature and introduce it to
users without confusing them than Christan nor I managed to.
* jh/notes (2010-01-27) 23 commits
- builtin-notes: Add "add" subcommand for appending to note objects
- builtin-notes: Add "list" subcommand for listing note objects
- Documentation: Generalize git-notes docs to 'objects' instead of 'commits'
- builtin-notes: Add "prune" subcommand for removing notes for missing objects
- Notes API: prune_notes(): Prune notes that belong to non-existing objects
- t3305: Verify that removing notes triggers automatic fanout consolidation
- builtin-notes: Add "remove" subcommand for removing existing notes
- Teach builtin-notes to remove empty notes
- Teach notes code to properly preserve non-notes in the notes tree
- t3305: Verify that adding many notes with git-notes triggers increased fanout
- t3301: Verify successful annotation of non-commits
- Builtin-ify git-notes
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: write_notes_tree(): Store the notes tree in the database
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: remove_note(): Remove note objects from the notes tree structure
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Add tests for checking correct handling of $GIT_NOTES_REF and core.notesRef
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Cosmetic fixes to notes.c
* jc/grep-author-all-match-implicit (2010-01-17) 1 commit
- "log --author=me --grep=it" should find intersection, not union
^ permalink raw reply
* Re: [gitolite] symlink hooks instead of copying them
From: martin f krafft @ 2010-02-04 6:34 UTC (permalink / raw)
To: git discussion list; +Cc: Bill Lear, Sitaram Chamarty, Teemu Matilainen
In-Reply-To: <19306.26226.369115.104150@blake.zopyra.com>
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
also sprach Bill Lear <rael@zopyra.com> [2010.02.04.1917 +1300]:
> Does 'ln -sf' work reliably on all distros? I seem to recall on Ubuntu
> 7.10 that this was broken.
unlink && symlink in Perl is probably preferably anyway.
--
martin | http://madduck.net/ | http://two.sentenc.es/
because light travels faster than sound,
some people appear to be intelligent,
until you hear them speak.
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Fix signal handler
From: Andreas Ericsson @ 2010-02-04 7:23 UTC (permalink / raw)
To: Markus Elfring; +Cc: Thomas Rast, Jeff King, git
In-Reply-To: <4B69A34B.7010309@web.de>
On 02/03/2010 05:24 PM, Markus Elfring wrote:
>
>>
>> The general feeling on this list is that patches are listened to, no
>> matter how foul they are, and you will get a (hopefully) polite
>> rejection if it is considered useless because it addresses a problem
>> that doesn't exist.
>>
>
> I hope that a healthy balance will be found between correct software
> design, development and quick "hacking".
What's considered a "healthy balance" varies from person to person
though.
> There might also be more
> efforts if too many patches will be rejected just because the suggested
> and planned changes were not discussed before.
>
Perhaps, but those wasted efforts would have been yours, not ours. Sorry,
but the sad fact is that unless you're willing to "fix" this (which you
should show by submitting patches), it's entirely uninteresting to even
discuss it. We're all busy folks here, and we do not have unlimited time
on our hands to masturbate mentally when most of us realize that it's
not a practical approach to blindly follow standards.
> Would you like to get an acknowledgement for signal handler problems
> from people in other discussion groups like "comp.programming.threads"?
>
No. I have no interest in theoretical best practices for a program that
has no known issues with its use of multiple threads.
I do have interest in bug-reports about my favourite scm and patches to
make it better. So far you have only shown a willingness to discuss
possible problems instead of real-world ones. I've mentally marked you
down as "the threads theory troll". To remedy that sad title, you should
deliver some patches pointing out and fixing problems in the sources.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Implement --password option for git svn perl script
From: Laszlo Papp @ 2010-02-04 7:45 UTC (permalink / raw)
To: Frank Li; +Cc: Eric Wong, Tay Ray Chuan, git
In-Reply-To: <1976ea661002021547ue22909cy27009c1b8743ecd4@mail.gmail.com>
On Wed, Feb 3, 2010 at 12:47 AM, Frank Li <lznuaa@gmail.com> wrote:
> Is it possible use OpenSSH method to let GUI to input passwd.
> environment SSH_ASKPASS, which point to a application. when
> passwd need, openssh launch this GUI application, user can input
> passwd at this GUI application.
>
What do you mean ? Should I install TortoiseGIT with openssh client,
so should I need to choose this option from the 2 facilities ?
Best Regards,
Laszlo Papp
^ permalink raw reply
* Dealing with many many git repos in a /home directory
From: demerphq @ 2010-02-04 8:29 UTC (permalink / raw)
To: Git
At $work we have a host where we have about 50-100 users each with
their own private copies of the same repos. These are cloned froma
remote via git/ssh and are not thus automatically hardlinking their
object stores.
This is starting to take a lot of space.
I was thinking it should be possible to hardlink all of the objects in
the different repos to a canonical single copy.
Would i be correct in thinking that if i have to repos with an
equivalent .git/objects/../..... file in them that the files are
necessarily identical and one can be replaced by a hardlink to the
other?
If this is correct then is there some tool known to the list that
already does this? I whipped this together:
find /home -regex .\*/.git/objects/.\* | perl -lne'if
(m!(\.git/objects/../.+)!) { if (my $t= $seen{$1}) { link $t,$_ } else
{ $seen{$1}=$_ } }'
But a proper script with a sign off of some git dev would make me feel
a lot safer :-)
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Making custom git-remove-tree command
From: Teemu Likonen @ 2010-02-04 9:03 UTC (permalink / raw)
To: git
I'm doing a script named git-remove-tree which removes the working tree
known to Git. It doesn't touch untracked files; it only deletes
directories if they are empty. The script seems to work, but because I'm
not very good at Git plumbing and there can be some corner cases which I
don't know about, I'd appreciate if more experienced users would have a
look. Is the following script safe?
#!/bin/sh
# git-remove-tree
is_wt=$(git rev-parse --is-inside-work-tree)
if [ "$is_wt" = false ]; then
echo "You must run this inside a working tree."
exit 1
elif [ -z "$is_wt" ]; then
exit 1
fi
top=$(git rev-parse --show-toplevel)
cd "$top" || {
echo "Can't go to top-level directory $top"
exit 1
}
git ls-tree --name-only -r -z HEAD | xargs -0r -- sh -c '
for f in "$@"; do
rm -f -- "$f"
d=$(dirname -- "$f")
[ "$d" = . ] || rmdir -p -- "$d" 2>/dev/null
done' dollar0_argument
echo 'Use "git reset --hard HEAD" to populate the working tree again.'
^ permalink raw reply
* Re: [PATCH] Typofixes outside documentation area
From: Peter Krefting @ 2010-02-04 9:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v636dr2hy.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> diff --git a/contrib/fast-import/import-directories.perl b/contrib/fast-import/import-directories.perl
> index 5782d80..3a5da4a 100755
> --- a/contrib/fast-import/import-directories.perl
> +++ b/contrib/fast-import/import-directories.perl
> @@ -344,7 +344,7 @@ sub parsekeyvaluepair
>
> Key and value strings may be enclosed in quotes, in which case
> whitespace inside the quotes is preserved. Additionally, an equal
> -sign may be included in the key by preceeding it with a backslash.
> +sign may be included in the key by preceding it with a backslash.
> For example:
>
> "key1 "=value1
ACKed, obviously.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: Making custom git-remove-tree command
From: Johannes Sixt @ 2010-02-04 9:55 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git
In-Reply-To: <87iqad2x09.fsf@mithlond.arda>
Teemu Likonen schrieb:
> I'm doing a script named git-remove-tree which removes the working tree
> known to Git. It doesn't touch untracked files; it only deletes
> directories if they are empty. The script seems to work, but because I'm
> not very good at Git plumbing and there can be some corner cases which I
> don't know about, I'd appreciate if more experienced users would have a
> look. Is the following script safe?
>
>
> #!/bin/sh
> # git-remove-tree
>
> is_wt=$(git rev-parse --is-inside-work-tree)
> if [ "$is_wt" = false ]; then
> echo "You must run this inside a working tree."
> exit 1
> elif [ -z "$is_wt" ]; then
> exit 1
> fi
>
> top=$(git rev-parse --show-toplevel)
> cd "$top" || {
> echo "Can't go to top-level directory $top"
> exit 1
> }
>
> git ls-tree --name-only -r -z HEAD | xargs -0r -- sh -c '
> for f in "$@"; do
> rm -f -- "$f"
> d=$(dirname -- "$f")
> [ "$d" = . ] || rmdir -p -- "$d" 2>/dev/null
> done' dollar0_argument
I think you should be able to reduce all of this to just
git read-tree --index-output=/tmp/empty.index -m -u \
4b825dc642cb6eb9a060e54bf8d69288fbee4904 # empty tree
rm -f /tmp/empty.index
(with the usual caveats about temporary files).
>
> echo 'Use "git reset --hard HEAD" to populate the working tree again.'
-- Hannes
^ permalink raw reply
* Re: Dealing with many many git repos in a /home directory
From: Alex Riesen @ 2010-02-04 9:57 UTC (permalink / raw)
To: demerphq; +Cc: Git
In-Reply-To: <9b18b3111002040029x1c7de0afw4a5ef883588f7a18@mail.gmail.com>
On Thu, Feb 4, 2010 at 09:29, demerphq <demerphq@gmail.com> wrote:
> Would i be correct in thinking that if i have to repos with an
> equivalent .git/objects/../..... file in them that the files are
> necessarily identical and one can be replaced by a hardlink to the
> other?
Yes, but you probably wont save as much as you'd like: think about the users
who *do* repack their repositories. The .pack files will be all different.
^ 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