* [PATCH 0/5] more progress display stuff
From: Nicolas Pitre @ 2007-10-30 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is the result of some changes and cleanup I did to nicely support
progress with throughput display, and avoid those random crashes the
previous patches introduced. All tests are OK now after every patch.
This is meant to replace my latest 2 patches currently in pu.
Nicolas
^ permalink raw reply
* [PATCH 1/5] prune-packed: don't call display_progress() for every file
From: Nicolas Pitre @ 2007-10-30 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1193770655-20492-1-git-send-email-nico@cam.org>
The progress count is per fanout directory, so it is useless to call
it for every file as the count doesn't change that often.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-prune-packed.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/builtin-prune-packed.c b/builtin-prune-packed.c
index 015c8bb..907e368 100644
--- a/builtin-prune-packed.c
+++ b/builtin-prune-packed.c
@@ -15,6 +15,9 @@ static void prune_dir(int i, DIR *dir, char *pathname, int len, int opts)
struct dirent *de;
char hex[40];
+ if (opts == VERBOSE)
+ display_progress(&progress, i + 1);
+
sprintf(hex, "%02x", i);
while ((de = readdir(dir)) != NULL) {
unsigned char sha1[20];
@@ -26,8 +29,6 @@ static void prune_dir(int i, DIR *dir, char *pathname, int len, int opts)
if (!has_sha1_pack(sha1, NULL))
continue;
memcpy(pathname + len, de->d_name, 38);
- if (opts == VERBOSE)
- display_progress(&progress, i + 1);
if (opts & DRY_RUN)
printf("rm -f %s\n", pathname);
else if (unlink(pathname) < 0)
--
1.5.3.4.1463.gf79ad2
^ permalink raw reply related
* [PATCH 2/5] make struct progress an opaque type
From: Nicolas Pitre @ 2007-10-30 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1193770655-20492-2-git-send-email-nico@cam.org>
This allows for better management of progress "object" existence,
as well as making the progress display implementation more independent
from its callers.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 16 ++++++++--------
builtin-prune-packed.c | 7 +++----
builtin-unpack-objects.c | 6 +++---
index-pack.c | 12 ++++++------
progress.c | 33 +++++++++++++++++++++++++++------
progress.h | 18 +++++-------------
unpack-trees.c | 10 +++++-----
7 files changed, 57 insertions(+), 45 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 21ba977..3ca5cc7 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -73,7 +73,7 @@ static int depth = 50;
static int delta_search_threads = 1;
static int pack_to_stdout;
static int num_preferred_base;
-static struct progress progress_state;
+static struct progress *progress_state;
static int pack_compression_level = Z_DEFAULT_COMPRESSION;
static int pack_compression_seen;
@@ -598,7 +598,7 @@ static void write_pack_file(void)
uint32_t nr_remaining = nr_result;
if (do_progress)
- start_progress(&progress_state, "Writing objects", nr_result);
+ progress_state = start_progress("Writing objects", nr_result);
written_list = xmalloc(nr_objects * sizeof(struct object_entry *));
do {
@@ -630,7 +630,7 @@ static void write_pack_file(void)
break;
offset = offset_one;
if (do_progress)
- display_progress(&progress_state, written);
+ display_progress(progress_state, written);
}
/*
@@ -854,7 +854,7 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
object_ix[-1 - ix] = nr_objects;
if (progress)
- display_progress(&progress_state, nr_objects);
+ display_progress(progress_state, nr_objects);
if (name && no_try_delta(name))
entry->no_try_delta = 1;
@@ -1518,7 +1518,7 @@ static void find_deltas(struct object_entry **list, unsigned list_size,
progress_lock();
(*processed)++;
if (progress)
- display_progress(&progress_state, *processed);
+ display_progress(progress_state, *processed);
progress_unlock();
/*
@@ -1718,8 +1718,8 @@ static void prepare_pack(int window, int depth)
if (nr_deltas && n > 1) {
unsigned nr_done = 0;
if (progress)
- start_progress(&progress_state, "Compressing objects",
- nr_deltas);
+ progress_state = start_progress("Compressing 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,7 +2135,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
prepare_packed_git();
if (progress)
- start_progress(&progress_state, "Counting objects", 0);
+ progress_state = start_progress("Counting objects", 0);
if (!use_internal_rev_list)
read_object_list_from_stdin();
else {
diff --git a/builtin-prune-packed.c b/builtin-prune-packed.c
index 907e368..c66fb03 100644
--- a/builtin-prune-packed.c
+++ b/builtin-prune-packed.c
@@ -8,7 +8,7 @@ static const char prune_packed_usage[] =
#define DRY_RUN 01
#define VERBOSE 02
-static struct progress progress;
+static struct progress *progress;
static void prune_dir(int i, DIR *dir, char *pathname, int len, int opts)
{
@@ -16,7 +16,7 @@ static void prune_dir(int i, DIR *dir, char *pathname, int len, int opts)
char hex[40];
if (opts == VERBOSE)
- display_progress(&progress, i + 1);
+ display_progress(progress, i + 1);
sprintf(hex, "%02x", i);
while ((de = readdir(dir)) != NULL) {
@@ -46,8 +46,7 @@ void prune_packed_objects(int opts)
int len = strlen(dir);
if (opts == VERBOSE)
- start_progress_delay(&progress,
- "Removing duplicate objects",
+ progress = start_progress_delay("Removing duplicate objects",
256, 95, 2);
if (len > PATH_MAX - 42)
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index 2317b8f..e0ecbc5 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -311,7 +311,7 @@ static void unpack_one(unsigned nr)
static void unpack_all(void)
{
int i;
- struct progress progress;
+ struct progress *progress = NULL;
struct pack_header *hdr = fill(sizeof(struct pack_header));
unsigned nr_objects = ntohl(hdr->hdr_entries);
@@ -322,12 +322,12 @@ static void unpack_all(void)
use(sizeof(struct pack_header));
if (!quiet)
- start_progress(&progress, "Unpacking objects", nr_objects);
+ progress = start_progress("Unpacking objects", nr_objects);
obj_list = xmalloc(nr_objects * sizeof(*obj_list));
for (i = 0; i < nr_objects; i++) {
unpack_one(i);
if (!quiet)
- display_progress(&progress, i + 1);
+ display_progress(progress, i + 1);
}
if (!quiet)
stop_progress(&progress);
diff --git a/index-pack.c b/index-pack.c
index 2f149a4..b4543a4 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -46,7 +46,7 @@ static int nr_resolved_deltas;
static int from_stdin;
static int verbose;
-static struct progress progress;
+static struct progress *progress;
/* We always read in 4kB chunks. */
static unsigned char input_buffer[4096];
@@ -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 objects", nr_objects);
+ progress = start_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);
@@ -419,7 +419,7 @@ static void parse_pack_objects(unsigned char *sha1)
sha1_object(data, obj->size, obj->type, obj->idx.sha1);
free(data);
if (verbose)
- display_progress(&progress, i+1);
+ display_progress(progress, i+1);
}
objects[i].idx.offset = consumed_bytes;
if (verbose)
@@ -455,7 +455,7 @@ static void parse_pack_objects(unsigned char *sha1)
* for some more deltas.
*/
if (verbose)
- start_progress(&progress, "Resolving deltas", nr_deltas);
+ progress = start_progress("Resolving deltas", nr_deltas);
for (i = 0; i < nr_objects; i++) {
struct object_entry *obj = &objects[i];
union delta_base base;
@@ -487,7 +487,7 @@ static void parse_pack_objects(unsigned char *sha1)
}
free(data);
if (verbose)
- display_progress(&progress, nr_resolved_deltas);
+ display_progress(progress, nr_resolved_deltas);
}
}
@@ -595,7 +595,7 @@ static void fix_unresolved_deltas(int nr_unresolved)
append_obj_to_pack(d->base.sha1, data, size, type);
free(data);
if (verbose)
- display_progress(&progress, nr_resolved_deltas);
+ display_progress(progress, nr_resolved_deltas);
}
free(sorted_by_pos);
}
diff --git a/progress.c b/progress.c
index 7629e05..7f9b00e 100644
--- a/progress.c
+++ b/progress.c
@@ -1,6 +1,15 @@
#include "git-compat-util.h"
#include "progress.h"
+struct progress {
+ const char *title;
+ int last_value;
+ unsigned total;
+ unsigned last_percent;
+ unsigned delay;
+ unsigned delayed_percent_treshold;
+};
+
static volatile sig_atomic_t progress_update;
static void progress_interval(int signum)
@@ -76,12 +85,18 @@ static int display(struct progress *progress, unsigned n, int done)
int display_progress(struct progress *progress, unsigned n)
{
- return display(progress, n, 0);
+ return progress ? display(progress, n, 0) : 0;
}
-void start_progress_delay(struct progress *progress, const char *title,
- unsigned total, unsigned percent_treshold, unsigned delay)
+struct progress * start_progress_delay(const char *title, unsigned total,
+ unsigned percent_treshold, unsigned delay)
{
+ struct progress *progress = malloc(sizeof(*progress));
+ if (!progress) {
+ /* unlikely, but here's a good fallback */
+ fprintf(stderr, "%s...\n", title);
+ return NULL;
+ }
progress->title = title;
progress->total = total;
progress->last_value = -1;
@@ -89,19 +104,25 @@ void start_progress_delay(struct progress *progress, const char *title,
progress->delayed_percent_treshold = percent_treshold;
progress->delay = delay;
set_progress_signal();
+ return progress;
}
-void start_progress(struct progress *progress, const char *title, unsigned total)
+struct progress * start_progress(const char *title, unsigned total)
{
- start_progress_delay(progress, title, total, 0, 0);
+ return start_progress_delay(title, total, 0, 0);
}
-void stop_progress(struct progress *progress)
+void stop_progress(struct progress **p_progress)
{
+ struct progress *progress = *p_progress;
+ if (!progress)
+ return;
+ *p_progress = NULL;
if (progress->last_value != -1) {
/* Force the last update */
progress_update = 1;
display(progress, progress->last_value, 1);
}
clear_progress_signal();
+ free(progress);
}
diff --git a/progress.h b/progress.h
index 07b56bd..29780ce 100644
--- a/progress.h
+++ b/progress.h
@@ -1,20 +1,12 @@
#ifndef PROGRESS_H
#define PROGRESS_H
-struct progress {
- const char *title;
- int last_value;
- unsigned total;
- unsigned last_percent;
- unsigned delay;
- unsigned delayed_percent_treshold;
-};
+struct progress;
int display_progress(struct progress *progress, unsigned n);
-void start_progress(struct progress *progress, const char *title,
- unsigned total);
-void start_progress_delay(struct progress *progress, const char *title,
- unsigned total, unsigned percent_treshold, unsigned delay);
-void stop_progress(struct progress *progress);
+struct progress * start_progress(const char *title, unsigned total);
+struct progress * start_progress_delay(const char *title, 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 3225101..6776c29 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -297,7 +297,7 @@ static void check_updates(struct cache_entry **src, int nr,
{
unsigned short mask = htons(CE_UPDATE);
unsigned cnt = 0, total = 0;
- struct progress progress;
+ struct progress *progress = NULL;
char last_symlink[PATH_MAX];
if (o->update && o->verbose_update) {
@@ -307,8 +307,8 @@ static void check_updates(struct cache_entry **src, int nr,
total++;
}
- start_progress_delay(&progress, "Checking out files",
- total, 50, 2);
+ progress = start_progress_delay("Checking out files",
+ total, 50, 2);
cnt = 0;
}
@@ -318,7 +318,7 @@ static void check_updates(struct cache_entry **src, int nr,
if (total)
if (!ce->ce_mode || ce->ce_flags & mask)
- display_progress(&progress, ++cnt);
+ display_progress(progress, ++cnt);
if (!ce->ce_mode) {
if (o->update)
unlink_entry(ce->name, last_symlink);
@@ -333,7 +333,7 @@ static void check_updates(struct cache_entry **src, int nr,
}
}
if (total)
- stop_progress(&progress);;
+ stop_progress(&progress);
}
int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options *o)
--
1.5.3.4.1463.gf79ad2
^ permalink raw reply related
* [PATCH 3/5] relax usage of the progress API
From: Nicolas Pitre @ 2007-10-30 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1193770655-20492-3-git-send-email-nico@cam.org>
Since it is now OK to pass a null pointer to display_progress() and
stop_progress() resulting in a no-op, then we can simplify the code
and remove a bunch of lines by not making those calls conditional all
the time.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 18 ++++++------------
builtin-prune-packed.c | 6 ++----
builtin-unpack-objects.c | 6 ++----
index-pack.c | 20 +++++++-------------
unpack-trees.c | 8 +++-----
5 files changed, 20 insertions(+), 38 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 3ca5cc7..52a26a2 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -629,8 +629,7 @@ static void write_pack_file(void)
if (!offset_one)
break;
offset = offset_one;
- if (do_progress)
- display_progress(progress_state, written);
+ display_progress(progress_state, written);
}
/*
@@ -684,8 +683,7 @@ static void write_pack_file(void)
} while (nr_remaining && i < nr_objects);
free(written_list);
- if (do_progress)
- stop_progress(&progress_state);
+ stop_progress(&progress_state);
if (written != nr_result)
die("wrote %u objects while expecting %u", written, nr_result);
/*
@@ -853,8 +851,7 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
else
object_ix[-1 - ix] = nr_objects;
- if (progress)
- display_progress(progress_state, nr_objects);
+ display_progress(progress_state, nr_objects);
if (name && no_try_delta(name))
entry->no_try_delta = 1;
@@ -1517,8 +1514,7 @@ static void find_deltas(struct object_entry **list, unsigned list_size,
progress_lock();
(*processed)++;
- if (progress)
- display_progress(progress_state, *processed);
+ display_progress(progress_state, *processed);
progress_unlock();
/*
@@ -1722,8 +1718,7 @@ static void prepare_pack(int window, int depth)
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)
- stop_progress(&progress_state);
+ stop_progress(&progress_state);
if (nr_done != nr_deltas)
die("inconsistency with delta count");
}
@@ -2142,8 +2137,7 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
rp_av[rp_ac] = NULL;
get_object_list(rp_ac, rp_av);
}
- if (progress)
- stop_progress(&progress_state);
+ stop_progress(&progress_state);
if (non_empty && !nr_result)
return 0;
diff --git a/builtin-prune-packed.c b/builtin-prune-packed.c
index c66fb03..f4287da 100644
--- a/builtin-prune-packed.c
+++ b/builtin-prune-packed.c
@@ -15,8 +15,7 @@ static void prune_dir(int i, DIR *dir, char *pathname, int len, int opts)
struct dirent *de;
char hex[40];
- if (opts == VERBOSE)
- display_progress(progress, i + 1);
+ display_progress(progress, i + 1);
sprintf(hex, "%02x", i);
while ((de = readdir(dir)) != NULL) {
@@ -64,8 +63,7 @@ void prune_packed_objects(int opts)
prune_dir(i, d, pathname, len + 3, opts);
closedir(d);
}
- if (opts == VERBOSE)
- stop_progress(&progress);
+ stop_progress(&progress);
}
int cmd_prune_packed(int argc, const char **argv, const char *prefix)
diff --git a/builtin-unpack-objects.c b/builtin-unpack-objects.c
index e0ecbc5..1e51865 100644
--- a/builtin-unpack-objects.c
+++ b/builtin-unpack-objects.c
@@ -326,11 +326,9 @@ static void unpack_all(void)
obj_list = xmalloc(nr_objects * sizeof(*obj_list));
for (i = 0; i < nr_objects; i++) {
unpack_one(i);
- if (!quiet)
- display_progress(progress, i + 1);
+ display_progress(progress, i + 1);
}
- if (!quiet)
- stop_progress(&progress);
+ stop_progress(&progress);
if (delta_list)
die("unresolved deltas left after unpacking");
diff --git a/index-pack.c b/index-pack.c
index b4543a4..879ea15 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -418,12 +418,10 @@ static void parse_pack_objects(unsigned char *sha1)
} else
sha1_object(data, obj->size, obj->type, obj->idx.sha1);
free(data);
- if (verbose)
- display_progress(progress, i+1);
+ display_progress(progress, i+1);
}
objects[i].idx.offset = consumed_bytes;
- if (verbose)
- stop_progress(&progress);
+ stop_progress(&progress);
/* Check pack integrity */
flush();
@@ -486,8 +484,7 @@ static void parse_pack_objects(unsigned char *sha1)
obj->size, obj->type);
}
free(data);
- if (verbose)
- display_progress(progress, nr_resolved_deltas);
+ display_progress(progress, nr_resolved_deltas);
}
}
@@ -594,8 +591,7 @@ static void fix_unresolved_deltas(int nr_unresolved)
die("local object %s is corrupt", sha1_to_hex(d->base.sha1));
append_obj_to_pack(d->base.sha1, data, size, type);
free(data);
- if (verbose)
- display_progress(progress, nr_resolved_deltas);
+ display_progress(progress, nr_resolved_deltas);
}
free(sorted_by_pos);
}
@@ -774,8 +770,7 @@ int main(int argc, char **argv)
deltas = xmalloc(nr_objects * sizeof(struct delta_entry));
parse_pack_objects(sha1);
if (nr_deltas == nr_resolved_deltas) {
- if (verbose)
- stop_progress(&progress);
+ stop_progress(&progress);
/* Flush remaining pack final 20-byte SHA1. */
flush();
} else {
@@ -788,11 +783,10 @@ int main(int argc, char **argv)
(nr_objects + nr_unresolved + 1)
* sizeof(*objects));
fix_unresolved_deltas(nr_unresolved);
- if (verbose) {
- stop_progress(&progress);
+ stop_progress(&progress);
+ if (verbose)
fprintf(stderr, "%d objects were added to complete this thin pack.\n",
nr_objects - nr_objects_initial);
- }
fixup_pack_header_footer(output_fd, sha1,
curr_pack, nr_objects);
}
diff --git a/unpack-trees.c b/unpack-trees.c
index 6776c29..c527d7d 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -316,9 +316,8 @@ static void check_updates(struct cache_entry **src, int nr,
while (nr--) {
struct cache_entry *ce = *src++;
- if (total)
- if (!ce->ce_mode || ce->ce_flags & mask)
- display_progress(progress, ++cnt);
+ if (!ce->ce_mode || ce->ce_flags & mask)
+ display_progress(progress, ++cnt);
if (!ce->ce_mode) {
if (o->update)
unlink_entry(ce->name, last_symlink);
@@ -332,8 +331,7 @@ static void check_updates(struct cache_entry **src, int nr,
}
}
}
- if (total)
- stop_progress(&progress);
+ stop_progress(&progress);
}
int unpack_trees(unsigned len, struct tree_desc *t, struct unpack_trees_options *o)
--
1.5.3.4.1463.gf79ad2
^ permalink raw reply related
* [PATCH 5/5] add throughput display to index-pack
From: Nicolas Pitre @ 2007-10-30 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1193770655-20492-5-git-send-email-nico@cam.org>
... and call it "Receiving objects" when over stdin to look clearer
to end users.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
index-pack.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index 879ea15..61ea762 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -87,6 +87,8 @@ static void *fill(int min)
die("early EOF");
die("read error on input: %s", strerror(errno));
}
+ if (from_stdin)
+ display_throughput(progress, ret);
input_len += ret;
} while (input_len < min);
return input_buffer;
@@ -406,7 +408,9 @@ static void parse_pack_objects(unsigned char *sha1)
* - remember base (SHA1 or offset) for all deltas.
*/
if (verbose)
- progress = start_progress("Indexing objects", nr_objects);
+ progress = start_progress(
+ from_stdin ? "Receiving objects" : "Indexing objects",
+ nr_objects);
for (i = 0; i < nr_objects; i++) {
struct object_entry *obj = &objects[i];
data = unpack_raw_entry(obj, &delta->base);
--
1.5.3.4.1463.gf79ad2
^ permalink raw reply related
* [PATCH 4/5] add throughput to progress display
From: Nicolas Pitre @ 2007-10-30 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1193770655-20492-4-git-send-email-nico@cam.org>
This adds the ability for the progress code to also display transfer
throughput when that makes sense.
The math was inspired by commit c548cf4ee0737a321ffe94f6a97c65baf87281be
from Linus.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
progress.c | 80 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
progress.h | 1 +
2 files changed, 77 insertions(+), 4 deletions(-)
diff --git a/progress.c b/progress.c
index 7f9b00e..23ee9f3 100644
--- a/progress.c
+++ b/progress.c
@@ -1,6 +1,19 @@
#include "git-compat-util.h"
#include "progress.h"
+#define TP_IDX_MAX 8
+
+struct throughput {
+ struct timeval prev_tv;
+ unsigned long count;
+ unsigned long avg_bytes;
+ unsigned long last_bytes[TP_IDX_MAX];
+ unsigned int avg_misecs;
+ unsigned int last_misecs[TP_IDX_MAX];
+ unsigned int idx;
+ char display[20];
+};
+
struct progress {
const char *title;
int last_value;
@@ -8,6 +21,7 @@ struct progress {
unsigned last_percent;
unsigned delay;
unsigned delayed_percent_treshold;
+ struct throughput *throughput;
};
static volatile sig_atomic_t progress_update;
@@ -46,7 +60,7 @@ static void clear_progress_signal(void)
static int display(struct progress *progress, unsigned n, int done)
{
- char *eol;
+ char *eol, *tp;
if (progress->delay) {
if (!progress_update || --progress->delay)
@@ -64,18 +78,20 @@ static int display(struct progress *progress, unsigned n, int done)
}
progress->last_value = n;
+ tp = (progress->throughput) ? progress->throughput->display : "";
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: %3u%% (%u/%u)%s", progress->title,
- percent, n, progress->total, eol);
+ fprintf(stderr, "%s: %3u%% (%u/%u)%s%s",
+ progress->title, percent, n,
+ progress->total, tp, eol);
progress_update = 0;
return 1;
}
} else if (progress_update) {
- fprintf(stderr, "%s: %u%s", progress->title, n, eol);
+ fprintf(stderr, "%s: %u%s%s", progress->title, n, tp, eol);
progress_update = 0;
return 1;
}
@@ -83,6 +99,60 @@ static int display(struct progress *progress, unsigned n, int done)
return 0;
}
+void display_throughput(struct progress *progress, unsigned long n)
+{
+ struct throughput *tp;
+ struct timeval tv;
+ unsigned int misecs;
+
+ if (!progress)
+ return;
+ tp = progress->throughput;
+
+ gettimeofday(&tv, NULL);
+
+ if (!tp) {
+ progress->throughput = tp = calloc(1, sizeof(*tp));
+ if (tp)
+ tp->prev_tv = tv;
+ return;
+ }
+
+ tp->count += n;
+
+ /*
+ * We have x = bytes and y = microsecs. We want z = KiB/s:
+ *
+ * z = (x / 1024) / (y / 1000000)
+ * z = x / y * 1000000 / 1024
+ * z = x / (y * 1024 / 1000000)
+ * z = x / y'
+ *
+ * To simplify things we'll keep track of misecs, or 1024th of a sec
+ * obtained with:
+ *
+ * y' = y * 1024 / 1000000
+ * y' = y / (1000000 / 1024)
+ * y' = y / 977
+ */
+ misecs = (tv.tv_sec - tp->prev_tv.tv_sec) * 1024;
+ misecs += (int)(tv.tv_usec - tp->prev_tv.tv_usec) / 977;
+
+ if (misecs > 512) {
+ tp->prev_tv = tv;
+ tp->avg_bytes += tp->count;
+ tp->avg_misecs += misecs;
+ snprintf(tp->display, sizeof(tp->display),
+ ", %lu KiB/s", tp->avg_bytes / tp->avg_misecs);
+ tp->avg_bytes -= tp->last_bytes[tp->idx];
+ tp->avg_misecs -= tp->last_misecs[tp->idx];
+ tp->last_bytes[tp->idx] = tp->count;
+ tp->last_misecs[tp->idx] = misecs;
+ tp->idx = (tp->idx + 1) % TP_IDX_MAX;
+ tp->count = 0;
+ }
+}
+
int display_progress(struct progress *progress, unsigned n)
{
return progress ? display(progress, n, 0) : 0;
@@ -103,6 +173,7 @@ struct progress * start_progress_delay(const char *title, unsigned total,
progress->last_percent = -1;
progress->delayed_percent_treshold = percent_treshold;
progress->delay = delay;
+ progress->throughput = NULL;
set_progress_signal();
return progress;
}
@@ -124,5 +195,6 @@ void stop_progress(struct progress **p_progress)
display(progress, progress->last_value, 1);
}
clear_progress_signal();
+ free(progress->throughput);
free(progress);
}
diff --git a/progress.h b/progress.h
index 29780ce..7902ca5 100644
--- a/progress.h
+++ b/progress.h
@@ -3,6 +3,7 @@
struct progress;
+void display_throughput(struct progress *progress, unsigned long n);
int display_progress(struct progress *progress, unsigned n);
struct progress * start_progress(const char *title, unsigned total);
struct progress * start_progress_delay(const char *title, unsigned total,
--
1.5.3.4.1463.gf79ad2
^ permalink raw reply related
* [PATCH] Fixed a command line option type for builtin-fsck.c
From: Emil Medve @ 2007-10-30 19:15 UTC (permalink / raw)
To: madcoder, spearce, gitster, git; +Cc: Emil Medve
The typo was introduced by this commit: 5ac0a2063e8f824f6e8ffb4d18de74c55aae7131
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
---
This patch applies to the 'next' branch
builtin-fsck.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 64da3bd..e4874f6 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -680,7 +680,7 @@ static struct option fsck_opts[] = {
OPT_BOOLEAN(0, "cache", &keep_cache_objects, "make index objects head nodes"),
OPT_BOOLEAN(0, "reflogs", &include_reflogs, "make reflogs head nodes (default)"),
OPT_BOOLEAN(0, "full", &check_full, "also consider alternate objects"),
- OPT_BOOLEAN(0, "struct", &check_strict, "enable more strict checking"),
+ OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
"write dangling objects in .git/lost-found"),
OPT_END(),
--
1.5.3.4.1458.g3e72e-dirty
^ permalink raw reply related
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Junio C Hamano @ 2007-10-30 19:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <52171BF7-50E2-473E-A0BD-CB64D38FD502@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:
>
>> It simply is insane to make this strange rule 10/10 introduces
>> the default behaviour. It is too specific to a particular
>> workflow (that is, working with a shared central repository,
>> having many locally tracking branches that are not often used
>> and become stale, and working on only things to completion
>> between pushes).
>
> I don't think its very strange behaviour if you see it in the
> light of what the user wants to achieve. We are talking about
> the case were only fast forward pushes are allowed. So, we
> only talk about a push that has the goal of adding new local
> changes to the remote. The user says "git push" and means
> push my new local changes to the remote.
If you want to push a specific subset of branches, you should
not be invoking the "matching refs" to begin with. And breaking
the "matching refs" behaviour is not the way to fix it.
You can rewind a wrong branch by mistake locally and run push.
With your change you would not notice that mistake.
$ git checkout bar
$ work work work; commit commit commit
$ git checkout test
$ git merge bar
... integrate, build, test
... notice that the tip commit of bar is not ready
$ git checkout foo ;# oops, mistake
$ git reset --hard HEAD^
$ git push
If you checked out foo instead of bar by mistake at the last
"git checkout" step like this, your change will make 'foo' an
ancestor of the other side of the connection, and push silently
ignores it instead of failing.
Also, the behaviour is too specific to your workflow of working
on things only to completion between pushes. If you work a bit
on branch 'foo' (but not complete), and work much on branch
'bar', 'baz', and 'boo' making all of them ready to be
published, you cannot say "git push" anyway. Instead you have
to say "git push $remote bar baz boo".
This discourages people from making commits that are not ready
to be published, which is a very wrong thing to do, as a major
selling point of distributed revision control is the
dissociation between committing and publishing.
You work and commit freely, and at any point some of your
branches are ready to be published while some others
aren't. Inconvenience of "matching refs" may need to be worked
around. I liked your "current branch only", with "git push
$remote HEAD" (I presume that "remote.$remote.push = HEAD" and
"branch.$current.remote = $remote" would let you do that with
"git push"), exactly because the way it specifies which branch
is to be published is very clearly defined and easy to
understand. This "matching but only ff" does not have that
attractive clarity.
^ permalink raw reply
* Re: [GIT-GUI PATCH 2/3] po2msg: ignore untranslated messages
From: Junio C Hamano @ 2007-10-30 19:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: stimming, spearce, git
In-Reply-To: <Pine.LNX.4.64.0710301124450.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Do not generate translations when the translated message is empty.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> po/po2msg.sh | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/po/po2msg.sh b/po/po2msg.sh
> index 48a2669..91d420b 100644
> --- a/po/po2msg.sh
> +++ b/po/po2msg.sh
> @@ -62,6 +62,9 @@ proc flush_msg {} {
> if {$msgid == ""} {
> set prefix "set ::msgcat::header"
> } else {
> + if {$msgstr == ""} {
> + return
> + }
> set prefix "::msgcat::mcset $lang \"[u2a $msgid]\""
> }
Is this change to fix some real issues?
Sometimes it is handy to be able to translate a non-empty string
into an empty one in one target language.
^ permalink raw reply
* Re: remote#branch
From: Pascal Obry @ 2007-10-30 19:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tom Prince, Theodore Tso, Junio C Hamano, Jan Hudec,
Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710301037120.30120@woody.linux-foundation.org>
Linus Torvalds a écrit :
> Nobody cares about git being consistent with a web browser. There is
> nothing in common.
I don't understand why you keep talking about web browser. URL is not a
web browser thing. It is the case that web browser are using URL, but
that's just one usage.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 19:38 UTC (permalink / raw)
To: Pascal Obry
Cc: Matthieu Moy, Tom Prince, Theodore Tso, Junio C Hamano, Jan Hudec,
Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <4727839B.9070205@obry.net>
On Tue, 30 Oct 2007, Pascal Obry wrote:
> Linus Torvalds a écrit :
> > I keep talking about a web browser, because THE ONLY POINT of following a
> > standard is to interoperate.
>
> Yes, and since URLs are not used for web browser only I do not see the
> point to concentrate all this discussion about a single possible usage.
Hey, it's find if you can come up with some *other* case why we should
care about RFC 1738.
I certainly didn't mean to bring up browsers as the _only_ case of
possible interoperability issues, but when it comes to URL's it's
certainly the obvious one...
So the only argument really is:
- Nobody has pointed to *any* reason to follow 1738.
- I have pointed to reasons *not* to do it.
So if you want to follow the RFC, you'd better give a real reason. And no,
the existence of an RFC, and the fact that people use the same name for
things that superficially _look_ the same is not a reason in itself.
So hands up, people. Anybody who asked for RFC quoting. Give a damn
*reason* already!
Linus
^ permalink raw reply
* [PATCH 6/5] add some copyright notice to the progress display code
From: Nicolas Pitre @ 2007-10-30 19:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1193770655-20492-6-git-send-email-nico@cam.org>
Some self patting on the back to keep my ego alive.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/progress.c b/progress.c
index 23ee9f3..2c4057a 100644
--- a/progress.c
+++ b/progress.c
@@ -1,3 +1,13 @@
+/*
+ * Simple text-based progress display module for GIT
+ *
+ * Copyright (c) 2007 by Nicolas Pitre <nico@cam.org>
+ *
+ * This code is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
#include "git-compat-util.h"
#include "progress.h"
^ permalink raw reply related
* Re: remote#branch
From: Jan Hudec @ 2007-10-30 19:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tom Prince, Theodore Tso, Junio C Hamano, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710300738550.30120@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]
On Tue, Oct 30, 2007 at 07:59:45 -0700, Linus Torvalds wrote:
> > So, how should git deal with
> >
> > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
>
> The way it has always cared. Git itself does no quoting what-so-ever
> (except for the *argument* quoting etc that it needs).
>
> Now, the *transport* back-end may end up quoting it, of course, the same
> way it may end up using some random protocol. The user shouldn't care
> about the implementation details!
>
> In the case of the git transport, there is no quoting even by the
> transport protocol. In the case of http, libcurl would hopefully quote for
> us.
So the three addresses will all be different, right?
> > compared to
> >
> > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
>
> No difference, what-so-ever, that I can see. Git doesn't quote it.
Yes. But the server will unquote it. ' ' should not have been there, but it's
just passed through if it was. '+' is quoting for ' ' and '%20' is quoting
for ' ' as well. Therefore all these three addresses are the *SAME*.
Now the user expectation will be that when these are the same, the git://
ones above will be as well. But they are not. This is not about following any
RFC for sake of it, but about being consistent with ourselves.
> Notice how the fact that we use http:// doesn't actually mean that you can
> feed the result to a web browser anyway? It's not like you get a "link"
> that git follows. You get a name.
>
> Yes, you can try to "co-locate" things so that something smart
> disambiguates (maybe have an "index.html" file, so a web browser gets a
> gitweb page, and git gets the raw data). But even then, notice how even
> web browser will do the quoting for you: try
>
> firefox "http://www.google.com/search?q=Html spaces"
>
> just for fun.
Sure. There is no abiguity in decoding this, so why refuse it.
> [...]
> - <remote shorthand> ("origin")
> - <path> ("../git.git")
> - <host>:<path> ("master.kernel.org:/pub/scm/...")
> - <protocol>://<host>/<path> ("git://repo.or.cz/...")
>
> See? We may not follow RFC's, but we follow "easy to use".
The first three don't look like URL ("URL" always means the thing defined by
RFC 2396, at least to me), so I don't expect any quoting there. But for the
last case http:// (and for that matter, sftp://) do use quoting, so I would
expect the quoting of something that differs only by starting with git:// to
work the same.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-merge: inconsistent manual page.
From: Sergei Organov @ 2007-10-30 19:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5p4l9gs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Subject: git-merge: document but discourage the historical syntax
>
> Historically "git merge" took its command line arguments in a
> rather strange order. Document the historical syntax, and also
> document clearly that it is not encouraged in new scripts.
>
> There is no reason to deprecate the historical syntax, as the
> current code can sanely tell which syntax the caller is using,
> and existing scripts by people do use the historical syntax.
OK, your patch is better than what I've suggested. The only thing that
your patch seems to be missing is prepending -m to <msg>:: in the
OPTIONS section. Yeah, it could be more strict to just describe <msg>,
but if there were no historical syntax, then you'd put '-m <msg>'
description in, right? So the latter might be better anyway.
--
Sergei.
^ permalink raw reply
* [PATCH] core-tutorial: Use new syntax for git-merge.
From: Sergei Organov @ 2007-10-30 19:54 UTC (permalink / raw)
To: git
The patch below turns core-tutorial to use new syntax for
git-merge. Please take close look at the last diff chunk, -- I'm not sure I
got it right as it didn't have HEAD in the original version, -- was it already
wrong before the patch?
---
Documentation/core-tutorial.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index d8e78ac..02255d8 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -878,7 +878,7 @@ script called `git merge`, which wants to know which branches you want
to resolve and what the merge is all about:
------------
-$ git merge "Merge work in mybranch" HEAD mybranch
+$ git merge -m "Merge work in mybranch" mybranch
------------
where the first argument is going to be used as the commit message if
@@ -965,7 +965,7 @@ to the `master` branch. Let's go back to `mybranch`, and run
------------
$ git checkout mybranch
-$ git merge "Merge upstream changes." HEAD master
+$ git merge -m "Merge upstream changes." master
------------
This outputs something like this (the actual commit object names
@@ -1607,8 +1607,8 @@ in both of them. You could merge in 'diff-fix' first and then
'commit-fix' next, like this:
------------
-$ git merge 'Merge fix in diff-fix' master diff-fix
-$ git merge 'Merge fix in commit-fix' master commit-fix
+$ git merge -m 'Merge fix in diff-fix' master diff-fix
+$ git merge -m 'Merge fix in commit-fix' master commit-fix
------------
Which would result in:
--
1.5.3.4
^ permalink raw reply related
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 19:53 UTC (permalink / raw)
To: Jan Hudec
Cc: Tom Prince, Theodore Tso, Junio C Hamano, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071030193610.GA4442@efreet.light.src>
On Tue, 30 Oct 2007, Jan Hudec wrote:
> >
> > Now, the *transport* back-end may end up quoting it, of course, the same
> > way it may end up using some random protocol. The user shouldn't care
> > about the implementation details!
>
> Yes. But the server will unquote it. ' ' should not have been there, but it's
> just passed through if it was. '+' is quoting for ' ' and '%20' is quoting
> for ' ' as well. Therefore all these three addresses are the *SAME*.
Ok, you have some reading comprehension skills.
Read the above again.
I'd certainly hope that *curl* does the proper quoting. That's a transport
issue.
Linus
^ permalink raw reply
* [PATCH] more compact user direction message
From: Nicolas Pitre @ 2007-10-30 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
A failed cherry-pick (and friend) currently says:
|Automatic cherry-pick failed. After resolving the conflicts,
|mark the corrected paths with 'git-add <paths>'
|and commit the result.
This can obviously be displayed on two lines only.
While at it, change "git-add" to "git add".
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-revert.c b/builtin-revert.c
index 2cd9ca5..50c2e18 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -364,7 +364,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
die ("Error wrapping up %s", defmsg);
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
- "mark the corrected paths with 'git-add <paths>'\n"
+ "mark the corrected paths with 'git add <paths>' "
"and commit the result.\n", me);
if (action == CHERRY_PICK) {
fprintf(stderr, "When commiting, use the option "
^ permalink raw reply related
* Re: [PATCH] core-tutorial: Use new syntax for git-merge.
From: Junio C Hamano @ 2007-10-30 20:05 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <87lk9k4bvp.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> The patch below turns core-tutorial to use new syntax for
> git-merge. Please take close look at the last diff chunk, -- I'm not sure I
> got it right as it didn't have HEAD in the original version, -- was it already
> wrong before the patch?
You do not want the extra 'master' there.
> @@ -1607,8 +1607,8 @@ in both of them. You could merge in 'diff-fix' first and then
> 'commit-fix' next, like this:
>
> ------------
> -$ git merge 'Merge fix in diff-fix' master diff-fix
> -$ git merge 'Merge fix in commit-fix' master commit-fix
> +$ git merge -m 'Merge fix in diff-fix' master diff-fix
> +$ git merge -m 'Merge fix in commit-fix' master commit-fix
> ------------
The example is working on 'master' branch at this point and HEAD
and 'master' are equivalent there.
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Mike Snitzer @ 2007-10-30 20:06 UTC (permalink / raw)
To: Michael Haggerty
Cc: Eyvind Bernhardsen, Thomas Pasch, git, Jan Wielemaker,
Gerald (Jerry) Carter, dev
In-Reply-To: <F1176033-1C6E-43F3-9F47-3BDD5EC88A14@orakel.ntnu.no>
On 10/10/07, Eyvind Bernhardsen <eyvind-git-list@orakel.ntnu.no> wrote:
...
>
> Thanks for making cvs2svn the best CVS-to-git conversion tool :) Now
> if it would only support incremental importing...
Michael,
I second this question: is there any chance incremental importing will
be implemented in cvs2svn?
I've not used cvs2svn much and when I did it was for svn not git; but
given that git-cvsimport is known to mess up your git repo (as Eyvind
pointed out earlier) there doesn't appear to be any reliable tools to
allow for incrementally importing from cvs to git.
Are others using a tool for reliably importing from cvs to git?
^ permalink raw reply
* Re: remote#branch
From: Randal L. Schwartz @ 2007-10-30 20:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pascal Obry, Matthieu Moy, Tom Prince, Theodore Tso,
Junio C Hamano, Jan Hudec, Johannes Schindelin, Petr Baudis,
Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710301232000.30120@woody.linux-foundation.org>
>>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:
Linus> So the only argument really is:
Linus> - Nobody has pointed to *any* reason to follow 1738.
Linus> - I have pointed to reasons *not* to do it.
I can support non-compliance with 1738. However, I'd also suggest
that outside of this cozy group of developers, URL already has a heavily
defined meaning associated with 1738.
Therefore, I propose that the git docs refrain from calling these things
"URLs" because they're not, and instead adopt something like "GRL" (git
resources locator) or whatever.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [PATCH/RFC 0/3] faster inexact rename handling
From: Jeff King @ 2007-10-30 20:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Andy C, Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710300818390.30120@woody.linux-foundation.org>
On Tue, Oct 30, 2007 at 08:38:24AM -0700, Linus Torvalds wrote:
> > with the old and new code. Pairs like Documentation/git-add-script.txt
> > -> Documentation/git-add.txt are not found, because the file is composed
> > almost entirely of boilerplate.
>
> Ok, that does imply to me that we cannot just drop boilerplate text,
> because the fact is, lots of files contain boilerplate, but people still
> think they are "similar".
Well, the problem is that instead of just "dropping" boilerplate text,
we fail to count it as a similarity, but it still counts towards the
file size. It may be that just dropping it totally is the right thing
(in which case those renames _will_ turn up, because they will be filled
with identical non-boilerplate goodness).
> Hmm. I hope that is sufficient. But I suspect it may well not be.
> Especially since you ignore boiler-plate lines for *some* files but not
> others (ie it depends on which file you happen to find it in first).
Yes, that part bothers me a little, so I think a "too common, ignore"
overflow flag would at least be better.
But I think the best thing to do now is for me to shut up and see what
the results look like with the tweaks I have mentioned.
-Peff
^ permalink raw reply
* Re: [PATCH] Fixed a command line option type for builtin-fsck.c
From: Pierre Habouzit @ 2007-10-30 20:20 UTC (permalink / raw)
To: Emil Medve; +Cc: spearce, gitster, git
In-Reply-To: <1193771721-2880-1-git-send-email-Emilian.Medve@Freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]
On Tue, Oct 30, 2007 at 07:15:21PM +0000, Emil Medve wrote:
> The typo was introduced by this commit: 5ac0a2063e8f824f6e8ffb4d18de74c55aae7131
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Acked-By: Pierre Habouzit <madcoder@debian.org>
good catch.
> ---
>
> This patch applies to the 'next' branch
>
> builtin-fsck.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-fsck.c b/builtin-fsck.c
> index 64da3bd..e4874f6 100644
> --- a/builtin-fsck.c
> +++ b/builtin-fsck.c
> @@ -680,7 +680,7 @@ static struct option fsck_opts[] = {
> OPT_BOOLEAN(0, "cache", &keep_cache_objects, "make index objects head nodes"),
> OPT_BOOLEAN(0, "reflogs", &include_reflogs, "make reflogs head nodes (default)"),
> OPT_BOOLEAN(0, "full", &check_full, "also consider alternate objects"),
> - OPT_BOOLEAN(0, "struct", &check_strict, "enable more strict checking"),
> + OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
> OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
> "write dangling objects in .git/lost-found"),
> OPT_END(),
> --
> 1.5.3.4.1458.g3e72e-dirty
>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 20:30 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Pascal Obry, Matthieu Moy, Tom Prince, Theodore Tso,
Junio C Hamano, Jan Hudec, Johannes Schindelin, Petr Baudis,
Paolo Ciarrocchi, git
In-Reply-To: <86tzo81hrd.fsf@blue.stonehenge.com>
On Tue, 30 Oct 2007, Randal L. Schwartz wrote:
>
> Therefore, I propose that the git docs refrain from calling these things
> "URLs" because they're not, and instead adopt something like "GRL" (git
> resources locator) or whatever.
They're called "GIT URLS" right now. I'd have hoped that was descriptive
enough. But maybe not.
I think it's stupid to make up a new name, it's not like it's really
ambiguous *or* as if people really think in terms of RFC's.
Let's face it: people talk and use email, even when they don't have a clue
about SMTP. And in practice, you'll never see any difference, apart from
the obvious extension of using the ssh format and the direct local path
thing.
Linus
^ permalink raw reply
* Re: remote#branch
From: Nicolas Pitre @ 2007-10-30 20:36 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Linus Torvalds, Pascal Obry, Matthieu Moy, Tom Prince,
Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <86tzo81hrd.fsf@blue.stonehenge.com>
On Tue, 30 Oct 2007, Randal L. Schwartz wrote:
> >>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> Linus> So the only argument really is:
>
> Linus> - Nobody has pointed to *any* reason to follow 1738.
>
> Linus> - I have pointed to reasons *not* to do it.
>
> I can support non-compliance with 1738. However, I'd also suggest
> that outside of this cozy group of developers, URL already has a heavily
> defined meaning associated with 1738.
>
> Therefore, I propose that the git docs refrain from calling these things
> "URLs" because they're not, and instead adopt something like "GRL" (git
> resources locator) or whatever.
And what do you do with the remote.<name>.url config option?
Add some backward compatibility cruft for some... well... issue that
turns out not to be one in practice?
Again, can someone point to a real usage scenario where all this
discussion is solving something?
Nicolas
^ permalink raw reply
* Re: [PATCH/RFC 0/3] faster inexact rename handling
From: Linus Torvalds @ 2007-10-30 20:39 UTC (permalink / raw)
To: Jeff King; +Cc: git, Andy C, Junio C Hamano
In-Reply-To: <20071030202014.GA22733@coredump.intra.peff.net>
On Tue, 30 Oct 2007, Jeff King wrote:
>
> Well, the problem is that instead of just "dropping" boilerplate text,
> we fail to count it as a similarity, but it still counts towards the
> file size. It may be that just dropping it totally is the right thing
> (in which case those renames _will_ turn up, because they will be filled
> with identical non-boilerplate goodness).
Yeah, you may well be right, and the normalization of the scores will just
solve things.
Linus
^ 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