* Re: [PATCH] Make git-fmt-merge-msg a builtin
From: Timo Hirvonen @ 2006-07-03 14:17 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607031530380.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> +struct list {
> + char **list;
> + void **payload;
> + unsigned nr, alloc;
> +};
How about something like this instead to reduce mallocs to half and
simplify the code?
struct item {
char *value;
void *payload;
};
struct list {
struct item *items;
unsigned int nr, alloc;
};
(But I realize this isn't performance critical)
> +static void append_to_list(struct list *list, char *value)
Add void *payload parameter too, would simplify the code.
> +static void free_list(struct list *list)
> +{
> + int i;
> +
> + if (list->alloc == 0)
> + return;
Unnecessary if nr is 0 too.
> + for (i = 0; i < list->nr; i++) {
> + free(list->list[i]);
> + if (list->payload[i])
> + free(list->payload[i]);
free(NULL) is safe.
> + }
> + free(list->list);
> + free(list->payload);
> + list->nr = list->alloc = 0;
> +}
> + if (!strncmp(line, "branch ", 7)) {
> + origin = strdup(line + 7);
> + append_to_list(&(src_data->branch), origin);
Parenthesis isn't needed.
> + head->object.flags |= UNINTERESTING;
> + prepare_revision_walk(rev);
Spaces..
> + if (merge_summary) {
> + struct commit *head;
> + struct rev_info rev;
> +
> + head = lookup_commit(head_sha1);
> +parse_object(head->object.sha1);
> +head = head->parents->item;
Indentation.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: Compression speed for large files
From: Nicolas Pitre @ 2006-07-03 14:33 UTC (permalink / raw)
To: Joachim Berdal Haga; +Cc: Alex Riesen, git
In-Reply-To: <44A91C7A.6090902@fys.uio.no>
On Mon, 3 Jul 2006, Joachim Berdal Haga wrote:
> Alex Riesen wrote:
> > On 7/3/06, Joachim B Haga <cjhaga@fys.uio.no> wrote:
> > > So: is it a good idea to change to faster compression, at least for larger
> > > files? From my (limited) testing I would suggest using Z_BEST_COMPRESSION
> > > only for small files (perhaps <1MB?) and
> > > Z_DEFAULT_COMPRESSION/Z_BEST_SPEED for
> > > larger ones.
> >
> > Probably yes, as a per-repo config option.
>
> I can send a patch later. If it's to be a per-repo option, it's probably too
> confusing with several values. Is it ok with
>
> core.compression = [-1..9]
>
> where the numbers are the zlib/gzip constants,
> -1 = zlib default (currently 6)
> 0 = no compression
> 1..9 = various speed/size tradeoffs (9 is git default)
I think this makes a lot of sense, although IMHO I'd simply use
Z_DEFAULT_COMPRESSION everywhere and be done with it without extra
complexity which aren't worth the size difference.
Nicolas
^ permalink raw reply
* Re: [PATCH] Make git-fmt-merge-msg a builtin
From: Johannes Schindelin @ 2006-07-03 14:36 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git, junkio
In-Reply-To: <20060703171751.2ed33220.tihirvon@gmail.com>
Hi,
On Mon, 3 Jul 2006, Timo Hirvonen wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > +struct list {
> > + char **list;
> > + void **payload;
> > + unsigned nr, alloc;
> > +};
>
> How about something like this instead to reduce mallocs to half and
> simplify the code?
>
> struct item {
> char *value;
> void *payload;
> };
>
> struct list {
> struct item *items;
> unsigned int nr, alloc;
> };
>
> (But I realize this isn't performance critical)
I had in mind that I want to use path-list instead (which is cooking in
the merge-recursive efforts ATM). And there, I would add a flag
needs_payload. Opinions?
> > +static void append_to_list(struct list *list, char *value)
>
> Add void *payload parameter too, would simplify the code.
Okay.
> > +static void free_list(struct list *list)
> > +{
> > + int i;
> > +
> > + if (list->alloc == 0)
> > + return;
>
> Unnecessary if nr is 0 too.
No. If nr == 0, alloc need not be 0, and if it is not, list and payload
are still allocated.
> > + for (i = 0; i < list->nr; i++) {
> > + free(list->list[i]);
> > + if (list->payload[i])
> > + free(list->payload[i]);
>
> free(NULL) is safe.
Is it? I vaguely remember that I had problems with this on some obscure
platform.
> > + if (!strncmp(line, "branch ", 7)) {
> > + origin = strdup(line + 7);
> > + append_to_list(&(src_data->branch), origin);
>
> Parenthesis isn't needed.
Okay. Wanted to be on the safe side.
> > + head->object.flags |= UNINTERESTING;
> > + prepare_revision_walk(rev);
>
> Spaces..
True. Will fix.
> > + if (merge_summary) {
> > + struct commit *head;
> > + struct rev_info rev;
> > +
> > + head = lookup_commit(head_sha1);
> > +parse_object(head->object.sha1);
> > +head = head->parents->item;
>
> Indentation.
No. Bug. This was a leftover from my tests (with this, the summary is not
done versus HEAD, but HEAD^).
Will fix and resubmit.
Ciao,
Dscho
^ permalink raw reply
* Re: Compression speed for large files
From: Yakov Lerner @ 2006-07-03 14:54 UTC (permalink / raw)
Cc: git
In-Reply-To: <Pine.LNX.4.64.0607031030150.1213@localhost.localdomain>
On 7/3/06, Nicolas Pitre <nico@cam.org> wrote:
> On Mon, 3 Jul 2006, Joachim Berdal Haga wrote:
>
> > Alex Riesen wrote:
> > > On 7/3/06, Joachim B Haga <cjhaga@fys.uio.no> wrote:
> > > > So: is it a good idea to change to faster compression, at least for larger
> > > > files? From my (limited) testing I would suggest using Z_BEST_COMPRESSION
> > > > only for small files (perhaps <1MB?) and
> > > > Z_DEFAULT_COMPRESSION/Z_BEST_SPEED for
> > > > larger ones.
> > >
> > > Probably yes, as a per-repo config option.
> >
> > I can send a patch later. If it's to be a per-repo option, it's probably too
> > confusing with several values. Is it ok with
> >
> > core.compression = [-1..9]
> >
> > where the numbers are the zlib/gzip constants,
> > -1 = zlib default (currently 6)
> > 0 = no compression
> > 1..9 = various speed/size tradeoffs (9 is git default)
It would be arguable whether, say, 10% better compression is worth
x(3-8) slower compression. But 3-4% better compression at the cost of
x(3-8) slower compression time as data suggest ? I think this begs
for switching the default to Z_DEFAULT_COMPRESSION
Yakov
^ permalink raw reply
* Re: Compression speed for large files
From: Johannes Schindelin @ 2006-07-03 15:17 UTC (permalink / raw)
To: Yakov Lerner; +Cc: git
In-Reply-To: <f36b08ee0607030754k4d10548pfb71dc62c6ee0b21@mail.gmail.com>
Hi,
On Mon, 3 Jul 2006, Yakov Lerner wrote:
> It would be arguable whether, say, 10% better compression is worth
> x(3-8) slower compression. But 3-4% better compression at the cost of
> x(3-8) slower compression time as data suggest ? I think this begs for
> switching the default to Z_DEFAULT_COMPRESSION
The real problem, of course, is that you cannot know before you tried, if
your data is really well compressible or not.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2nd try] Make git-fmt-merge-msg a builtin
From: Johannes Schindelin @ 2006-07-03 15:18 UTC (permalink / raw)
To: git, junio, Timo Hirvonen
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
This retires git-fmt-merge-msg.perl, since it passes all the
tests, but removes the Perl version not now. Did I mention it
is very, very, very fast? (Even compared to the Git.pm version;
measured on a cygwin setup.)
Makefile | 7 +
builtin-fmt-merge-msg.c | 355 +++++++++++++++++++++++++++++++++++++++++++++++
builtin.h | 1
git.c | 3
4 files changed, 362 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index c142bdd..a551c33 100644
--- a/Makefile
+++ b/Makefile
@@ -147,7 +147,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
- git-shortlog.perl git-fmt-merge-msg.perl git-rerere.perl \
+ git-shortlog.perl git-rerere.perl \
git-annotate.perl git-cvsserver.perl \
git-svnimport.perl git-mv.perl git-cvsexportcommit.perl \
git-send-email.perl
@@ -189,7 +189,8 @@ BUILT_INS = git-log$X git-whatchanged$X
git-ls-files$X git-ls-tree$X git-get-tar-commit-id$X \
git-read-tree$X git-commit-tree$X git-write-tree$X \
git-apply$X git-show-branch$X git-diff-files$X git-update-index$X \
- git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X
+ git-diff-index$X git-diff-stages$X git-diff-tree$X git-cat-file$X \
+ git-fmt-merge-msg$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -245,7 +246,7 @@ BUILTIN_OBJS = \
builtin-apply.o builtin-show-branch.o builtin-diff-files.o \
builtin-diff-index.o builtin-diff-stages.o builtin-diff-tree.o \
builtin-cat-file.o builtin-mailsplit.o builtin-stripspace.o \
- builtin-update-ref.o
+ builtin-update-ref.o builtin-fmt-merge-msg.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
EXTLIBS = -lz
diff --git a/builtin-fmt-merge-msg.c b/builtin-fmt-merge-msg.c
new file mode 100644
index 0000000..6527482
--- /dev/null
+++ b/builtin-fmt-merge-msg.c
@@ -0,0 +1,355 @@
+#include "cache.h"
+#include "commit.h"
+#include "diff.h"
+#include "revision.h"
+#include "tag.h"
+
+static const char *fmt_merge_msg_usage =
+ "git-fmt-merge-msg [--summary] [--no-summary] [--file <file>]";
+
+static int merge_summary = 0;
+
+static int fmt_merge_msg_config(const char *key, const char *value)
+{
+ if (!strcmp("merge.summary", key))
+ merge_summary = git_config_bool(key, value);
+ return 0;
+}
+
+struct list {
+ char **list;
+ void **payload;
+ unsigned nr, alloc;
+};
+
+static void append_to_list(struct list *list, char *value, void *payload)
+{
+ if (list->nr == list->alloc) {
+ list->alloc += 32;
+ list->list = realloc(list->list, sizeof(char *) * list->alloc);
+ list->payload = realloc(list->payload,
+ sizeof(char *) * list->alloc);
+ }
+ list->payload[list->nr] = payload;
+ list->list[list->nr++] = value;
+}
+
+static int find_in_list(struct list *list, char *value)
+{
+ int i;
+
+ for (i = 0; i < list->nr; i++)
+ if (!strcmp(list->list[i], value))
+ return i;
+
+ return -1;
+}
+
+static void free_list(struct list *list)
+{
+ int i;
+
+ if (list->alloc == 0)
+ return;
+
+ for (i = 0; i < list->nr; i++) {
+ free(list->list[i]);
+ if (list->payload[i])
+ free(list->payload[i]);
+ }
+ free(list->list);
+ free(list->payload);
+ list->nr = list->alloc = 0;
+}
+
+struct src_data {
+ struct list branch, tag, r_branch, generic;
+ int head_status;
+};
+
+static struct list srcs = { NULL, NULL, 0, 0};
+static struct list origins = { NULL, NULL, 0, 0};
+
+static int handle_line(char *line)
+{
+ int i, len = strlen(line);
+ unsigned char *sha1;
+ char *src, *origin;
+ struct src_data *src_data;
+
+ if (len < 43 || line[40] != '\t')
+ return 1;
+
+ if (!strncmp(line + 41, "not-for-merge", 13))
+ return 0;
+
+ if (line[41] != '\t')
+ return 2;
+
+ line[40] = 0;
+ sha1 = xmalloc(20);
+ i = get_sha1(line, sha1);
+ line[40] = '\t';
+ if (i)
+ return 3;
+
+ if (line[len - 1] == '\n')
+ line[len - 1] = 0;
+ line += 42;
+
+ src = strstr(line, " of ");
+ if (src) {
+ *src = 0;
+ src += 4;
+ } else
+ src = "HEAD";
+
+ i = find_in_list(&srcs, src);
+ if (i < 0) {
+ i = srcs.nr;
+ append_to_list(&srcs, strdup(src),
+ xcalloc(1, sizeof(struct src_data)));
+ }
+ src_data = srcs.payload[i];
+
+ if (!strncmp(line, "branch ", 7)) {
+ origin = strdup(line + 7);
+ append_to_list(&src_data->branch, origin, NULL);
+ src_data->head_status |= 2;
+ } else if (!strncmp(line, "tag ", 4)) {
+ origin = line;
+ append_to_list(&src_data->tag, strdup(origin + 4), NULL);
+ src_data->head_status |= 2;
+ } else if (!strncmp(line, "remote branch ", 14)) {
+ origin = strdup(line + 14);
+ append_to_list(&src_data->r_branch, origin, NULL);
+ src_data->head_status |= 2;
+ } else if (!strcmp(line, "HEAD")) {
+ origin = strdup(src);
+ src_data->head_status |= 1;
+ } else {
+ origin = strdup(src);
+ append_to_list(&src_data->generic, strdup(line), NULL);
+ src_data->head_status |= 2;
+ }
+
+ if (!strcmp(".", src) || !strcmp(src, origin)) {
+ int len = strlen(origin);
+ if (origin[0] == '\'' && origin[len - 1] == '\'') {
+ char *new_origin = malloc(len - 1);
+ memcpy(new_origin, origin + 1, len - 2);
+ new_origin[len - 1] = 0;
+ origin = new_origin;
+ } else
+ origin = strdup(origin);
+ } else {
+ char *new_origin = malloc(strlen(origin) + strlen(src) + 5);
+ sprintf(new_origin, "%s of %s", origin, src);
+ origin = new_origin;
+ }
+ append_to_list(&origins, origin, sha1);
+ return 0;
+}
+
+static void print_joined(const char *singular, const char *plural,
+ struct list *list)
+{
+ if (list->nr == 0)
+ return;
+ if (list->nr == 1) {
+ printf("%s%s", singular, list->list[0]);
+ } else {
+ int i;
+ printf("%s", plural);
+ for (i = 0; i < list->nr - 1; i++)
+ printf("%s%s", i > 0 ? ", " : "", list->list[i]);
+ printf(" and %s", list->list[list->nr - 1]);
+ }
+}
+
+static void shortlog(const char *name, unsigned char *sha1,
+ struct commit *head, struct rev_info *rev, int limit)
+{
+ int i, count = 0;
+ struct commit *commit;
+ struct object *branch;
+ struct list subjects = { NULL, NULL, 0, 0 };
+ int flags = UNINTERESTING | TREECHANGE | SEEN | SHOWN | ADDED;
+
+ branch = deref_tag(parse_object(sha1), sha1_to_hex(sha1), 40);
+ if (!branch || branch->type != TYPE_COMMIT)
+ return;
+
+ setup_revisions(0, NULL, rev, NULL);
+ rev->ignore_merges = 1;
+ add_pending_object(rev, branch, name);
+ add_pending_object(rev, &head->object, "^HEAD");
+ head->object.flags |= UNINTERESTING;
+ prepare_revision_walk(rev);
+ while ((commit = get_revision(rev)) != NULL) {
+ char *oneline, *bol, *eol;
+
+ /* ignore merges */
+ if (commit->parents && commit->parents->next)
+ continue;
+
+ count++;
+ if (subjects.nr > limit)
+ continue;
+
+ bol = strstr(commit->buffer, "\n\n");
+ if (!bol) {
+ append_to_list(&subjects, strdup(sha1_to_hex(
+ commit->object.sha1)),
+ NULL);
+ continue;
+ }
+
+ bol += 2;
+ eol = strchr(bol, '\n');
+
+ if (eol) {
+ int len = eol - bol;
+ oneline = malloc(len + 1);
+ memcpy(oneline, bol, len);
+ oneline[len] = 0;
+ } else
+ oneline = strdup(bol);
+ append_to_list(&subjects, oneline, NULL);
+ }
+
+ if (count > limit)
+ printf("\n* %s: (%d commits)\n", name, count);
+ else
+ printf("\n* %s:\n", name);
+
+ for (i = 0; i < subjects.nr; i++)
+ if (i >= limit)
+ printf(" ...\n");
+ else
+ printf(" %s\n", subjects.list[i]);
+
+ clear_commit_marks((struct commit *)branch, flags);
+ clear_commit_marks(head, flags);
+ free_commit_list(rev->commits);
+ rev->commits = NULL;
+ rev->pending.nr = 0;
+
+ free_list(&subjects);
+}
+
+int cmd_fmt_merge_msg(int argc, char **argv, char **envp)
+{
+ int limit = 20, i = 0;
+ char line[1024];
+ FILE *in = stdin;
+ const char *sep = "";
+ unsigned char head_sha1[20];
+ const char *head, *current_branch;
+
+ git_config(fmt_merge_msg_config);
+
+ while (argc > 1) {
+ if (!strcmp(argv[1], "--summary"))
+ merge_summary = 1;
+ else if (!strcmp(argv[1], "--no-summary"))
+ merge_summary = 0;
+ else if (!strcmp(argv[1], "-F") || !strcmp(argv[1], "--file")) {
+ if (argc < 2)
+ die ("Which file?");
+ if (!strcmp(argv[2], "-"))
+ in = stdin;
+ else {
+ fclose(in);
+ in = fopen(argv[2], "r");
+ }
+ argc--; argv++;
+ } else
+ break;
+ argc--; argv++;
+ }
+
+ if (argc > 1)
+ usage(fmt_merge_msg_usage);
+
+ /* get current branch */
+ head = strdup(git_path("HEAD"));
+ current_branch = resolve_ref(head, head_sha1, 1);
+ current_branch += strlen(head) - 4;
+ free((char *)head);
+ if (!strncmp(current_branch, "refs/heads/", 11))
+ current_branch += 11;
+
+ while (fgets(line, sizeof(line), in)) {
+ i++;
+ if (line[0] == 0)
+ continue;
+ if (handle_line(line))
+ die ("Error in line %d: %s", i, line);
+ }
+
+ printf("Merge ");
+ for (i = 0; i < srcs.nr; i++) {
+ struct src_data *src_data = srcs.payload[i];
+ const char *subsep = "";
+
+ printf(sep);
+ sep = "; ";
+
+ if (src_data->head_status == 1) {
+ printf(srcs.list[i]);
+ continue;
+ }
+ if (src_data->head_status == 3) {
+ subsep = ", ";
+ printf("HEAD");
+ }
+ if (src_data->branch.nr) {
+ printf(subsep);
+ subsep = ", ";
+ print_joined("branch ", "branches ", &src_data->branch);
+ }
+ if (src_data->r_branch.nr) {
+ printf(subsep);
+ subsep = ", ";
+ print_joined("remote branch ", "remote branches ",
+ &src_data->r_branch);
+ }
+ if (src_data->tag.nr) {
+ printf(subsep);
+ subsep = ", ";
+ print_joined("tag ", "tags ", &src_data->tag);
+ }
+ if (src_data->generic.nr) {
+ printf(subsep);
+ print_joined("commit ", "commits ", &src_data->generic);
+ }
+ if (strcmp(".", srcs.list[i]))
+ printf(" of %s", srcs.list[i]);
+ }
+
+ if (!strcmp("master", current_branch))
+ putchar('\n');
+ else
+ printf(" into %s\n", current_branch);
+
+ if (merge_summary) {
+ struct commit *head;
+ struct rev_info rev;
+
+ head = lookup_commit(head_sha1);
+ init_revisions(&rev);
+ rev.commit_format = CMIT_FMT_ONELINE;
+ rev.ignore_merges = 1;
+ rev.limited = 1;
+
+ for (i = 0; i < origins.nr; i++)
+ shortlog(origins.list[i], origins.payload[i],
+ head, &rev, limit);
+ }
+
+ /* No cleanup yet; is standalone anyway */
+
+ return 0;
+}
+
diff --git a/builtin.h b/builtin.h
old mode 100644
new mode 100755
index f12d5e6..d9e5483
--- a/builtin.h
+++ b/builtin.h
@@ -49,6 +49,7 @@ extern int cmd_cat_file(int argc, const
extern int cmd_rev_parse(int argc, const char **argv, char **envp);
extern int cmd_update_index(int argc, const char **argv, char **envp);
extern int cmd_update_ref(int argc, const char **argv, char **envp);
+extern int cmd_fmt_merge_msg(int argc, const char **argv, char **envp);
extern int cmd_write_tree(int argc, const char **argv, char **envp);
extern int write_tree(unsigned char *sha1, int missing_ok, const char *prefix);
diff --git a/git.c b/git.c
index 512fa63..7cc826b 100644
--- a/git.c
+++ b/git.c
@@ -200,7 +200,8 @@ static void handle_internal_command(int
{ "mailinfo", cmd_mailinfo },
{ "stripspace", cmd_stripspace },
{ "update-index", cmd_update_index },
- { "update-ref", cmd_update_ref }
+ { "update-ref", cmd_update_ref },
+ { "fmt-merge-msg", cmd_fmt_merge_msg }
};
int i;
--
1.4.1.gb2dcd-dirty
^ permalink raw reply related
* Re: [PATCH] Make git-fmt-merge-msg a builtin
From: Timo Hirvonen @ 2006-07-03 15:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607031632290.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I had in mind that I want to use path-list instead (which is cooking in
> the merge-recursive efforts ATM). And there, I would add a flag
> needs_payload. Opinions?
This code is so simple that making the path_list more complex
(needs_payload special case?) is not worth it. I have not looked at the
code very closely though and have no idea what I'm talking about :)
> > > +static void free_list(struct list *list)
> > > +{
> > > + int i;
> > > +
> > > + if (list->alloc == 0)
> > > + return;
> >
> > Unnecessary if nr is 0 too.
>
> No. If nr == 0, alloc need not be 0, and if it is not, list and payload
> are still allocated.
If alloc is 0 then nr is 0 too (at least it _should_ be). The code would
effectively become:
for (i = 0; i < 0; i++) {
...
}
free(NULL);
free(NULL);
list->nr = list->alloc = 0;
But this is not important...
> > free(NULL) is safe.
>
> Is it? I vaguely remember that I had problems with this on some obscure
> platform.
I don't think so.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH] Make git-fmt-merge-msg a builtin
From: Johannes Schindelin @ 2006-07-03 15:45 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git, junkio
In-Reply-To: <20060703182621.dbed5b5f.tihirvon@gmail.com>
Hi,
On Mon, 3 Jul 2006, Timo Hirvonen wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I had in mind that I want to use path-list instead (which is cooking in
> > the merge-recursive efforts ATM). And there, I would add a flag
> > needs_payload. Opinions?
>
> This code is so simple that making the path_list more complex
> (needs_payload special case?) is not worth it. I have not looked at the
> code very closely though and have no idea what I'm talking about :)
Okay. But I'd rather go back to work on merge-recursive, and just reuse
the path_list struct.
> > > free(NULL) is safe.
> >
> > Is it? I vaguely remember that I had problems with this on some obscure
> > platform.
>
> I don't think so.
Well, after a little Googling, I am more convinced than ever that it is a
BAD thing to rely on free(NULL) being a NOP.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/4] merge-recursive in C
From: Timo Hirvonen @ 2006-07-03 15:46 UTC (permalink / raw)
To: fork0; +Cc: git, Johannes.Schindelin, junkio
In-Reply-To: <20060630002721.GA22618@steel.home>
fork0@t-online.de (Alex Riesen) wrote:
> +/* in place */
> +void path_list_union_update(struct path_list *dst, const struct path_list *src)
> +{
> + char **new_paths;
> + int i = 0, j = 0, nr = 0, alloc = dst->nr + dst->nr;
It should be alloc = dst->nr + src->nr.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: [PATCH 1/4] merge-recursive in C
From: Johannes Schindelin @ 2006-07-03 15:54 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060703184604.59801e4e.tihirvon@gmail.com>
Hi,
On Mon, 3 Jul 2006, Timo Hirvonen wrote:
> fork0@t-online.de (Alex Riesen) wrote:
>
> > +/* in place */
> > +void path_list_union_update(struct path_list *dst, const struct path_list *src)
> > +{
> > + char **new_paths;
> > + int i = 0, j = 0, nr = 0, alloc = dst->nr + dst->nr;
>
> It should be alloc = dst->nr + src->nr.
Good catch. Merci.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git-fmt-merge-msg a builtin
From: Timo Hirvonen @ 2006-07-03 16:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607031731550.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > > free(NULL) is safe.
> > >
> > > Is it? I vaguely remember that I had problems with this on some obscure
> > > platform.
> >
> > I don't think so.
>
> Well, after a little Googling, I am more convinced than ever that it is a
> BAD thing to rely on free(NULL) being a NOP.
I did some research too. Seems that C89 requires free(NULL) to be a
no-op but on some old systems (SunOS) it may crash. IMNSHO these
systems were designed to crash valid programs and torture developers.
There are probably many free(NULL) and realloc(NULL, ...) uses in the
git source code and are not worth fixing.
--
http://onion.dynserv.net/~timo/
^ permalink raw reply
* Re: Compression speed for large files
From: Linus Torvalds @ 2006-07-03 16:31 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Joachim Berdal Haga, Alex Riesen, git
In-Reply-To: <Pine.LNX.4.64.0607031030150.1213@localhost.localdomain>
On Mon, 3 Jul 2006, Nicolas Pitre wrote:
> On Mon, 3 Jul 2006, Joachim Berdal Haga wrote:
> >
> > I can send a patch later. If it's to be a per-repo option, it's probably too
> > confusing with several values. Is it ok with
> >
> > core.compression = [-1..9]
> >
> > where the numbers are the zlib/gzip constants,
> > -1 = zlib default (currently 6)
> > 0 = no compression
> > 1..9 = various speed/size tradeoffs (9 is git default)
>
> I think this makes a lot of sense, although IMHO I'd simply use
> Z_DEFAULT_COMPRESSION everywhere and be done with it without extra
> complexity which aren't worth the size difference.
I think Z_DEFAULT_COMPRESSION is fine too - we've long since started
relying on pack-files and the delta compression for the _real_ size
improvements, and as such, the zlib compression is less important.
That said, the "core.compression" thing sounds good to me, and gives
people the ability to tune things for their loads.
Linus
^ permalink raw reply
* Re: [PATCH 3/3] Make clear_commit_marks() clean harder
From: Linus Torvalds @ 2006-07-03 17:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Rene Scharfe, git
In-Reply-To: <Pine.LNX.4.63.0607031553570.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, 3 Jul 2006, Johannes Schindelin wrote:
>
> On Mon, 3 Jul 2006, Junio C Hamano wrote:
>
> > Rene Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> >
> > > Don't care if objects have been parsed or not and don't stop when we
> > > reach a commit that is already clean -- its parents could be dirty.
> >
> > There is something quite wrong with this patch.
>
> I always had the feeling that it was wrong to traverse not-yet-parsed
> parents: How could a revision walk possibly come to a certain commit
> without at least one continuous history of now-parsed objects?
No, that's not the problem.
The problem is that if we unconditionally traverse parents - whether
parsed or not - any merge will basically result in a 2* expansion of the
working set: we'll traverse all children twice (whether they meet again or
not).
So the cost of doign unconditional traversals of parents basically
approaches 2^n, where 'n' is the number of merges.
Now, the fact that we only traverse parents without adding new ones (and
the decision on whether it is parsed or not is irrelevant - the only
relevant part being that we don't parse any _new_ ones) means that each
commit itself is very cheap to traverse, but O(2^n) ends up meaning that
even a small constant will eventually be pretty big.
The proper fix is _not_ to add the "object->parsed" check (which is silly,
wrong, and doesn't fix anything at all), but to add a check for whether
the object has been seen or not.
In the case of clearing flags, you have two choices:
- _set_ a new flag ("already cleared"). This would work - once - but is
obviously pretty bad.
This is what we do in all the other cases. We usually call the flag
SEEN or similar.
- depend on the flags being "dense", and saying that we depend on the
fact that in order for any of the flags to have been set in the first
place, at least _one_ of them needs to be set in the path leading up to
that commit.
Now, for the specific case of get_merge_bases(), the flags _are_ dense.
Individual flags may not be (eg the "UNINTERESTING" flag, whatever it's
called, will not be dense), but the question of "is _any_ of the flags we
care about set" _will_ be dense.
As such, adding a
/* Have we already cleared this? */
if (!(mask & object->flags))
return;
object->flags &= ~mask;
to the traversal function will fix the O(m+2^n) behaviour, and turn the
traversal into O(m+n) (where "n" is the number of merges, and "m" is the
total number of commits).
Linus
^ permalink raw reply
* [PATCH] Make zlib compression level configurable, and change default.
From: Joachim B Haga @ 2006-07-03 18:59 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre, Linus Torvalds, Alex Riesen, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0607030929490.12404@g5.osdl.org>
Make zlib compression level configurable, and change the default.
With the change in default, "git add ." on kernel dir is about
twice as fast as before, with only minimal (0.5%) change in
object size. The speed difference is even more noticeable
when committing large files, which is now up to 8 times faster.
The configurability is through setting core.compression = [-1..9]
which maps to the zlib constants; -1 is the default, 0 is no
compression, and 1..9 are various speed/size tradeoffs, 9
being slowest.
Signed-off-by: Joachim B Haga (cjhaga@fys.uio.no)
---
Documentation/config.txt | 6 ++++++
cache.h | 1 +
config.c | 5 +++++
environment.c | 1 +
sha1_file.c | 4 ++--
5 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a04c5ad..ac89be7 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -91,6 +91,12 @@ core.warnAmbiguousRefs::
If true, git will warn you if the ref name you passed it is ambiguous
and might match multiple refs in the .git/refs/ tree. True by default.
+core.compression:
+ An integer -1..9, indicating the compression level for objects that
+ are not in a pack file. -1 is the zlib and git default. 0 means no
+ compression, and 1..9 are various speed/size tradeoffs, 9 being
+ slowest.
+
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
diff --git a/cache.h b/cache.h
index 8719939..84770bf 100644
--- a/cache.h
+++ b/cache.h
@@ -183,6 +183,7 @@ extern int log_all_ref_updates;
extern int warn_ambiguous_refs;
extern int shared_repository;
extern const char *apply_default_whitespace;
+extern int zlib_compression_level;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/config.c b/config.c
index ec44827..61563be 100644
--- a/config.c
+++ b/config.c
@@ -279,6 +279,11 @@ int git_default_config(const char *var,
return 0;
}
+ if (!strcmp(var, "core.compression")) {
+ zlib_compression_level = git_config_int(var, value);
+ return 0;
+ }
+
if (!strcmp(var, "user.name")) {
strlcpy(git_default_name, value, sizeof(git_default_name));
return 0;
diff --git a/environment.c b/environment.c
index 3de8eb3..1d8ceef 100644
--- a/environment.c
+++ b/environment.c
@@ -20,6 +20,7 @@ int repository_format_version = 0;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
int shared_repository = PERM_UMASK;
const char *apply_default_whitespace = NULL;
+int zlib_compression_level = -1;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
diff --git a/sha1_file.c b/sha1_file.c
index 8179630..bc35808 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1458,7 +1458,7 @@ int write_sha1_file(void *buf, unsigned
/* Set it up */
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_BEST_COMPRESSION);
+ deflateInit(&stream, zlib_compression_level);
size = deflateBound(&stream, len+hdrlen);
compressed = xmalloc(size);
@@ -1511,7 +1511,7 @@ static void *repack_object(const unsigne
/* Set it up */
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_BEST_COMPRESSION);
+ deflateInit(&stream, zlib_compression_level);
size = deflateBound(&stream, len + hdrlen);
buf = xmalloc(size);
--
1.4.1.g8fced-dirty
^ permalink raw reply related
* [PATCH] Use configurable zlib compression level everywhere.
From: Joachim B Haga @ 2006-07-03 19:02 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre, Linus Torvalds, Alex Riesen, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0607030929490.12404@g5.osdl.org>
This one I'm not so sure about, it's for completeness. But I don't actually use
git and haven't tested beyond the git add / git commit stage. Still...
Signed-off-by: Joachim B Haga (cjhaga@fys.uio.no)
---
csum-file.c | 2 +-
diff.c | 2 +-
http-push.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/csum-file.c b/csum-file.c
index ebaad03..6a7b40f 100644
--- a/csum-file.c
+++ b/csum-file.c
@@ -122,7 +122,7 @@ int sha1write_compressed(struct sha1file
void *out;
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_DEFAULT_COMPRESSION);
+ deflateInit(&stream, zlib_compression_level);
maxsize = deflateBound(&stream, size);
out = xmalloc(maxsize);
diff --git a/diff.c b/diff.c
index 5a71489..428ff78 100644
--- a/diff.c
+++ b/diff.c
@@ -583,7 +583,7 @@ static unsigned char *deflate_it(char *d
z_stream stream;
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_BEST_COMPRESSION);
+ deflateInit(&stream, zlib_compression_level);
bound = deflateBound(&stream, size);
deflated = xmalloc(bound);
stream.next_out = deflated;
diff --git a/http-push.c b/http-push.c
index e281f70..f761584 100644
--- a/http-push.c
+++ b/http-push.c
@@ -492,7 +492,7 @@ static void start_put(struct transfer_re
/* Set it up */
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_BEST_COMPRESSION);
+ deflateInit(&stream, zlib_compression_level);
size = deflateBound(&stream, len + hdrlen);
request->buffer.buffer = xmalloc(size);
--
1.4.1.g8fced-dirty
^ permalink raw reply related
* Re: [PATCH] Make zlib compression level configurable, and change default.
From: Linus Torvalds @ 2006-07-03 19:33 UTC (permalink / raw)
To: Joachim B Haga
Cc: Nicolas Pitre, Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <85d5cm8qfn.fsf_-_@lupus.ig3.net>
On Mon, 3 Jul 2006, Joachim B Haga wrote:
>
> The configurability is through setting core.compression = [-1..9]
> which maps to the zlib constants; -1 is the default, 0 is no
> compression, and 1..9 are various speed/size tradeoffs, 9
> being slowest.
My only worry is that this encodes "Z_DEFAULT_COMPRESSION" as being -1,
which happens to be /true/, but I don't think that's a documented
interface (you're supposed to use the Z_DEFAULT_COMPRESSION macro, which
could have any value, and just _happens_ to be -1).
Is it likely to ever change from that -1? Probably not. So I think your
patch is technically correct, but it might just be nicer if it did
something like
..
if (!strcmp(var, "core.compression")) {
int level = git_config_int(var, value);
if (level == -1)
level = Z_DEFAULT_COMPRESSION;
else if (level < 0 || level > Z_BEST_COMPRESSION)
die("bad zlib compression level %d", level);
zlib_compression_level = level;
return 0;
}
..
which would be safer, and a smart compiler might notice that the -1 case
ends up being a no-op, and then just generate code AS IF we just had a
if (level < -1 || level > Z_BEST_COMPRESSION)
die(...
there.
Oh, and for all the same reasons, we should use
int zlib_compression_level = Z_BEST_COMPRESSION;
for the default initializer.
Hmm?
Linus
^ permalink raw reply
* Re: [PATCH] Use configurable zlib compression level everywhere.
From: Junio C Hamano @ 2006-07-03 19:43 UTC (permalink / raw)
To: Joachim B Haga; +Cc: git
In-Reply-To: <8564ie8qbe.fsf_-_@lupus.ig3.net>
Joachim B Haga <cjhaga@fys.uio.no> writes:
> This one I'm not so sure about, it's for completeness. But I don't actually use
> git and haven't tested beyond the git add / git commit stage. Still...
>
> Signed-off-by: Joachim B Haga (cjhaga@fys.uio.no)
You made a good judgement to notice that these three are
different.
* sha1write_compressed() in csum-file.c is for producing packs
and most of the things we compress there are deltas and less
compressible, so even when core.compression is set to high we
might be better off using faster compression.
* diff's deflate_it() is about producing binary diffs (later
encoded in base85) for textual transfer. Again it is almost
always used to compress deltas so the same comment as above
apply to this.
* http-push uses it to send compressed whole object, and this
is only used over the network, so it is plausible that the
user would want to use different compression level than the
usual core.compression.
It is fine by me to use the same core.compression to these
three. If somebody comes up with a workload that benefits from
having different settings for them, we can add separate
variables, falling back on the default core.compression if there
isn't one, as needed.
Thanks for the patches.
^ permalink raw reply
* Re: [PATCH 3/3] Make clear_commit_marks() clean harder
From: Junio C Hamano @ 2006-07-03 19:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607031553570.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> > Don't care if objects have been parsed or not and don't stop when we
>> > reach a commit that is already clean -- its parents could be dirty.
>>
>> There is something quite wrong with this patch.
>
> I always had the feeling that it was wrong to traverse not-yet-parsed
> parents: How could a revision walk possibly come to a certain commit
> without at least one continuous history of now-parsed objects?
>
> Also, AFAIK the revision walk sets flags for each commit it touched, and
> we should not try to be smart-asses about the flags, but just unset these
> flags.
The main points were made by Linus already.
Traversing is not needed -- not clearing not-yet-parsed is
obviously wrong.
> BTW some very quick tests showed that the clear_commit_marks() thing that
> I sent to the list was much faster than traversing all objects (which was
> in my original version).
I have a crude workaround pushed out last night but will be
replacing it with something less drastic. I think the final
version should be what you had, perhaps minus not looking at the
parsed flag for unmarking purposes.
^ permalink raw reply
* Re: [PATCH] Make zlib compression level configurable, and change default.
From: Linus Torvalds @ 2006-07-03 19:50 UTC (permalink / raw)
To: Joachim B Haga
Cc: Nicolas Pitre, Alex Riesen, Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0607031226370.12404@g5.osdl.org>
On Mon, 3 Jul 2006, Linus Torvalds wrote:
>
> Oh, and for all the same reasons, we should use
>
> int zlib_compression_level = Z_BEST_COMPRESSION;
That should be Z_DEFAULT_COMPRESSION, of course.
Anyway, I think the patches are ok as-is, and my suggestion to avoid the
"-1" and use Z_DEFAULT_COMPRESSION is really just an additional comment,
not anything fundamental.
So Junio, feel free to add an
Acked-by: Linus Torvalds <torvalds@osdl.org>
regardless of whether also doing that.
Linus
^ permalink raw reply
* Re: qgit idea: interface for cherry-picking
From: Junio C Hamano @ 2006-07-03 20:03 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <e5bfff550607030418n6a46c0cdh1a95155e1feb4356@mail.gmail.com>
"Marco Costalba" <mcostalba@gmail.com> writes:
> I cannot test your patch now, so I'm just guessing, what if we have a
> series of patches?
The patch stops at each patch. I am primarily interested in
keeping "git-am" usable from command line while making it easy
to use from other tools.
The expected use for the patch you are responding to is that
after the first application with --fail the user has an
opportunity to fix the result up but needs to create a commit by
rerunning "git-am" (or just drop that by resetting the index and
saying "git-am --skip").
> Is it possible that for two patches A and B happens that
>
> git-am A
> git-am B
> git-reset --soft HEAD^^
>
> gives a different result then
>
> git-am --fail A
> git-am --fail B
If you had a series of patches chosen inside your GUI and
squash-apply them all, two full am with soft reset to the
original state would be the easiest, if and only if both patch
applications do not fail. If patch A does not apply for
whatever reason, you have to guide your user through the patch
adjustment process before applying B, regardless of the reason
why the patch application failed (either A did not apply
cleanly, or you gave --fail to the command).
The main question is what you would let your users do and how
you would guide them through the process, when the application
of an earlier patch in the series fails. I think it is a
secondary implementation detail which of "git-am", "git-am
--fail" or "git-apply" to implement that process.
^ permalink raw reply
* Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
From: Junio C Hamano @ 2006-07-03 20:08 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <e8atkm$ipg$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> As I see it, we have the following options with respect to autoconf related
> files and use of ./configure script
>
>
> 1. Use autoconf and ./configure script generated by it as optional way to
> configure installation process. Have configure.ac and config.mak.in in main
> directory of git.git repository. Do not use ./configure script in
> git.spec.in, i.e. do not apply this patch... perhaps put _patch_ in the
> contrib/. Leave changes to *.spec file to distributions, documenting it
> somewhere.
> ..
> I am partially to [*1*], if just because I wouldn't need to take care
> autoconf in git.
I do not understand this "I wouldn't need to take care autoconf
in git" part. Sorry.
^ permalink raw reply
* Re: [PATCH] Make zlib compression level configurable, and change default.
From: Joachim B Haga @ 2006-07-03 20:11 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0607031226370.12404@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> [snip suggested improvements]
Yes, that would be more... thorough. And, especially for the
int zlib_compression_level = Z_DEFAULT_COMPRESSION;
line, more self-explanatory, too. So here's an updated patch
(replacing the previous) including your suggestions.
-j.
-
Make zlib compression level configurable, and change default.
With the change in default, "git add ." on kernel dir is about
twice as fast as before, with only minimal (0.5%) change in
object size. The speed difference is even more noticeable
when committing large files, which is now up to 8 times faster.
The configurability is through setting core.compression = [-1..9]
which maps to the zlib constants; -1 is the default, 0 is no
compression, and 1..9 are various speed/size tradeoffs, 9
being slowest.
Signed-off-by: Joachim B Haga (cjhaga@fys.uio.no)
---
Documentation/config.txt | 6 ++++++
cache.h | 1 +
config.c | 10 ++++++++++
environment.c | 1 +
sha1_file.c | 4 ++--
5 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a04c5ad..ac89be7 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -91,6 +91,12 @@ core.warnAmbiguousRefs::
If true, git will warn you if the ref name you passed it is ambiguous
and might match multiple refs in the .git/refs/ tree. True by default.
+core.compression:
+ An integer -1..9, indicating the compression level for objects that
+ are not in a pack file. -1 is the zlib and git default. 0 means no
+ compression, and 1..9 are various speed/size tradeoffs, 9 being
+ slowest.
+
alias.*::
Command aliases for the gitlink:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
diff --git a/cache.h b/cache.h
index 8719939..84770bf 100644
--- a/cache.h
+++ b/cache.h
@@ -183,6 +183,7 @@ extern int log_all_ref_updates;
extern int warn_ambiguous_refs;
extern int shared_repository;
extern const char *apply_default_whitespace;
+extern int zlib_compression_level;
#define GIT_REPO_VERSION 0
extern int repository_format_version;
diff --git a/config.c b/config.c
index ec44827..b23f4bf 100644
--- a/config.c
+++ b/config.c
@@ -279,6 +279,16 @@ int git_default_config(const char *var,
return 0;
}
+ if (!strcmp(var, "core.compression")) {
+ int level = git_config_int(var, value);
+ if (level == -1)
+ level = Z_DEFAULT_COMPRESSION;
+ else if (level < 0 || level > Z_BEST_COMPRESSION)
+ die("bad zlib compression level %d", level);
+ zlib_compression_level = level;
+ return 0;
+ }
+
if (!strcmp(var, "user.name")) {
strlcpy(git_default_name, value, sizeof(git_default_name));
return 0;
diff --git a/environment.c b/environment.c
index 3de8eb3..43823ff 100644
--- a/environment.c
+++ b/environment.c
@@ -20,6 +20,7 @@ int repository_format_version = 0;
char git_commit_encoding[MAX_ENCODING_LENGTH] = "utf-8";
int shared_repository = PERM_UMASK;
const char *apply_default_whitespace = NULL;
+int zlib_compression_level = Z_DEFAULT_COMPRESSION;
static char *git_dir, *git_object_dir, *git_index_file, *git_refs_dir,
*git_graft_file;
diff --git a/sha1_file.c b/sha1_file.c
index 8179630..bc35808 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1458,7 +1458,7 @@ int write_sha1_file(void *buf, unsigned
/* Set it up */
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_BEST_COMPRESSION);
+ deflateInit(&stream, zlib_compression_level);
size = deflateBound(&stream, len+hdrlen);
compressed = xmalloc(size);
@@ -1511,7 +1511,7 @@ static void *repack_object(const unsigne
/* Set it up */
memset(&stream, 0, sizeof(stream));
- deflateInit(&stream, Z_BEST_COMPRESSION);
+ deflateInit(&stream, zlib_compression_level);
size = deflateBound(&stream, len + hdrlen);
buf = xmalloc(size);
--
1.4.1.g8fced-dirty
^ permalink raw reply related
* Re: Quick merge status updates.
From: Petr Baudis @ 2006-07-03 20:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vejx31sav.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Jul 03, 2006 at 02:02:30AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Petr Baudis <pasky@suse.cz> writes:
>
> > so this is my attempt to summarize it:
>
> Ah, our message crossed -- thanks for summarizing it. I do not
> particularly like any of the solution so far, but maybe the
> patch I just sent out to "do the normal thing unless we are
> running tests" might be the right thing to do.
Yes, I roughly agree. I have some gripes, patches will follow.
> > (ii) My proposed second solution was to add an autogenerated line to
> > the Git's perl scripts saying something like:
> >
> > use lib ('instlibdir', 'srclibdir');
> >
> > This fulfills all (D1), (D2) and (D3)
>
> If you have srclibdir after instlibdir, aren't you breaking D2?
*Sigh*
Why can't I get it right for once? ;-)
> And I do not think swapping them is right either. It would
> fullfil D1/D2/D3 but I think it has one bad side effect.
Yes, I agree with your reservations.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: [PATCH 2] autoconf: Use ./configure script in git *.spec file
From: Jakub Narebski @ 2006-07-03 20:43 UTC (permalink / raw)
To: git
In-Reply-To: <7v4pxyqwn6.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> As I see it, we have the following options with respect to autoconf
related
>> files and use of ./configure script
>>
>>
>> 1. Use autoconf and ./configure script generated by it as optional way to
>> configure installation process. Have configure.ac and config.mak.in in
main
>> directory of git.git repository. Do not use ./configure script in
>> git.spec.in, i.e. do not apply this patch... perhaps put _patch_ in the
>> contrib/. Leave changes to *.spec file to distributions, documenting it
>> somewhere.
>> ..
>> I am partially to [*1*], if just because I wouldn't need to take care
>> autoconf in git.
>
> I do not understand this "I wouldn't need to take care autoconf
> in git" part. Sorry.
Gah. It should be: "if just because there would be no need to have someone
to take care that ./configure is up-to-date with respect to changes in
autoconf files". Sorry for the noise.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH 3/6] Git.pm: Introduce ident() and ident_person() methods
From: Petr Baudis @ 2006-07-03 20:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060703204415.28541.47920.stgit@machine.or.cz>
These methods can retrieve/parse the author/committer ident.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
git-send-email.perl | 11 ++---------
perl/Git.pm | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 51 insertions(+), 9 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index e794e44..79e82f5 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -84,15 +84,8 @@ foreach my $entry (@bcclist) {
# Now, let's fill any that aren't set in with defaults:
-sub gitvar_ident {
- my ($name) = @_;
- my $val = $repo->command('var', $name);
- my @field = split(/\s+/, $val);
- return join(' ', @field[0...(@field-3)]);
-}
-
-my ($author) = gitvar_ident('GIT_AUTHOR_IDENT');
-my ($committer) = gitvar_ident('GIT_COMMITTER_IDENT');
+my ($author) = $repo->ident_person('author');
+my ($committer) = $repo->ident_person('committer');
my %aliases;
my @alias_files = $repo->config('sendemail.aliasesfile');
diff --git a/perl/Git.pm b/perl/Git.pm
index 24fd7ce..9ce9fcd 100644
--- a/perl/Git.pm
+++ b/perl/Git.pm
@@ -521,6 +521,55 @@ sub config {
}
+=item ident ( TYPE | IDENTSTR )
+
+=item ident_person ( TYPE | IDENTSTR | IDENTARRAY )
+
+This suite of functions retrieves and parses ident information, as stored
+in the commit and tag objects or produced by C<var GIT_type_IDENT> (thus
+C<TYPE> can be either I<author> or I<committer>; case is insignificant).
+
+The C<ident> method retrieves the ident information from C<git-var>
+and either returns it as a scalar string or as an array with the fields parsed.
+Alternatively, it can take a prepared ident string (e.g. from the commit
+object) and just parse it.
+
+C<ident_person> returns the person part of the ident - name and email;
+it can take the same arguments as C<ident> or the array returned by C<ident>.
+
+The synopsis is like:
+
+ my ($name, $email, $time_tz) = ident('author');
+ "$name <$email>" eq ident_person('author');
+ "$name <$email>" eq ident_person($name);
+ $time_tz =~ /^\d+ [+-]\d{4}$/;
+
+Both methods must be called on a repository instance.
+
+=cut
+
+sub ident {
+ my ($self, $type) = @_;
+ my $identstr;
+ if (lc $type eq lc 'committer' or lc $type eq lc 'author') {
+ $identstr = $self->command_oneline('var', 'GIT_'.uc($type).'_IDENT');
+ } else {
+ $identstr = $type;
+ }
+ if (wantarray) {
+ return $identstr =~ /^(.*) <(.*)> (\d+ [+-]\d{4})$/;
+ } else {
+ return $identstr;
+ }
+}
+
+sub ident_person {
+ my ($self, @ident) = @_;
+ $#ident == 0 and @ident = $self->ident($ident[0]);
+ return "$ident[0] <$ident[1]>";
+}
+
+
=item hash_object ( TYPE, FILENAME )
=item hash_object ( TYPE, FILEHANDLE )
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox