* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Michael Witten @ 2007-10-17 1:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071017011148.GL13801@spearce.org>
On 16 Oct 2007, at 9:11:48 PM, Shawn O. Pearce wrote:
> Sorry, but I have to say I agree with Robin here. The tab patch
> is large, ugly, and provides relatively little value in comparsion.
>
> The first rule of git development typically is "any change is bad".
> Because anything that is already written can be assumed to already
> be tested and in use by someone. Breaking that is bad, as then
> they have a bad experience with git.
OK. I understand.
This was really preparation for a more substantial addition
that I hope to make.
I'll just have to change one line at a time with every substantial
patch!
mfwitten
^ permalink raw reply
* Re: [PATCH] gitweb: speed up project listing by limiting find depth
From: Shawn O. Pearce @ 2007-10-17 1:35 UTC (permalink / raw)
To: Luke Lu; +Cc: git, pasky
In-Reply-To: <1192583606-14893-1-git-send-email-git@vicaya.com>
Luke Lu <git@vicaya.com> wrote:
> Resubmit patch due to tab/space issue :)
Thanks, I have this locally from your prior version but already
had fixed the tab/space problem.
> +GITWEB_PROJECT_MAXDEPTH = 2007
Cute. But does what I was asking for, which was to not change
behavior for existing users. Most folks have a MAX_PATH around
1024-4096. There's no sane way they would exceed 2000 nested
directories.
--
Shawn.
^ permalink raw reply
* [PATCH] Teach "git reflog" a subcommand to delete single entries
From: Johannes Schindelin @ 2007-10-17 1:50 UTC (permalink / raw)
To: git, spearce, gitster
This commit implements the "delete" subcommand:
git reflog delete master@{2}
will delete the second reflog entry of the "master" branch.
With this, it should be easy to implement "git stash pop" everybody
seems to want these days.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-reflog.txt | 5 +++
builtin-reflog.c | 59 ++++++++++++++++++++++++++++++++++++++++++
t/t1410-reflog.sh | 26 ++++++++++++++++++
3 files changed, 90 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-reflog.txt b/Documentation/git-reflog.txt
index 5c7316c..a0c7cee 100644
--- a/Documentation/git-reflog.txt
+++ b/Documentation/git-reflog.txt
@@ -19,6 +19,8 @@ depending on the subcommand:
git reflog expire [--dry-run] [--stale-fix] [--verbose]
[--expire=<time>] [--expire-unreachable=<time>] [--all] <refs>...
+git reflog delete ref@\{specifier\}...
+
git reflog [show] [log-options]
Reflog is a mechanism to record when the tip of branches are
@@ -36,6 +38,9 @@ subcommands) will take all the normal log options, and show the log of
It is basically an alias for 'git log -g --abbrev-commit
--pretty=oneline', see gitlink:git-log[1].
+To delete single entries from the reflog, use the subcommand "delete"
+and specify the _exact_ entry (e.g. ``git reflog delete master@\{2\}'').
+
OPTIONS
-------
diff --git a/builtin-reflog.c b/builtin-reflog.c
index ce093ca..f422693 100644
--- a/builtin-reflog.c
+++ b/builtin-reflog.c
@@ -25,6 +25,7 @@ struct cmd_reflog_expire_cb {
int verbose;
unsigned long expire_total;
unsigned long expire_unreachable;
+ int recno;
};
struct expire_reflog_cb {
@@ -220,6 +221,9 @@ static int expire_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
goto prune;
}
+ if (cb->cmd->recno && --(cb->cmd->recno) == 0)
+ goto prune;
+
if (cb->newlog) {
char sign = (tz < 0) ? '-' : '+';
int zone = (tz < 0) ? (-tz) : tz;
@@ -363,6 +367,58 @@ static int cmd_reflog_expire(int argc, const char **argv, const char *prefix)
return status;
}
+static int count_reflog_ent(unsigned char *osha1, unsigned char *nsha1,
+ const char *email, unsigned long timestamp, int tz,
+ const char *message, void *cb_data)
+{
+ struct cmd_reflog_expire_cb *cb = cb_data;
+ if (!cb->expire_total || timestamp < cb->expire_total)
+ cb->recno++;
+ return 0;
+}
+
+static int cmd_reflog_delete(int argc, const char **argv, const char *prefix)
+{
+ struct cmd_reflog_expire_cb cb;
+ int i, status = 0;
+
+ if (argc < 2)
+ return error("Nothing to delete?");
+
+ memset(&cb, 0, sizeof(cb));
+
+ for (i = 1; i < argc; i++) {
+ const char *spec = strstr(argv[i], "@{");
+ unsigned char sha1[20];
+ char *ep, *ref;
+ int recno;
+
+ if (!spec) {
+ status |= error("Not a reflog: %s", ref);
+ continue;
+ }
+
+ if (!dwim_ref(argv[i], spec - argv[i], sha1, &ref)) {
+ status |= error("%s points nowhere!", argv[i]);
+ continue;
+ }
+
+ recno = strtoul(spec + 2, &ep, 10);
+ if (*ep == '}') {
+ cb.recno = -recno;
+ for_each_reflog_ent(ref, count_reflog_ent, &cb);
+ } else {
+ cb.expire_total = approxidate(spec + 2);
+ for_each_reflog_ent(ref, count_reflog_ent, &cb);
+ cb.expire_total = 0;
+ }
+
+ status |= expire_reflog(ref, sha1, 0, &cb);
+ free(ref);
+ }
+ return status;
+}
+
/*
* main "reflog"
*/
@@ -382,6 +438,9 @@ int cmd_reflog(int argc, const char **argv, const char *prefix)
if (!strcmp(argv[1], "expire"))
return cmd_reflog_expire(argc - 1, argv + 1, prefix);
+ if (!strcmp(argv[1], "delete"))
+ return cmd_reflog_delete(argc - 1, argv + 1, prefix);
+
/* Not a recognized reflog command..*/
usage(reflog_usage);
}
diff --git a/t/t1410-reflog.sh b/t/t1410-reflog.sh
index e5bbc38..12a53ed 100755
--- a/t/t1410-reflog.sh
+++ b/t/t1410-reflog.sh
@@ -175,4 +175,30 @@ test_expect_success 'recover and check' '
'
+test_expect_success 'delete' '
+ echo 1 > C &&
+ test_tick &&
+ git commit -m rat C &&
+
+ echo 2 > C &&
+ test_tick &&
+ git commit -m ox C &&
+
+ echo 3 > C &&
+ test_tick &&
+ git commit -m tiger C &&
+
+ test 5 = $(git reflog | wc -l) &&
+
+ git reflog delete master@{1} &&
+ git reflog show master > output &&
+ test 4 = $(wc -l < output) &&
+ ! grep ox < output &&
+
+ git reflog delete master@{07.04.2005.15:15:00.-0700} &&
+ git reflog show master > output &&
+ test 3 = $(wc -l < output) &&
+ ! grep dragon < output
+'
+
test_done
--
1.5.3.4.1223.ga973c
^ permalink raw reply related
* Re: revised: [PATCH] Color support added to git-add--interactive.
From: Shawn O. Pearce @ 2007-10-17 1:51 UTC (permalink / raw)
To: Dan Zwell
Cc: Jeff King, Wincent Colaiuta, Git Mailing List,
Jonathan del Strother, Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071016194709.3c1cb3a8@danzwell.com>
Dan Zwell <dzwell@gmail.com> wrote:
> Adds color to the prompts and output of git-add--interactive.
I'm probbaly going to publish this in `pu` tonight but I have some
comments that I think need to be addressed before this graduates
any further.
First off, no Signed-off-by? This is big enough that I refuse to
put it in the main tree without one. Second it would really have
helped if the email was formatted with `git format-patch`. Copying
the message headers and body over for the commit message was less
than fun. I have better things to do with my time.
> +color.interactive.<slot>::
> + Use customized color for add--interactive output. `<slot>`
You probably should talk about `git add --interactive` as that
is what the git-add documentation calls it. Many end-users don't
even know that `git add -i` is exec()'ing into another program to
accomplish its task. I fixed this up when I applied the patch.
> +Note: these are not the same colors/attributes that the
> +rest of git supports, but are specific to git-add--interactive.
This is a problem in my opinion. Why can't it match the same
names that the C code recognizes? What if we one day were to
see git-add--interactive.perl converted to C? How would we then
reconcile the color handling at that point in time?
--
Shawn.
^ permalink raw reply
* [PATCH 0/6] miscelaneous stuff
From: Nicolas Pitre @ 2007-10-17 1:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
This is a few patches I've been accumulating. Included is a rework of
the progress display so it uses much less screen lines, as well as a
couple code cleanups.
Nicolas
^ permalink raw reply
* [PATCH 1/6] more compact progress display
From: Nicolas Pitre @ 2007-10-17 1:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1192586150-13743-1-git-send-email-nico@cam.org>
Each progress can be on a single line instead of two.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 16 ++++---------
builtin-unpack-objects.c | 2 +-
index-pack.c | 4 +-
progress.c | 53 +++++++++++++++++++++------------------------
progress.h | 10 +++-----
unpack-trees.c | 4 +-
6 files changed, 39 insertions(+), 50 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 0be539e..df69abd 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -606,7 +606,7 @@ static void write_pack_file(void)
uint32_t nr_remaining = nr_result;
if (do_progress)
- start_progress(&progress_state, "Writing %u objects...", "", nr_result);
+ start_progress(&progress_state, "Writing objects", nr_result);
written_list = xmalloc(nr_objects * sizeof(struct object_entry *));
do {
@@ -1717,9 +1717,8 @@ static void prepare_pack(int window, int depth)
if (nr_deltas) {
unsigned nr_done = 0;
if (progress)
- start_progress(&progress_state,
- "Deltifying %u objects...", "",
- nr_deltas);
+ start_progress(&progress_state, "Deltifying objects",
+ nr_deltas);
qsort(delta_list, n, sizeof(*delta_list), type_size_sort);
ll_find_deltas(delta_list, n, window+1, depth, &nr_done);
if (progress)
@@ -2135,23 +2134,18 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
prepare_packed_git();
if (progress)
- start_progress(&progress_state, "Generating pack...",
- "Counting objects: ", 0);
+ start_progress(&progress_state, "Counting objects", 0);
if (!use_internal_rev_list)
read_object_list_from_stdin();
else {
rp_av[rp_ac] = NULL;
get_object_list(rp_ac, rp_av);
}
- if (progress) {
+ if (progress)
stop_progress(&progress_state);
- fprintf(stderr, "Done counting %u objects.\n", nr_objects);
- }
if (non_empty && !nr_result)
return 0;
- if (progress && (nr_objects != nr_result))
- fprintf(stderr, "Result has %u objects.\n", nr_result);
if (nr_result)
prepare_pack(window, depth);
write_pack_file();
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index a6ff62f..2317b8f 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -322,7 +322,7 @@ static void unpack_all(void)
use(sizeof(struct pack_header));
if (!quiet)
- start_progress(&progress, "Unpacking %u objects...", "", nr_objects);
+ start_progress(&progress, "Unpacking objects", nr_objects);
obj_list = xmalloc(nr_objects * sizeof(*obj_list));
for (i = 0; i < nr_objects; i++) {
unpack_one(i);
diff --git a/index-pack.c b/index-pack.c
index db58e05..c784dec 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -406,7 +406,7 @@ static void parse_pack_objects(unsigned char *sha1)
* - remember base (SHA1 or offset) for all deltas.
*/
if (verbose)
- start_progress(&progress, "Indexing %u objects...", "", nr_objects);
+ start_progress(&progress, "Indexing objects", nr_objects);
for (i = 0; i < nr_objects; i++) {
struct object_entry *obj = &objects[i];
data = unpack_raw_entry(obj, &delta->base);
@@ -455,7 +455,7 @@ static void parse_pack_objects(unsigned char *sha1)
* for some more deltas.
*/
if (verbose)
- start_progress(&progress, "Resolving %u deltas...", "", nr_deltas);
+ start_progress(&progress, "Resolving deltas", nr_deltas);
for (i = 0; i < nr_objects; i++) {
struct object_entry *obj = &objects[i];
union delta_base base;
diff --git a/progress.c b/progress.c
index 4344f4e..7629e05 100644
--- a/progress.c
+++ b/progress.c
@@ -35,10 +35,11 @@ static void clear_progress_signal(void)
progress_update = 0;
}
-int display_progress(struct progress *progress, unsigned n)
+static int display(struct progress *progress, unsigned n, int done)
{
+ char *eol;
+
if (progress->delay) {
- char buf[80];
if (!progress_update || --progress->delay)
return 0;
if (progress->total) {
@@ -51,60 +52,56 @@ int display_progress(struct progress *progress, unsigned n)
return 0;
}
}
- if (snprintf(buf, sizeof(buf),
- progress->delayed_title, progress->total))
- fprintf(stderr, "%s\n", buf);
}
+
+ progress->last_value = n;
+ eol = done ? ", done. \n" : " \r";
if (progress->total) {
unsigned percent = n * 100 / progress->total;
if (percent != progress->last_percent || progress_update) {
progress->last_percent = percent;
- fprintf(stderr, "%s%4u%% (%u/%u) done\r",
- progress->prefix, percent, n, progress->total);
+ fprintf(stderr, "%s: %3u%% (%u/%u)%s", progress->title,
+ percent, n, progress->total, eol);
progress_update = 0;
- progress->need_lf = 1;
return 1;
}
} else if (progress_update) {
- fprintf(stderr, "%s%u\r", progress->prefix, n);
+ fprintf(stderr, "%s: %u%s", progress->title, n, eol);
progress_update = 0;
- progress->need_lf = 1;
return 1;
}
+
return 0;
}
-void start_progress(struct progress *progress, const char *title,
- const char *prefix, unsigned total)
+int display_progress(struct progress *progress, unsigned n)
{
- char buf[80];
- progress->prefix = prefix;
- progress->total = total;
- progress->last_percent = -1;
- progress->delay = 0;
- progress->need_lf = 0;
- if (snprintf(buf, sizeof(buf), title, total))
- fprintf(stderr, "%s\n", buf);
- set_progress_signal();
+ return display(progress, n, 0);
}
void start_progress_delay(struct progress *progress, const char *title,
- const char *prefix, unsigned total,
- unsigned percent_treshold, unsigned delay)
+ unsigned total, unsigned percent_treshold, unsigned delay)
{
- progress->prefix = prefix;
+ progress->title = title;
progress->total = total;
+ progress->last_value = -1;
progress->last_percent = -1;
progress->delayed_percent_treshold = percent_treshold;
- progress->delayed_title = title;
progress->delay = delay;
- progress->need_lf = 0;
set_progress_signal();
}
+void start_progress(struct progress *progress, const char *title, unsigned total)
+{
+ start_progress_delay(progress, title, total, 0, 0);
+}
+
void stop_progress(struct progress *progress)
{
+ if (progress->last_value != -1) {
+ /* Force the last update */
+ progress_update = 1;
+ display(progress, progress->last_value, 1);
+ }
clear_progress_signal();
- if (progress->need_lf)
- fputc('\n', stderr);
}
diff --git a/progress.h b/progress.h
index a7c17ca..07b56bd 100644
--- a/progress.h
+++ b/progress.h
@@ -2,21 +2,19 @@
#define PROGRESS_H
struct progress {
- const char *prefix;
+ const char *title;
+ int last_value;
unsigned total;
unsigned last_percent;
unsigned delay;
unsigned delayed_percent_treshold;
- const char *delayed_title;
- int need_lf;
};
int display_progress(struct progress *progress, unsigned n);
void start_progress(struct progress *progress, const char *title,
- const char *prefix, unsigned total);
+ unsigned total);
void start_progress_delay(struct progress *progress, const char *title,
- const char *prefix, unsigned total,
- unsigned percent_treshold, unsigned delay);
+ unsigned total, unsigned percent_treshold, unsigned delay);
void stop_progress(struct progress *progress);
#endif
diff --git a/unpack-trees.c b/unpack-trees.c
index ccfeb6e..e083898 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -307,8 +307,8 @@ static void check_updates(struct cache_entry **src, int nr,
total++;
}
- start_progress_delay(&progress, "Checking %u files out...",
- "", total, 50, 2);
+ start_progress_delay(&progress, "Checking files out",
+ total, 50, 2);
cnt = 0;
}
--
1.5.3.4.1212.gdb015
^ permalink raw reply related
* [PATCH 2/6] cope with multiple line breaks within sideband progress messages
From: Nicolas Pitre @ 2007-10-17 1:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1192586150-13743-2-git-send-email-nico@cam.org>
A single sideband packet may sometimes contain multiple lines of progress
messages, but we prepend "remote: " only to the whole buffer which creates
a messed up display in that case. Make sure that the "remote: " prefix
is applied to every remote lines.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
sideband.c | 19 +++++++++++++++++--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/sideband.c b/sideband.c
index 277fa3c..ab8a1e9 100644
--- a/sideband.c
+++ b/sideband.c
@@ -17,7 +17,7 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
strcpy(buf, "remote:");
while (1) {
int band, len;
- len = packet_read_line(in_stream, buf+7, LARGE_PACKET_MAX);
+ len = packet_read_line(in_stream, buf+7, LARGE_PACKET_MAX);
if (len == 0)
break;
if (len < 1) {
@@ -35,7 +35,22 @@ int recv_sideband(const char *me, int in_stream, int out, int err)
return SIDEBAND_REMOTE_ERROR;
case 2:
buf[7] = ' ';
- safe_write(err, buf, 8+len);
+ len += 8;
+ while (1) {
+ int brk = 8;
+ while (brk < len) {
+ brk++;
+ if (buf[brk-1] == '\n' ||
+ buf[brk-1] == '\r')
+ break;
+ }
+ safe_write(err, buf, brk);
+ if (brk < len) {
+ memmove(buf + 8, buf + brk, len - brk);
+ len = len - brk + 8;
+ } else
+ break;
+ }
continue;
case 1:
safe_write(out, buf+8, len);
--
1.5.3.4.1212.gdb015
^ permalink raw reply related
* [PATCH 4/6] pack-objects.c: fix some global variable abuse and memory leaks
From: Nicolas Pitre @ 2007-10-17 1:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1192586150-13743-4-git-send-email-nico@cam.org>
To keep things well layered, sha1close() now returns the file descriptor
when it doesn't close the file.
An ugly cast was added to the return of write_idx_file() to avoid a
warning. A proper fix will come separately.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 29 +++++++++++++++--------------
csum-file.c | 23 ++++++++++++++---------
2 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index d729cb7..933c252 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -65,8 +65,6 @@ static int no_reuse_delta, no_reuse_object, keep_unreachable;
static int local;
static int incremental;
static int allow_ofs_delta;
-static const char *pack_tmp_name, *idx_tmp_name;
-static char tmpname[PATH_MAX];
static const char *base_name;
static int progress = 1;
static int window = 10;
@@ -587,12 +585,6 @@ static off_t write_one(struct sha1file *f,
return offset + size;
}
-static int open_object_dir_tmp(const char *path)
-{
- snprintf(tmpname, sizeof(tmpname), "%s/%s", get_object_directory(), path);
- return xmkstemp(tmpname);
-}
-
/* forward declaration for write_pack_file */
static int adjust_perm(const char *path, mode_t mode);
@@ -611,11 +603,16 @@ static void write_pack_file(void)
do {
unsigned char sha1[20];
+ char *pack_tmp_name = NULL;
if (pack_to_stdout) {
f = sha1fd(1, "<stdout>");
} else {
- int fd = open_object_dir_tmp("tmp_pack_XXXXXX");
+ char tmpname[PATH_MAX];
+ int fd;
+ snprintf(tmpname, sizeof(tmpname),
+ "%s/tmp_pack_XXXXXX", get_object_directory());
+ fd = xmkstemp(tmpname);
pack_tmp_name = xstrdup(tmpname);
f = sha1fd(fd, pack_tmp_name);
}
@@ -643,19 +640,21 @@ static void write_pack_file(void)
if (pack_to_stdout || nr_written == nr_remaining) {
sha1close(f, sha1, 1);
} else {
- sha1close(f, sha1, 0);
- fixup_pack_header_footer(f->fd, sha1, pack_tmp_name, nr_written);
- close(f->fd);
+ int fd = sha1close(f, NULL, 0);
+ fixup_pack_header_footer(fd, sha1, pack_tmp_name, nr_written);
+ close(fd);
}
if (!pack_to_stdout) {
mode_t mode = umask(0);
+ char *idx_tmp_name, tmpname[PATH_MAX];
umask(mode);
mode = 0444 & ~mode;
- idx_tmp_name = write_idx_file(NULL,
- (struct pack_idx_entry **) written_list, nr_written, sha1);
+ idx_tmp_name = (char *) write_idx_file(NULL,
+ (struct pack_idx_entry **) written_list,
+ nr_written, sha1);
snprintf(tmpname, sizeof(tmpname), "%s-%s.pack",
base_name, sha1_to_hex(sha1));
if (adjust_perm(pack_tmp_name, mode))
@@ -672,6 +671,8 @@ static void write_pack_file(void)
if (rename(idx_tmp_name, tmpname))
die("unable to rename temporary index file: %s",
strerror(errno));
+ free(idx_tmp_name);
+ free(pack_tmp_name);
puts(sha1_to_hex(sha1));
}
diff --git a/csum-file.c b/csum-file.c
index 9ab9971..9929991 100644
--- a/csum-file.c
+++ b/csum-file.c
@@ -31,22 +31,27 @@ static void sha1flush(struct sha1file *f, unsigned int count)
int sha1close(struct sha1file *f, unsigned char *result, int final)
{
+ int fd;
unsigned offset = f->offset;
if (offset) {
SHA1_Update(&f->ctx, f->buffer, offset);
sha1flush(f, offset);
f->offset = 0;
}
- if (!final)
- return 0; /* only want to flush (no checksum write, no close) */
- SHA1_Final(f->buffer, &f->ctx);
- if (result)
- hashcpy(result, f->buffer);
- sha1flush(f, 20);
- if (close(f->fd))
- die("%s: sha1 file error on close (%s)", f->name, strerror(errno));
+ if (final) {
+ /* write checksum and close fd */
+ SHA1_Final(f->buffer, &f->ctx);
+ if (result)
+ hashcpy(result, f->buffer);
+ sha1flush(f, 20);
+ if (close(f->fd))
+ die("%s: sha1 file error on close (%s)",
+ f->name, strerror(errno));
+ fd = 0;
+ } else
+ fd = f->fd;
free(f);
- return 0;
+ return fd;
}
int sha1write(struct sha1file *f, void *buf, unsigned int count)
--
1.5.3.4.1212.gdb015
^ permalink raw reply related
* [PATCH 3/6] pack-objects: no delta possible with only one object in the list
From: Nicolas Pitre @ 2007-10-17 1:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1192586150-13743-3-git-send-email-nico@cam.org>
... so don't even try in that case, and save another useless line of
progress display.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index df69abd..d729cb7 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -1714,7 +1714,7 @@ static void prepare_pack(int window, int depth)
delta_list[n++] = entry;
}
- if (nr_deltas) {
+ if (nr_deltas && n > 1) {
unsigned nr_done = 0;
if (progress)
start_progress(&progress_state, "Deltifying objects",
--
1.5.3.4.1212.gdb015
^ permalink raw reply related
* [PATCH 5/6] fix const issues with some functions
From: Nicolas Pitre @ 2007-10-17 1:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1192586150-13743-5-git-send-email-nico@cam.org>
Two functions, namely write_idx_file() and open_pack_file(), currently
return a const pointer. However that pointer is either a copy of the
first argument, or set to a malloc'd buffer when that first argument
is null. In the later case it is wrong to qualify that pointer as const
since ownership of the buffer is transferred to the caller to dispose of,
and obviously the free() function is not meant to be passed const
pointers.
Making the return pointer not const causes a warning when the first
argument is returned since that argument is also marked const.
The correct thing to do is therefore to remove the const qualifiers,
avoiding the need for ugly casts only to silence some warnings.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 2 +-
index-pack.c | 8 ++++----
pack-write.c | 3 ++-
pack.h | 2 +-
4 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 933c252..15d3750 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -652,7 +652,7 @@ static void write_pack_file(void)
umask(mode);
mode = 0444 & ~mode;
- idx_tmp_name = (char *) write_idx_file(NULL,
+ idx_tmp_name = write_idx_file(NULL,
(struct pack_idx_entry **) written_list,
nr_written, sha1);
snprintf(tmpname, sizeof(tmpname), "%s-%s.pack",
diff --git a/index-pack.c b/index-pack.c
index c784dec..60173d5 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -106,7 +106,7 @@ static void use(int bytes)
consumed_bytes += bytes;
}
-static const char *open_pack_file(const char *pack_name)
+static char *open_pack_file(char *pack_name)
{
if (from_stdin) {
input_fd = 0;
@@ -686,15 +686,15 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
int main(int argc, char **argv)
{
int i, fix_thin_pack = 0;
- const char *curr_pack, *pack_name = NULL;
- const char *curr_index, *index_name = NULL;
+ char *curr_pack, *pack_name = NULL;
+ char *curr_index, *index_name = NULL;
const char *keep_name = NULL, *keep_msg = NULL;
char *index_name_buf = NULL, *keep_name_buf = NULL;
struct pack_idx_entry **idx_objects;
unsigned char sha1[20];
for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
+ char *arg = argv[i];
if (*arg == '-') {
if (!strcmp(arg, "--stdin")) {
diff --git a/pack-write.c b/pack-write.c
index 979bdff..665e2b2 100644
--- a/pack-write.c
+++ b/pack-write.c
@@ -17,7 +17,8 @@ static int sha1_compare(const void *_a, const void *_b)
* the SHA1 hash of sorted object names. The objects array passed in
* will be sorted by SHA1 on exit.
*/
-const char *write_idx_file(const char *index_name, struct pack_idx_entry **objects, int nr_objects, unsigned char *sha1)
+char *write_idx_file(char *index_name, struct pack_idx_entry **objects,
+ int nr_objects, unsigned char *sha1)
{
struct sha1file *f;
struct pack_idx_entry **sorted_by_sha, **list, **last;
diff --git a/pack.h b/pack.h
index b57ba2d..b31b376 100644
--- a/pack.h
+++ b/pack.h
@@ -55,7 +55,7 @@ struct pack_idx_entry {
off_t offset;
};
-extern const char *write_idx_file(const char *index_name, struct pack_idx_entry **objects, int nr_objects, unsigned char *sha1);
+extern char *write_idx_file(char *index_name, struct pack_idx_entry **objects, int nr_objects, unsigned char *sha1);
extern int verify_pack(struct packed_git *, int);
extern void fixup_pack_header_footer(int, unsigned char *, const char *, uint32_t);
--
1.5.3.4.1212.gdb015
^ permalink raw reply related
* [PATCH 6/6] fix for more minor memory leaks
From: Nicolas Pitre @ 2007-10-17 1:55 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1192586150-13743-6-git-send-email-nico@cam.org>
Now that some pointers have lost their const attribute, we can free their
associated memory when done with them. This is more a correctness issue
about the rule for freeing those pointers which isn't completely trivial
more than the leak itself which didn't matter as the program is
exiting anyway.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
index-pack.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index 60173d5..2f149a4 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -815,6 +815,10 @@ int main(int argc, char **argv)
free(objects);
free(index_name_buf);
free(keep_name_buf);
+ if (pack_name == NULL)
+ free(curr_pack);
+ if (index_name == NULL)
+ free(curr_index);
return 0;
}
--
1.5.3.4.1212.gdb015
^ permalink raw reply related
* Re: [PATCH 1/6] more compact progress display
From: Shawn O. Pearce @ 2007-10-17 2:11 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <1192586150-13743-2-git-send-email-nico@cam.org>
Nicolas Pitre <nico@cam.org> wrote:
> Each progress can be on a single line instead of two.
Nice. Of course that screws with git-gui and now I have to
match two regexs and not one. But whatever.
> +++ b/progress.c
> @@ -35,10 +35,11 @@ static void clear_progress_signal(void)
> progress_update = 0;
> }
>
> -int display_progress(struct progress *progress, unsigned n)
> +static int display(struct progress *progress, unsigned n, int done)
> {
> + char *eol;
> +
> if (progress->delay) {
> - char buf[80];
> if (!progress_update || --progress->delay)
> return 0;
> if (progress->total) {
> @@ -51,60 +52,56 @@ int display_progress(struct progress *progress, unsigned n)
> return 0;
> }
> }
> - if (snprintf(buf, sizeof(buf),
> - progress->delayed_title, progress->total))
> - fprintf(stderr, "%s\n", buf);
> }
> +
> + progress->last_value = n;
Hmm. n is unsigned and last_value is signed. Uh? I know you are
using the special value -1 to mean we've never output anything for
this progress meter but mixing signed and unsigned always gives me
the willies.
--
Shawn.
^ permalink raw reply
* Deltifying? (was [PATCH 3/6] pack-objects: no delta possible...)
From: Shawn O. Pearce @ 2007-10-17 2:15 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <1192586150-13743-4-git-send-email-nico@cam.org>
Nicolas Pitre <nico@cam.org> wrote:
> start_progress(&progress_state, "Deltifying objects",
Totally unrelated to this patch but yesterday a coworker called the
Grammar Police on me because Git said "Deltifying objects" in their
console window during a fetch or push operation. I told them it was
perfectly valid, they disagreed. I got free coffee out of the deal.
But still, it bothers some users that we use perhaps less than
commonly accepted English in an important tool's output. Seeing it
in your context just reminded me of that discussion yesterday.
--
Shawn.
^ permalink raw reply
* [PATCH 1/2] fix filter-branch documentation
From: Johannes Schindelin @ 2007-10-17 2:22 UTC (permalink / raw)
To: Bill Lear; +Cc: git, spearce, gitster
In-Reply-To: <18197.24051.863751.436705@lisa.zopyra.com>
The man page for filter-branch still talked about writing the result
to the branch "newbranch". This is hopefully the last place where the
old behaviour was described.
Noticed by Bill Lear.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Documentation/git-filter-branch.txt | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index c878ed3..ba9b4fb 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -180,8 +180,7 @@ A significantly faster version:
git filter-branch --index-filter 'git update-index --remove filename' HEAD
--------------------------------------------------------------------------
-Now, you will get the rewritten history saved in the branch 'newbranch'
-(your current branch is left untouched).
+Now, you will get the rewritten history saved in HEAD.
To set a commit (which typically is at the tip of another
history) to be the parent of the current initial commit, in
--
1.5.3.4.1223.ga973c
^ permalink raw reply related
* [PATCH 2/2] filter-branch: update current branch when rewritten
From: Johannes Schindelin @ 2007-10-17 2:23 UTC (permalink / raw)
To: Bill Lear; +Cc: git, spearce, gitster
In-Reply-To: <Pine.LNX.4.64.0710170322000.25221@racer.site>
Earlier, "git filter-branch --<options> HEAD" would not update the
working tree after rewriting the branch. This commit fixes it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Bill, I hope this clarifies some things for you, too...
git-filter-branch.sh | 15 +++++++++++++++
t/t7003-filter-branch.sh | 4 +++-
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a12f6c2..ffcc408 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -94,6 +94,10 @@ USAGE="[--env-filter <command>] [--tree-filter <command>] \
. git-sh-setup
+git diff-files --quiet &&
+ git diff-index --cached --quiet HEAD ||
+ die "Cannot rewrite branch(es) with a dirty working directory."
+
tempdir=.git-rewrite
filter_env=
filter_tree=
@@ -196,6 +200,9 @@ do
esac
done < "$tempdir"/backup-refs
+ORIG_GIT_DIR="$GIT_DIR"
+ORIG_GIT_WORK_TREE="$GIT_WORK_TREE"
+ORIG_GIT_INDEX_FILE="$GIT_INDEX_FILE"
export GIT_DIR GIT_WORK_TREE=.
# These refs should be updated if their heads were rewritten
@@ -413,4 +420,12 @@ echo
test $count -gt 0 && echo "These refs were rewritten:"
git show-ref | grep ^"$orig_namespace"
+unset GIT_DIR GIT_WORK_TREE GIT_INDEX_FILE
+test -z "$ORIG_GIT_DIR" || GIT_DIR="$ORIG_GIT_DIR" && export GIT_DIR
+test -z "$ORIG_GIT_WORK_TREE" || GIT_WORK_TREE="$ORIG_GIT_WORK_TREE" &&
+ export GIT_WORK_TREE
+test -z "$ORIG_GIT_INDEX_FILE" || GIT_INDEX_FILE="$ORIG_GIT_INDEX_FILE" &&
+ export GIT_INDEX_FILE
+git read-tree -u -m HEAD
+
exit $ret
diff --git a/t/t7003-filter-branch.sh b/t/t7003-filter-branch.sh
index e935b20..2089351 100755
--- a/t/t7003-filter-branch.sh
+++ b/t/t7003-filter-branch.sh
@@ -41,7 +41,9 @@ test_expect_success 'rewrite, renaming a specific file' '
'
test_expect_success 'test that the file was renamed' '
- test d = $(git show HEAD:doh)
+ test d = $(git show HEAD:doh) &&
+ test -f doh &&
+ test d = $(cat doh)
'
git tag oldD HEAD~4
--
1.5.3.4.1223.ga973c
^ permalink raw reply related
* Re: [PATCH 1/6] more compact progress display
From: Nicolas Pitre @ 2007-10-17 2:24 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071017021137.GO13801@spearce.org>
On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
> Hmm. n is unsigned and last_value is signed. Uh? I know you are
> using the special value -1 to mean we've never output anything for
> this progress meter but mixing signed and unsigned always gives me
> the willies.
Really? ;-)
Nicolas
^ permalink raw reply
* Re: [PATCH 2/3] git-cvsexportcommit.perl tmpdir removed
From: Shawn O. Pearce @ 2007-10-17 2:25 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <1192522094-4988-2-git-send-email-mfwitten@mit.edu>
Michael Witten <mfwitten@mit.edu> wrote:
> Signed-off-by: Michael Witten <mfwitten@mit.edu>
> ---
> This is perhaps a duplicate of another patch sent in,
> but it applies to the tabified version.
Yea, I don't know if you know this but I do already have this in my
master branch. Same change but it came from Johannes Schindelin.
I just happened to come across his patch first in my inbox last
night when I was processing through what I could.
--
Shawn.
^ permalink raw reply
* Re: Deltifying? (was [PATCH 3/6] pack-objects: no delta possible...)
From: Nicolas Pitre @ 2007-10-17 2:28 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071017021555.GP13801@spearce.org>
On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
> Nicolas Pitre <nico@cam.org> wrote:
> > start_progress(&progress_state, "Deltifying objects",
>
> Totally unrelated to this patch but yesterday a coworker called the
> Grammar Police on me because Git said "Deltifying objects" in their
> console window during a fetch or push operation. I told them it was
> perfectly valid, they disagreed. I got free coffee out of the deal.
Whatever is proper English I don't mind, as long as it is short, like a
single word to describe the action + "objects".
> But still, it bothers some users that we use perhaps less than
> commonly accepted English in an important tool's output. Seeing it
> in your context just reminded me of that discussion yesterday.
With Git's growing user base, this is becoming more and more common
though. ;-)
Nicolas
^ permalink raw reply
* Re: [PATCH] gitweb: speed up project listing by limiting find depth
From: Shawn O. Pearce @ 2007-10-17 2:40 UTC (permalink / raw)
To: Luke Lu; +Cc: git, pasky
In-Reply-To: <1192583606-14893-1-git-send-email-git@vicaya.com>
Luke Lu <git@vicaya.com> wrote:
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 3064298..d62357f 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -1509,16 +1513,23 @@ sub git_get_projects_list {
...
> + # don't traverse too deep (Find is super slow on os x)
> + if (tr!/!! - $pfxdepth > $project_maxdepth) {
> + $File::Find::prune = 1;
> + return;
> + }
>
> my $subdir = substr($File::Find::name, $pfxlen + 1);
Your patch appears to be causing some errors in the test suite
in t/t9500-gitweb-standalone-no-errors.sh. Perl is whining about
$subdir not getting initialized above due to the substr being off
the string. I've got too many other topics tonight to figure out
why yours is failing, can you please run the test and resubmit when
you've resolved the error?
--
Shawn.
^ permalink raw reply
* RE: Is there any plan to support partial checkout or submouduleimprovement?
From: franky @ 2007-10-17 2:54 UTC (permalink / raw)
To: 'Jan Hudec'; +Cc: git
In-Reply-To: <20071016213359.GJ26127@efreet.light.src>
franky
> -----Original Message-----
> From: Jan Hudec [mailto:bulb@ucw.cz]
> Sent: Wednesday, October 17, 2007 5:34 AM
> To: franky
> Cc: 'Johannes Schindelin'; 'Lars Hjemli'; git@vger.kernel.org
> Subject: Re: Is there any plan to support partial checkout or
> submouduleimprovement?
>
> On Tue, Oct 16, 2007 at 19:53:08 +0800, franky wrote:
> > > You are talking as if your partial checkout was a project in its own
> > > right. Then make it so. Do not use a partial checkout, but make that
a
> > > submodule.
> >
> > As I said in the first email, the submodule way suffers from the
multiple
> > commit problem: src and bin as two submodules of project, three commits
(for
> > the 3 dirs separately) are needed when src directory changes and
compiled
> > binaries being put in bin directory. It's annoying to have to give 3
commit
> > logs.
>
> Thinking about it, it's only two commits -- src can be a submodule, but
bin
> a normal directory (you can choose not to check out subprojects during
> repository checkout).
> Now I would actually say that commiting bin independently is better.
> It allows you to commit sources more often (eg. if you are doing series of
> small fixes) and more flexibility for branching (you don't want to merge
> binaries).
>
Thanks for the advice. It's a good idea.
> --
> Jan 'Bulb' Hudec
<bulb@ucw.cz>
^ permalink raw reply
* Re: On Tabs and Spaces
From: Michael Witten @ 2007-10-17 3:08 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <alpine.LFD.0.999.0710161722320.26902@woody.linux-foundation.org>
On 16 Oct 2007, at 8:45:51 PM, Linus Torvalds wrote:
> And is it really so unreasonable to just say "8-character tabs are the
> gold standard"?
It's unreasonable not to list that anywhere.
mfwitten
^ permalink raw reply
* Re: What's cooking in git/spearce.git (topics)
From: Shawn O. Pearce @ 2007-10-17 3:20 UTC (permalink / raw)
To: Theodore Tso; +Cc: Johannes Schindelin, git
In-Reply-To: <20071016195744.GB32132@closure.lan>
Theodore Tso <tytso@mit.edu> wrote:
> I've recently started trying to use some of the scripts in "todo" to
> send similar "What's cooking" messages, and started wondering if they
> were what Junio actually used in production to send his notes. For
> example, the scripts don't work particularly well if the refs have
> been packed. So I had to make changes such as these so they would
> work for me.
I think Junio just makes sure he doesn't pack his refs. :-)
> diff --git a/PU b/PU
> index 4b4be2b..4643a42 100755
> --- a/PU
> +++ b/PU
> @@ -26,8 +26,8 @@ case "$#" in
> 0)
> # interactive ;-)
> shift
> - HH=`cd .git/refs/heads && find -type f |
> - sed -e 's/^\.\///' \
> + HH=`git-show-ref --heads | awk '{print $2}' |\
Perhaps `git for-each-ref --format='%(refname)' refs/heads` is the
better change here as then you can avoid the pipe into awk. We still
need the sed to strip the refs/heads/ off the results though.
> + sed -e 's;refs/heads/;;' \
> -e '/^naster$/d' -e '/^master$/d' -e '/^maint$/d' -e '/^pu$/d'`
> while test "$HH"
> do
I'm actually applying it with the show-ref variant and will wind up
pushing it into my tree later tonight. Because I do pack my refs.
--
Shawn.
^ permalink raw reply
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 3:29 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <B01BBB60-6231-4AF6-9A64-10374464E442@mit.edu>
On Tue, 16 Oct 2007, Michael Witten wrote:
>
> On 16 Oct 2007, at 8:45:51 PM, Linus Torvalds wrote:
>
> > And is it really so unreasonable to just say "8-character tabs are the
> > gold standard"?
>
> It's unreasonable not to list that anywhere.
Heh.
I was sure we had a "CodingStyle", but it turns out that no, we don't, and
yes, the 8-tab assumption is implicit in (a) the kernel rules (which git
started out following for obvious reasons, and which *does* have
documentation making this very explicit indeed) and (b) those few places
where you can actually see it in the result.
So maybe it should be made explicit. You can see the effect right now by
doing
git grep -1 ' ' *.c
(again, that regex is a "tab+space", although it's not obvious) and then
looking for places where we line up things in ways that simply wouldn't
have worked if it wasn't a 8-wide tab, ie things like
...
check_all_attr = xrealloc(check_all_attr,
sizeof(*check_all_attr) * attr_nr);
..
read_tree_recursive(args->tree, args->base, plen, 0,
args->pathspec, write_zip_entry);
..
where the arguments wouldn't line up for anything but 8-char-wide tabs.
(But the code is certainly *readable* with other tab sizes, so it's not
like this makes it impossible to work if somebody has a 4-space tab, it
just means that such people can get odd effects - but they may not even
realize that others see things line up!)
Linus
^ permalink raw reply
* Re: On Tabs and Spaces
From: David @ 2007-10-17 3:41 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20071016230952.GA18099@machine.or.cz>
On 10/16/07, Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Oct 16, 2007 at 07:40:26PM +0200, Sam Ravnborg wrote:
> > Tabs should be used for indent and not general alignment.
> >
> > Consider:
> > <tab>if (some long condition that
> > <tab>....&& spans two lines) {
> > <tab><tab>my_private_printf("bla bla bla"
> > <tab><tab>.................."more bla bla\n");
> > <tab><tab>}
> >
> > This will look good and align "more bla bla\n" as
> > intended no matter your tab setting.
> > But replacing the 8 spaces with a tab will
> > cause it to look bad.
>
> I'd so much love to have this and sometimes do this even manually, but
> does anyone have an idea how to make vim do this for me? I never got
> around to investigate this in depth or possibly make a patch...
>
> --
> Petr "Pasky" Baudis
> Early to rise and early to bed makes a male healthy and wealthy and dead.
> -- James Thurber
Hello
I use both vim and emacs so I must be weird.
Anyways, here's some useful vim settings that I've come across:
set tabstop=8
set softtabstop=8
set shiftwidth=8
set noexpandtab
set list
set listchars=<tab>:.\
The last two are extremely useful, especially if you're hacking on
python. That's
listchars=(less-than)tab(greater-than)(colon)(dot)(backslash)(space)
(don't forget the space!).
That makes vim display tabs with a "." indicator, so you have a very
clear view of when tabs are in use. This has helped me countless
times.
You can use any character in there instead of dot. I actually use an
extended ascii character since it looks nicer but I didn't want to
risk email mangling it.
--
David
^ permalink raw reply
* [PATCH] gitweb: speed up project listing on large work trees by limiting find depth
From: Luke Lu @ 2007-10-17 3:45 UTC (permalink / raw)
To: git; +Cc: pasky, spearce, Luke Lu
Resubmitting patch after passing gitweb regression tests.
Signed-off-by: Luke Lu <git@vicaya.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 10 ++++++++++
t/t9500-gitweb-standalone-no-errors.sh | 1 +
3 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 8db4dbe..3e9938e 100644
--- a/Makefile
+++ b/Makefile
@@ -165,6 +165,7 @@ GITWEB_CONFIG = gitweb_config.perl
GITWEB_HOME_LINK_STR = projects
GITWEB_SITENAME =
GITWEB_PROJECTROOT = /pub/git
+GITWEB_PROJECT_MAXDEPTH = 2007
GITWEB_EXPORT_OK =
GITWEB_STRICT_EXPORT =
GITWEB_BASE_URL =
@@ -831,6 +832,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_HOME_LINK_STR++|$(GITWEB_HOME_LINK_STR)|g' \
-e 's|++GITWEB_SITENAME++|$(GITWEB_SITENAME)|g' \
-e 's|++GITWEB_PROJECTROOT++|$(GITWEB_PROJECTROOT)|g' \
+ -e 's|"++GITWEB_PROJECT_MAXDEPTH++"|$(GITWEB_PROJECT_MAXDEPTH)|g' \
-e 's|++GITWEB_EXPORT_OK++|$(GITWEB_EXPORT_OK)|g' \
-e 's|++GITWEB_STRICT_EXPORT++|$(GITWEB_STRICT_EXPORT)|g' \
-e 's|++GITWEB_BASE_URL++|$(GITWEB_BASE_URL)|g' \
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3064298..48e21da 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -35,6 +35,10 @@ our $GIT = "++GIT_BINDIR++/git";
#our $projectroot = "/pub/scm";
our $projectroot = "++GITWEB_PROJECTROOT++";
+# fs traversing limit for getting project list
+# the number is relative to the projectroot
+our $project_maxdepth = "++GITWEB_PROJECT_MAXDEPTH++";
+
# target of the home link on top of all pages
our $home_link = $my_uri || "/";
@@ -1509,6 +1513,7 @@ sub git_get_projects_list {
# remove the trailing "/"
$dir =~ s!/+$!!;
my $pfxlen = length("$dir");
+ my $pfxdepth = ($dir =~ tr!/!!);
File::Find::find({
follow_fast => 1, # follow symbolic links
@@ -1519,6 +1524,11 @@ sub git_get_projects_list {
return if (m!^[/.]$!);
# only directories can be git repositories
return unless (-d $_);
+ # don't traverse too deep (Find is super slow on os x)
+ if (($File::Find::name =~ tr!/!!) - $pfxdepth > $project_maxdepth) {
+ $File::Find::prune = 1;
+ return;
+ }
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 642b836..f7bad5b 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -18,6 +18,7 @@ gitweb_init () {
our \$version = "current";
our \$GIT = "git";
our \$projectroot = "$(pwd)";
+our \$project_maxdepth = 8;
our \$home_link_str = "projects";
our \$site_name = "[localhost]";
our \$site_header = "";
--
1.5.3.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox