* [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 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 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 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 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
* 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] 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: [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
* 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: Git User's Survey 2007 summary - git homepage improvements
From: Petr Baudis @ 2007-10-17 1:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8fe92b430710141505y75ab61c4l50688fc9530e4f90@mail.gmail.com>
On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> This website itself is tracked in Git as well - you can browse its
> development history or even clone it from
> http://repo.or.cz/r/git-homepage.git. The site is covered by GPLv2 and
> maintained by Petr Baudis who always takes patches eagerly. ;-)
Note that if someone is going to contribute to the homepage more
regularily, I can give him push access as well.
> Here is short summary of most common answers, with a short comment if
> appropriate:
>
> Generic:
> # Dedicated domain name / site name, e.g. git.org or git.com
> to have it look less like mirror or unofficial page
>
> (git.or.cz still comes first when searching Google for "git";
> current domain name was available to homepage admin - historical
> reason)
See my other mail in this thread; if someone registers it, I can set
everything else up.
> # Better design: make it prettier, easier to find information,
> move more important things first, use sidebar instead of boxes,
> perhaps divide it into separate pages (again). But make sure it
> works on Elinks for example.
>
> (IIRC pasky is not web designer, so help is appreciated)
I'm not really unhappy with the current layout - I think it is pretty
enough but simple. Dividing it to separate pages is question of taste
and opinitions simply differ; I personally think with the current amount
of information single page is fine. OTOH I think it would be nicer to
get more content on the page, then perhaps split it up. :-)
Sure, the webpage could be much prettier, with cute graphics and so on.
But I'm not a webdesigner and can't really do these things better than
how they already are. And is it really that bad?
> Documentation
> # More documentation: tutorials, workflow examples, walkthroughs,
> SCM commands comparison, interacting with other SCMs, HOWTOs, best
> practices, recommended tools, fluxograms describing use cases
> (graphics). Make link to Git User's Manual stand out better.
Yes, please! Bring it on! ;-)
> # Less emphasizis on Cogito, mark it more explicitely as deprecated
> and slowly try to get rid of Cogito references in documentation
> (e.g. crash courses).
>
> (Cogito is officially deprecated from not a long time; the process
> of removing references to cg in crash courses is AFAIK ongoing)
Fixed, hopefully?
> # Simple online demo. The demo could be an applet giving access to a
> terminal of a running virtual machine with git and some demo
> repositories. The virtual machine is reset every full hour.
>
> (This might be a good idea, but I think it is a bit hard to do from
> technical point of view; at least securely, securing against
> intrusion and, perhaps accidental, denial of service)
Yes, and I don't think this is all that important since Git should be
readily available pre-packaged on all popular Linux distributions.
> Downloads:
> # More up-to-date about new git versions.
>
> (With one person updating homepage, who is not git maintainer...)
That shouldn't have been a problem since May; there is a script being
run every 4 hours that syncs this up. If the homepage isn't picking a
release up in a timely fashion, that's a bug and I need to know about
it; I didn't notice anything like that yet, though.
> # There should be links to download pu/next/master/maint branches
> tar.gz trees (snapshots) from gitweb.
>
> (The source snapshot part is quite easy to do, but it might
> increase load on kernel.org / repo.or.cz, unless snapshots are
> somehow cached)
Why would anyone want this? Adding extra useless or seldom-used links to
the homepage is actually harmful, the important ones must not get lost
between those.
> # Results of nightly builds and tests.
> Static binaries for other OS (FreeBSD, MacOS X).
>
> (There is a matter of machine park. Somewhere those nightly builds,
> perhaps together with nightly running of test suite, have to run.)
This is not something for the Git homepage itself. If someone volunteers
to run a tinderbox-like thing for Git, cool. I can link to it. ;-)
> # Information about MS Windows version(s). Link to MSys Git, marking
> it as under development; perhaps plea for help?
I'm not sure what in particular the MSys people want... They may want to
send patches, though. ;-)
Maybe we could merge the (largely artificially separated anyway)
subproject subsections to a single alphabetically-ordered subsection and
include MSysGit there?
> # Provide processed man pages to install.
> Provide PDF documentation, at least PDF version of Git User's Manual.
>
> (Having PDF version is quite new; there is no manual.pdf target in
> official Makefile.)
I think it's more appropriate to link to this from inside the k.org Git
Manual site.
> Information, new links, new features
> # Link to the latest release announcement (RelNotes) on download page.
>
> (Links to relnotes are in HTML version of git(7) manpage, but I
> think it is not enough. Happily we _have_ release announcements)
Done.
> # News section, info about where things are goung (roadmap)
>
> (Junio has a hard time maintaining TODO, and git doesn't have
> roadmap AFAICT)
Maybe something like the News section could be nice, but someone else
would have to maintain it.
Then again, what would be the contents? Just aggregating recent
announces? Cc' posting-restricted mailing list on these and link to its
archives, and you will make more people happy.
> # Provide 'A note from the maintainer' as a prominent link probably
> named as 'How the git project is managed and how to participate'
>
> (That is a good idea I think, better than having it on GitWiki.
> We can put direct link to SubmittingPatches nearby.)
Yes, got a patch from Michael Witten for this few days ago, applied now.
Thanks, Michael!
> # Links to more tools, GUIs, version control interface layers.
> A somewhat related request: copy pages like FAQ or Tips and Tricks,
> or discussion about branches from GitWiki when they are mature
> enough.
>
> (For example there was requests to put links to / info about Guilt
> and Giggle on git homepage. Giggle has quite a bit of users among
> GUIs).
I can't remember ever getting a patch. If I missed it, I'm sorry -
please resend.
> Code and design
> * More prominent links to documentation on how to get started with
> GIT.
How much more prominent can you be? :)
> * The layout and the organization of the sections. It's pretty hard
> to know why should I use git just looking at the webpage.
This is one of the things I tried to optimalize the layout to. If it
doesn't work, I'm sorry but I'm not getting it and you need to be more
concrete.
> * Hide the rarer commands and special tricks deeper and emphasize the
> best usage practices.
That's rather about the Git manual?
> * Download link needs to stand out more. The homepage appears rather
> 'flat' that is nothing stands out as more important than the rest.
Maybe this improved a bit today.
> In order of importance, I think there should be:
> 1. Download
> 2. Git Quickstart Guide
> 3. Documentation
Funnily enough, this _is_ the order in which the information flows.
> * The lines are too long. Try to find a better proportion.
The sidebar would help here, I guess. Counter-argument is that sidebar
would take up space for the main content. ;-)
Opinions? Should the lines get a bit shorter? I'd almost agree.
> * It doesn't look like a project home page.
> Mercurial does a better job with the look of their page IMHO.
I actually find Mercurial's homepage much uglier, personally.
> Documentation
Many suggestions here are for the Git manual, actually; that's a good
sign that the integration isn't working so badly after all.
> * 'git for svn/cvs people' could use an overhaul
> (at least they did a few months ago)
> The Git for SVN users tutorial is incomplete and does not explain
> for example how the index works and why it's there. Thus people end
> up thinking that 'svn add' is like 'git add' whereas it's not.
Yes, this would be nice to get improved; however, the surgery needs to
be very careful in order to avoid complicating or confusing things up
too much - I already got few patches that tried, but the end result
wasn't really working well. Maybe the whole crash course should just be
rewritten along the lines of the Git tutorial?
> * Add some material for presenting git to others (slides)
> * Perhaps making some pages like FAQ or Tips and Tricks, or
> discussion about nature of branches in git taken from GitWiki when
> they are mature enough
This touches a subject that I'm kind of surprised wasn't mentioned more,
that is the homepage-wiki duality. Are people happy with the current
setup? I kinda am, or would be if I got more patches. ;-) I'm personally
not too fond of having project's main homepage in wiki -
*especially* if it's made obvious by half of the screen space being
occupied by wiki-generated metalinks. But if everyone else thinks that
we should just move the main page to a wiki format, I won't stay in the
way.
I'd like to use this space to also repeat that I never seriously
intended to maintain the technical side of the wiki, I've set up just
because it was so damn easy. I have grown to just hate the wiki engine
we use, and if someone wants to take the wiki over, you are welcome!
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* [PATCH] gitweb: speed up project listing by limiting find depth
From: Luke Lu @ 2007-10-17 1:13 UTC (permalink / raw)
To: git; +Cc: pasky, Luke Lu
Resubmit patch due to tab/space issue :)
Signed-off-by: Luke Lu <git@vicaya.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 11 +++++++++++
2 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..d62357f 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,16 +1513,23 @@ 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
follow_skip => 2, # ignore duplicates
+ no_chdir => 1, # don't chdir into every directory
dangling_symlinks => 0, # ignore dangling symlinks, silently
wanted => sub {
# skip project-list toplevel, if we get it.
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 (tr!/!! - $pfxdepth > $project_maxdepth) {
+ $File::Find::prune = 1;
+ return;
+ }
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 3/3] git-cvsexportcommit.perl: git-apply no longer needs --binary
From: Shawn O. Pearce @ 2007-10-17 1:11 UTC (permalink / raw)
To: Michael Witten; +Cc: Robin Rosenberg, git
In-Reply-To: <561D7B44-9EDE-447B-A751-BE6E3A3AD9CC@mit.edu>
Michael Witten <mfwitten@MIT.EDU> wrote:
> On 16 Oct 2007, at 5:20:14 PM, Robin Rosenberg wrote:
>
> >So all this series does is... making it harder to follow the history?
>
> If you follow the history solely on patches.
`git-blame -w` can probably punch through the indentation change
just fine to find the older history. But it does make `git log -p`
damn ugly to read at this point in history. And if you forget the
-w to git-blame, well, then you are really in for some fun for a
few minutes. Lets not mention pickaxe noticing strings removed+added
in this patch either.
> >Ack for removing the --binary, the rest is just noise
>
> I think fixing the tabs is more important than removing --binary.
>
> It's clear the the entropy of tabulation increases over time;
> the tab patch acts as a buffer to reconstruct a clean signal.
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.
There needs to be a really good reason behind a change, like the
existing code is already not functioning according to its documented
behavior due to a corner case input. Such things should be changed.
I'm not going to apply the indentation change patch to my tree.
You can try to resubmit it through Junio after he's back online
and accepting patches.
--
Shawn.
^ permalink raw reply
* [PATCH] gitweb: speed up project listing by limiting find depth
From: Luke Lu @ 2007-10-17 1:03 UTC (permalink / raw)
To: git; +Cc: pasky, Luke Lu
Resubmit patch based on feedback from Shawn O. Pearce.
Signed-off-by: Luke Lu <git@vicaya.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 11 +++++++++++
2 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..5eb4414 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,16 +1513,23 @@ 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
follow_skip => 2, # ignore duplicates
+ no_chdir => 1, # don't chdir into every directory
dangling_symlinks => 0, # ignore dangling symlinks, silently
wanted => sub {
# skip project-list toplevel, if we get it.
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 (tr!/!! - $pfxdepth > $project_maxdepth) {
+ $File::Find::prune = 1;
+ return;
+ }
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
--
1.5.3.4
^ permalink raw reply related
* Re: git-cherry-pick no longer detecting moved files in 1.5.3.4
From: Shawn O. Pearce @ 2007-10-17 0:58 UTC (permalink / raw)
To: Richard Quirk; +Cc: git
In-Reply-To: <cac9e4380710161517m64ba737dj8711a6ce59b1b69@mail.gmail.com>
Richard Quirk <richard.quirk@gmail.com> wrote:
> (Also, minor thing this, but the docs for git-config
> says it is diff.renameLimit but diff.c uses diff.renamelimit.)
Someone else already responded about how to set this limit, but
I wanted to clarify what the docs vs. the code were doing here.
The docs use camelCase as it is prettier to read multiple words
that useCamelCase than alllowercaselikethis. Internally when we
parse your config file we lowercase the entire string so that the
code can worry only about the lowercase variant. That's why you
see it all lowercase in diff.c, but the docs suggest you to use
the camelCase format.
--
Shawn.
^ permalink raw reply
* Question on git-filter-branch
From: Bill Lear @ 2007-10-17 0:57 UTC (permalink / raw)
To: git
I'm testing out git-filter-branch, as I would like to use it to remove
proprietary information from our repository.
I created a test repo with "sensitive information" in a file 'A', some
other "plain" information, more sensitive stuff in file 'D', a subdirectory
of sensitive information (some of this added on a branch 'branch_1',
some added on master):
% ls -F sensitive
A B C D sensitive_stuff/
I then cloned this repo and tried the filter:
% git clone sensitive sensitive.clone
% cd sensitive.clone
% git filter-branch --index-filter 'git update-index --remove A' HEAD
Rewrite 5dd7d5f2d7d3a5f43c242188ac96294628267673 (7/7)
Ref 'refs/heads/master' was rewritten
These refs were rewritten:
% ls
A B C D sensitive_stuff
Ok, so it doesn't list the refs, so I do git status:
% git status
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# new file: A
#
So, it seems to have done something to A, but I don't know what to do
next.
The man page says: "Now, you will get the rewritten history saved in
the branch newbranch (your current branch is left untouched)." Well,
I don't see any new branch created:
% git branch -a
* master
origin/HEAD
origin/branch_1
origin/master
Then next part of the man page counsels that "To set a commit ...",
but I'm not sure if that is what I want to do (I think it is).
However, I'm not sure what the 'graft-id' refers to, or if I'm
supposed to type in the command as specified, especially since this is
followed by this caution: "if the parent string is empty - which
happens when we are dealing with the initial commit - add graftcommit
as a parent". Here, I'm unsure what graftcommit is, most especially
since the use of 'graft' first appears as 'graft-id'...
Could someone help, please?
Bill
^ permalink raw reply
* Re: [PATCH] When renaming config sections delete conflicting sections
From: Shawn O. Pearce @ 2007-10-17 0:55 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20071017003418.GA11013@diku.dk>
Jonas Fonseca <fonseca@diku.dk> wrote:
> The old behavior of keeping config sections matching the new name caused
> problems leading to warnings being emitted by git-remote when renaming
> branches where information about tracked remote branches differed. To
> fix this any config sections that will conflict with the new name are
> removed from the config file. Update test to check for this.
...
> This command sequence was causing problems for me:
>
> git checkout -b test madcoder/next
> git checkout -b test2 spearce/next
> git branch -M test
Ouch. But this may cause the user to lose what they might consider
important settings relative to the old section named branch.test.
I think in the case you mention above where you are doing a
`branch -M` the user really does want the basic branch properties
to be forced over (branch.$name.remote, branch.$name.merge) but
they probably do not want other branch properties to be removed
or deleted. Or maybe they do.
Its really hard to second guess the user's intent here. I think
its too broad to whack an entire section when renaming. For example
today lets say I do:
cat >.git/config <<EOF
[remote "many"]
url = blah
fetch = refs/heads/master
fetch = refs/heads/next
EOF
$ git config remote.many.fetch refs/heads/pu
Warning: remote.many.fetch has multiple values
cat .git/config
[remote "many"]
url = blah
fetch = refs/heads/master
fetch = refs/heads/next
So we don't blindly replace multi-valued keys just because the
user asked us to. I don't really see a section as being that much
different to warrant a potentially lossy behavior by default.
--
Shawn.
^ permalink raw reply
* Re: revised: [PATCH] Color support added to git-add--interactive.
From: Dan Zwell @ 2007-10-17 0:47 UTC (permalink / raw)
To: Jeff King
Cc: Wincent Colaiuta, Git Mailing List, Jonathan del Strother,
Johannes Schindelin, Frank Lichtenheld
In-Reply-To: <20071015034338.GA4844@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 4889 bytes --]
Adds color to the prompts and output of git-add--interactive.
-Reads config color.interactive, respects "auto", "true",
"always", and anything else.
-Uses the library Term::ANSIColor, which is included with modern
versions of perl. This is optional, and should not need to be
present if color.interactive is not on.
-Reads color.interactive.<slot>, where slot is "header", "prompt",
or "help", colorizing output accordingly.
Documentation/config.txt is updated to reflect the new keys.
I cannot test this or see how it looks in manpages, however,
as I cannot install the documentation build tools.
Unfortunately, I think the default colors are ugly, but all colors that
are readable on both black and white backgrounds are probably ugly.
This patch does not colorize the diffs, because that is a larger
job, and very distinct from this (simple) task.
Dan
gzipped patch is also attached, just in case.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 971fd9f..17e29e4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -381,6 +381,27 @@ color.diff.<slot>::
whitespace). The values of these variables may be specified as
in color.branch.<slot>.
+color.interactive::
+ When true (or `always`), always use colors in add--interactive.
+ When false (or `never`), never. When set to `auto`, use
+ colors only when the output is to the terminal. Defaults to
+ false.
+
+color.interactive.<slot>::
+ Use customized color for add--interactive output. `<slot>`
+ may be `prompt`, `header`, or `help`, for three distinct types
+ of common output from interactive programs. The values may be a
+ space-delimited combination of up to three of the following:
++
+(optional attribute, optional foreground color, and optional
background) ++
+dark, bold, underline, underscore, blink, reverse, concealed,
+black, red, green, yellow, blue, magenta, cyan, white, on_black,
+on_red, on_green, on_yellow, on_blue, on_magenta, on_cyan, on_white
++
+Note: these are not the same colors/attributes that the
+rest of git supports, but are specific to git-add--interactive.
+
color.pager::
A boolean to enable/disable colored output when the pager is in
use (default is true).
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index be68814..125655b 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -2,6 +2,33 @@
use strict;
+my ($use_color, $prompt_color, $header_color, $help_color);
+my $color_config = qx(git config --get color.interactive);
+if ($color_config=~/true|always/ || -t STDOUT &&
$color_config=~/auto/) {
+ $use_color = "true";
+ chomp( $prompt_color = qx(git config --get
color.interactive.prompt) );
+ chomp( $header_color = qx(git config --get
color.interactive.header) );
+ chomp( $help_color = qx(git config --get
color.interactive.help) );
+ $prompt_color ||= "red bold";
+ $header_color ||= "bold";
+ $help_color ||= "blue bold";
+
+ require Term::ANSIColor;
+}
+
+sub print_colored {
+ my $color = shift;
+ my @strings = @_;
+
+ if ($use_color) {
+ print Term::ANSIColor::color($color);
+ print(@strings);
+ print Term::ANSIColor::color("reset");
+ } else {
+ print @strings;
+ }
+}
+
sub run_cmd_pipe {
if ($^O eq 'MSWin32') {
my @invalid = grep {m/[":*]/} @_;
@@ -175,7 +202,7 @@ sub list_and_choose {
if (!$opts->{LIST_FLAT}) {
print " ";
}
- print "$opts->{HEADER}\n";
+ print_colored $header_color,
"$opts->{HEADER}\n"; }
for ($i = 0; $i < @stuff; $i++) {
my $chosen = $chosen[$i] ? '*' : ' ';
@@ -205,7 +232,7 @@ sub list_and_choose {
return if ($opts->{LIST_ONLY});
- print $opts->{PROMPT};
+ print_colored $prompt_color, $opts->{PROMPT};
if ($opts->{SINGLETON}) {
print "> ";
}
@@ -544,7 +571,7 @@ sub coalesce_overlapping_hunks {
}
sub help_patch_cmd {
- print <<\EOF ;
+ print_colored $help_color, <<\EOF ;
y - stage this hunk
n - do not stage this hunk
a - stage this and all the remaining hunks
@@ -619,7 +646,7 @@ sub patch_update_cmd {
for (@{$hunk[$ix]{TEXT}}) {
print;
}
- print "Stage this hunk [y/n/a/d$other/?]? ";
+ print_colored $prompt_color, "Stage this hunk
[y/n/a/d$other/?]? "; my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
@@ -673,7 +700,7 @@ sub patch_update_cmd {
elsif ($other =~ /s/ && $line =~ /^s/) {
my @split =
split_hunk($hunk[$ix]{TEXT}); if (1 < @split) {
- print "Split into ",
+ print_colored "$header_color",
"Split into ", scalar(@split), " hunks.\n";
}
splice(@hunk, $ix, 1,
@@ -769,7 +796,7 @@ sub quit_cmd {
}
sub help_cmd {
- print <<\EOF ;
+ print_colored $help_color, <<\EOF ;
status - show paths with changes
update - add working tree state to the staged set of changes
revert - revert staged set of changes back to the HEAD version
--
1.5.3.4.207.gc0ee
[-- Attachment #2: color-add--interactive.patch.gz --]
[-- Type: application/x-gzip, Size: 1749 bytes --]
^ permalink raw reply related
* Re: On Tabs and Spaces
From: Linus Torvalds @ 2007-10-17 0:45 UTC (permalink / raw)
To: Christer Weinigel; +Cc: Tom Tobin, git
In-Reply-To: <20071017015109.303760cc@localhost.localdomain>
On Wed, 17 Oct 2007, Christer Weinigel wrote:
>
> If you assume that everyone is sane and use a tab size of 8 you will
> get bitten, sooner or later. Or actually, you, Linus, who are lucky
> enough to work mostly with Linux source, you might personally not get
> bitten all that often. But us poor suckers that have to work with
> other people, often Windows programmers, we do.
One issue may well be that Windows programmers also probably don't work
very much with patches, do they?
One reason for *really* wanting to use hard-tabs is that it makes patches
look better, exactly because diffs contain that one extra (or two, in the
case of old-style context diffs) character at the beginning of the line.
Which means that while all-space indents look fine, *mixing* styles
definitely does not. In particular, a two-character indent (which
hopefully nobody uses, but people are crazy) will be totally unreadable as
a patch if you have the (fairly common, at least in UNIX projects) style
of using spaces for less-than-eight-character-indents and tabs for the
full 8 characters.
(In particular, a 3-level and 4-level indent will look *identical* in such
a project, when using context diffs).
And sure, you can use all-spaces-everywhere, but that just isn't what any
normal UNIX editors are set up for by default. In contrast, under UNIX, I
can pretty much guarantee that hard-tab indents look at least reasonable
in any editor.
And if you have an editor that shows hard-tabs as 4-character indents,
generally you can work with it. You may have odd indentation, and people
may complain about your patches not lining up, and yes, it would be up to
*you* to understand that 8-wide tabs are the normal and default. But you
can certainly work with a source base that uses a single hard-tab for
indentation.
In contrast, if you use spaces (or worse - mixing), things really look
ugly as sin, to the point of actually being unworkable.
In short:
- if the project has the rule that an indentation is "one hard-tab", then
at least everybody can *work* with that project. Different people may
see things laid out slightly differently, but it's generally not a
horrible disaster, especially if you aim to use block comments indented
with the code (like we *mostly* do both in the kernel and in git)
- all-space and all-tabs just leads to problems. Yes, I know about
python, but lets face it, python is different, since the spacing has
semantic rules there. Most non-python programmers will not use editors
where you can obviously see the difference between spaces and tabs, and
as a result an all-space model will *turn* into a mixed-space/tab
model, and you get horrible end results.
- as per above, mixing spaces and tabs is a *horrid* idea.
- as a result, a "pure tab for indents" model tends to be workable in
most situations. It may not be ideal for you, but it's workable.
- and at least in the UNIX world, default for pure tabs really is 8
characters. Even if you have an editor that shows them as four, you'll
see different results outside the editor (eg "grep -5 file.c"), so
people should just consider other tab sizes to be "secondary".
And as long as 99% of all git developers are under Linux, and all the
core ones seem to have had no problem with the current tab rules, I
really don't see why that should change.
See? Hard-tabs are good. Maybe Windows people don't ever see patches
(perhaps they only see them as side-by-side graphical things), and maybe
windows projects are always done inside *one* environment where there is
no "grep" and "terminal TAB size" and "fifty different editors with
different defaults".
But even in DOS/Windows, hard-tabs seem to be quite common, judging by
what little source code I've seen from Windows projects.
And I just checked. The current git model seems to work fine if you have
an editor that thinks tabs are 4 spaces:
sed 's/ / /g' < revision.c | less -S
(that's a hard-tab in that first regex). No, things don't necessarily line
up just like they should, but you actually have to *look* for problems to
see them (ie stuff where people have added line-breaks).
And is it really so unreasonable to just say "8-character tabs are the
gold standard"?
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: speed up project listing by limiting find depth
From: Shawn O. Pearce @ 2007-10-17 0:41 UTC (permalink / raw)
To: Luke Lu; +Cc: git, gitster, Petr Baudis
In-Reply-To: <1192580691-14308-1-git-send-email-git@vicaya.com>
Luke Lu <git@vicaya.com> wrote:
> diff --git a/Makefile b/Makefile
> index 8db4dbe..b70ba8c 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 = 2
I'd rather see this default to an unlimited (or maybe insane?) depth.
Current users may be surprised upon upgrading to a more recent git
when their gitweb stops showing projects because the default depth
is too small.
repo.or.cz is up at 3 deep, maybe 4 right now, right Pasky?
I think letting admins control the depth is a good idea, but its
a performance tuning thing and probably shouldn't break existing
setups.
> + # don't traverse too deep (Find is super slow on os x)
> + return if tr!/!! - $pfxdepth > $project_maxdepth && ($File::Find::prune = 1);
I don't do much gitweb hacking, but I usually don't like to find
code that mutates a value as an important side-effect in the middle
of a boolean condition that is used to determine if we are breaking
out of this function now, or falling through to do more work. yea
its more lines of code but I think it would be easier to grok if this
was a proper if {...}.
--
Shawn.
^ permalink raw reply
* [PATCH] When renaming config sections delete conflicting sections
From: Jonas Fonseca @ 2007-10-17 0:34 UTC (permalink / raw)
To: git, Shawn O. Pearce
The old behavior of keeping config sections matching the new name caused
problems leading to warnings being emitted by git-remote when renaming
branches where information about tracked remote branches differed. To
fix this any config sections that will conflict with the new name are
removed from the config file. Update test to check for this.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
config.c | 9 ++++++++-
t/t1300-repo-config.sh | 17 +++++++++++++++++
2 files changed, 25 insertions(+), 1 deletions(-)
This command sequence was causing problems for me:
git checkout -b test madcoder/next
git checkout -b test2 spearce/next
git branch -M test
On top of spearce/next ...
diff --git a/config.c b/config.c
index dc3148d..578849a 100644
--- a/config.c
+++ b/config.c
@@ -1013,6 +1013,14 @@ int git_config_rename_section(const char *old_name, const char *new_name)
; /* do nothing */
if (buf[i] == '[') {
/* it's a section */
+ remove = 0;
+ if (new_name != NULL
+ && section_name_match (&buf[i+1], new_name)) {
+ /* Remove any existing occurences of the
+ * new section. */
+ remove = 1;
+ continue;
+ }
if (section_name_match (&buf[i+1], old_name)) {
ret++;
if (new_name == NULL) {
@@ -1026,7 +1034,6 @@ int git_config_rename_section(const char *old_name, const char *new_name)
}
continue;
}
- remove = 0;
}
if (remove)
continue;
diff --git a/t/t1300-repo-config.sh b/t/t1300-repo-config.sh
index 1d2bf2c..63b969e 100755
--- a/t/t1300-repo-config.sh
+++ b/t/t1300-repo-config.sh
@@ -419,6 +419,23 @@ EOF
test_expect_success "section was removed properly" \
"git diff -u expect .git/config"
+cat > .git/config << EOF
+[branch "new-name"]
+ x = 1
+[branch "old-name"]
+ y = 1
+EOF
+
+test_expect_success "rename and remove old section" \
+ 'git config --rename-section branch.old-name branch.new-name'
+
+cat > expect << EOF
+[branch "new-name"]
+ y = 1
+EOF
+
+test_expect_success "rename and remove succeeded" "git diff expect .git/config"
+
rm .git/config
cat > expect << EOF
--
1.5.3.4.1206.g5f96-dirty
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] gitweb: Provide title attributes for abbreviated author names.
From: David Symonds @ 2007-10-17 0:34 UTC (permalink / raw)
To: pasky; +Cc: git, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
gitweb/gitweb.perl | 34 +++++++++++++++++++++++++++++-----
1 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b2bae1b..3112fd4 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -3461,9 +3461,15 @@ sub git_shortlog_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 10);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
# git_summary() used print "<td><i>$co{'age_string'}</i></td>\n" .
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 10)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>";
print format_subject_html($co{'title'}, $co{'title_short'},
href(action=>"commit", hash=>$commit), $ref);
@@ -3511,9 +3517,15 @@ sub git_history_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ # shortlog uses chop_str($co{'author_name'}, 10)
+ my $author = chop_str($co{'author_name'}, 15, 3);
+ if ($author ne $co{'author_name'}) {
+ "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- # shortlog uses chop_str($co{'author_name'}, 10)
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 3)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>";
# originally git_history used chop_str($co{'title'}, 50)
print format_subject_html($co{'title'}, $co{'title_short'},
@@ -3667,8 +3679,14 @@ sub git_search_grep_body {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 15, 5);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'}), -class => "list subject"},
esc_html(chop_str($co{'title'}, 50)) . "<br/>");
@@ -5181,8 +5199,14 @@ sub git_search {
print "<tr class=\"light\">\n";
}
$alternate ^= 1;
+ my $author = chop_str($co{'author_name'}, 15, 5);
+ if ($author ne $co{'author_name'}) {
+ $author = "<span title=\"$co{'author_name'}\">" . esc_html($author) . "</span>";
+ } else {
+ $author = esc_html($author);
+ }
print "<td title=\"$co{'age_string_age'}\"><i>$co{'age_string_date'}</i></td>\n" .
- "<td><i>" . esc_html(chop_str($co{'author_name'}, 15, 5)) . "</i></td>\n" .
+ "<td><i>" . $author . "</i></td>\n" .
"<td>" .
$cgi->a({-href => href(action=>"commit", hash=>$co{'id'}),
-class => "list subject"},
--
1.5.3.1
^ permalink raw reply related
* Re: Git User's Survey 2007 summary - git homepage improvements
From: david @ 2007-10-17 0:36 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Petr Baudis, Jan Hudec, Frank Lichtenheld, Jakub Narebski, git,
Jonas Fonseca
In-Reply-To: <20071017002648.GH13801@spearce.org>
On Tue, 16 Oct 2007, Shawn O. Pearce wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>> On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
>>> On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
>>>> On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
>>>>> Generic:
>>>>> # Dedicated domain name / site name, e.g. git.org or git.com
> ...
>>>> (And I guess something like git-scm.org wouldn't qualify as more
>>>> "official", would it?)
>>>
> ...
>> If someone trustworthy in the community has the resources to sponsor the
>> domain, I will only be happy and gladly set it up on my side (I can run
>> the nameservers myself too, if required). But I don't have the
>> resources for registering the domain myself, unfortunately.
>
> "git" is a three letter word. I don't think there have been *any*
> three letter .com/.org/.net domains available for years.
>
> I see that Jonas Fonseca registered git-scm.org today... I wonder
> what his plans are for that domain...
I've been useing the .hm domain for several years. some people who don't
know what it means read it as 'home'. I see that git.hm is not allocated.
David Lang
^ permalink raw reply
* [PATCH] gitweb: speed up project listing by limiting find depth
From: Luke Lu @ 2007-10-17 0:24 UTC (permalink / raw)
To: git; +Cc: gitster, Luke Lu
Resubmit patch to make project max depth configurable.
Signed-off-by: Luke Lu <git@vicaya.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 8 ++++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 8db4dbe..b70ba8c 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 = 2
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..1453101 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,16 +1513,20 @@ 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
follow_skip => 2, # ignore duplicates
+ no_chdir => 1, # don't chdir into every directory
dangling_symlinks => 0, # ignore dangling symlinks, silently
wanted => sub {
# skip project-list toplevel, if we get it.
return if (m!^[/.]$!);
# only directories can be git repositories
return unless (-d $_);
+ # don't traverse too deep (Find is super slow on os x)
+ return if tr!/!! - $pfxdepth > $project_maxdepth && ($File::Find::prune = 1);
my $subdir = substr($File::Find::name, $pfxlen + 1);
# we check related file in $projectroot
--
1.5.3.4
^ permalink raw reply related
* Re: Git User's Survey 2007 summary - git homepage improvements
From: Shawn O. Pearce @ 2007-10-17 0:26 UTC (permalink / raw)
To: Petr Baudis
Cc: Jan Hudec, Frank Lichtenheld, Jakub Narebski, git, Jonas Fonseca
In-Reply-To: <20071017000526.GG18279@machine.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Oct 16, 2007 at 10:12:47PM +0200, Jan Hudec wrote:
> > On Mon, Oct 15, 2007 at 00:56:18 +0200, Frank Lichtenheld wrote:
> > > On Mon, Oct 15, 2007 at 12:05:22AM +0200, Jakub Narebski wrote:
> > > > Generic:
> > > > # Dedicated domain name / site name, e.g. git.org or git.com
...
> > > (And I guess something like git-scm.org wouldn't qualify as more
> > > "official", would it?)
> >
...
> If someone trustworthy in the community has the resources to sponsor the
> domain, I will only be happy and gladly set it up on my side (I can run
> the nameservers myself too, if required). But I don't have the
> resources for registering the domain myself, unfortunately.
"git" is a three letter word. I don't think there have been *any*
three letter .com/.org/.net domains available for years.
I see that Jonas Fonseca registered git-scm.org today... I wonder
what his plans are for that domain...
--
Shawn.
^ permalink raw reply
* Re: What's in git/spearce.git (stable)
From: Shawn O. Pearce @ 2007-10-17 0:09 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git
In-Reply-To: <200710162228.12680.barra_cuda@katamail.com>
Michele Ballabio <barra_cuda@katamail.com> wrote:
> On Tuesday 16 October 2007, Shawn O. Pearce wrote:
> > * The 'maint' branch has these fixes since the last announcement.
>
> There are typos in RelNotes-1.5.3.5.txt:
>
> s/wilh/will
> s/Documention/Documentation
Gah. That'll teach me to not spellcheck a documentation file before
pushing it. :-)
Thanks for catching it.
--
Shawn.
^ 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