* Re: git-rev-list bug?
From: Junio C Hamano @ 2006-03-10 9:59 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Catalin Marinas
In-Reply-To: <7virqmzlhb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I am wondering why try_to_simplify_commit() skips parents marked
> with UNINTERESTING. I think this is causing a problem Catalin
> found with rev-list.
> ...
> The attached patch seems to fix it (without losing the logic to
> omit tree comparison with UNINTERESTING parent, which I do not
> quite understand).
Actually the previous patch is not right either. If I ask "what
changes path B between commit#1..commit#4", it would still omit
commit#2.
It should not matter if the parent is uninteresting while
checking if a commit touches the specified path. The attached
patch which replaces the previous botched one does exactly that.
It however has a side effect -- uninteresting commits were never
parsed here, but now they get parsed. I am not sure if there
are correctness implications...
---
diff --git a/revision.c b/revision.c
index 713f27e..9d0934a 100644
--- a/revision.c
+++ b/revision.c
@@ -296,11 +296,6 @@ static void try_to_simplify_commit(struc
while ((parent = *pp) != NULL) {
struct commit *p = parent->item;
- if (p->object.flags & UNINTERESTING) {
- pp = &parent->next;
- continue;
- }
-
parse_commit(p);
switch (compare_tree(p->tree, commit->tree)) {
case TREE_SAME:
^ permalink raw reply related
* Re: git-rev-list bug?
From: Junio C Hamano @ 2006-03-10 9:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Catalin Marinas
In-Reply-To: <7vmzfy1zjb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> To my surprise, it turns out that this regression was not very
> recent. Bisecting points at this commite:
>...
> I haven't had time to dig into this deeper yet...
I am wondering why try_to_simplify_commit() skips parents marked
with UNINTERESTING. I think this is causing a problem Catalin
found with rev-list.
If you have (time flows from top to bottom):
commit#1 (it does not matter what this does)
commit#2 change file B only
commit#3 change file A only
commit#4 change file B only
"git-rev-list commit#1..commit#4 -- A" shows commit#3 (correct)
and commit#2 (incorrect).
It pushes commit#1 (UNINTERESTING) and commit#4 (~UNINTERESTING)
and starts traversing. try-to-simplify(commit#4) says "no tree
change between #3 and #4" and it returns without marking
commit#4 with TREECHANGE flag. But when looking at commit#2 and
trying to simplify it, it says "Ah, its parent is uninteresting,
so I would not do compare_tree()". Iteration over parents of
commit#2 leaves the while() loop and at the end of function the
commit is marked with TREECHANGE and is shown.
The attached patch seems to fix it (without losing the logic to
omit tree comparison with UNINTERESTING parent, which I do not
quite understand).
---
diff --git a/revision.c b/revision.c
index 713f27e..23c9b9d 100644
--- a/revision.c
+++ b/revision.c
@@ -282,6 +282,7 @@ static int same_tree_as_empty(struct tre
static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
{
struct commit_list **pp, *parent;
+ int changed = 0;
if (!commit->tree)
return;
@@ -315,12 +316,14 @@ static void try_to_simplify_commit(struc
}
/* fallthrough */
case TREE_DIFFERENT:
+ changed = 1;
pp = &parent->next;
continue;
}
die("bad tree compare for commit %s", sha1_to_hex(commit->object.sha1));
}
- commit->object.flags |= TREECHANGE;
+ if (changed)
+ commit->object.flags |= TREECHANGE;
}
static void add_parents_to_list(struct rev_info *revs, struct commit *commit, struct commit_list **list)
^ permalink raw reply related
* [PATCH 3/3] blame: Rename detection (take 2)
From: Fredrik Kuivinen @ 2006-03-10 9:21 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <20060310092135.24015.26510.stgit@c165>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
blame.c | 239 ++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 199 insertions(+), 40 deletions(-)
diff --git a/blame.c b/blame.c
index 90338af..ac57e10 100644
--- a/blame.c
+++ b/blame.c
@@ -14,6 +14,7 @@
#include "tree.h"
#include "blob.h"
#include "diff.h"
+#include "diffcore.h"
#include "revision.h"
#define DEBUG 0
@@ -34,7 +35,9 @@ struct util_info {
char *buf;
unsigned long size;
int num_lines;
-// const char* path;
+ const char* pathname;
+
+ void* topo_data;
};
struct chunk {
@@ -342,25 +345,34 @@ static int map_line(struct commit *commi
return info->line_map[line];
}
-static int fill_util_info(struct commit *commit, const char *path)
+static struct util_info* get_util(struct commit *commit)
{
- struct util_info *util;
- if (commit->object.util)
- return 0;
+ struct util_info *util = commit->object.util;
+
+ if (util)
+ return util;
util = xmalloc(sizeof(struct util_info));
+ util->buf = NULL;
+ util->size = 0;
+ util->line_map = NULL;
+ util->num_lines = -1;
+ util->pathname = NULL;
+ commit->object.util = util;
+ return util;
+}
- if (get_blob_sha1(commit->tree, path, util->sha1)) {
- free(util);
+static int fill_util_info(struct commit *commit)
+{
+ struct util_info *util = commit->object.util;
+
+ assert(util);
+ assert(util->pathname);
+
+ if (get_blob_sha1(commit->tree, util->pathname, util->sha1))
return 1;
- } else {
- util->buf = NULL;
- util->size = 0;
- util->line_map = NULL;
- util->num_lines = -1;
- commit->object.util = util;
+ else
return 0;
- }
}
static void alloc_line_map(struct commit *commit)
@@ -389,10 +401,11 @@ static void alloc_line_map(struct commit
static void init_first_commit(struct commit* commit, const char* filename)
{
- struct util_info* util;
+ struct util_info* util = commit->object.util;
int i;
- if (fill_util_info(commit, filename))
+ util->pathname = filename;
+ if (fill_util_info(commit))
die("fill_util_info failed");
alloc_line_map(commit);
@@ -453,7 +466,7 @@ static void process_commits(struct rev_i
if(num_parents == 0)
*initial = commit;
- if(fill_util_info(commit, path))
+ if (fill_util_info(commit))
continue;
alloc_line_map(commit);
@@ -471,7 +484,7 @@ static void process_commits(struct rev_i
printf("parent: %s\n",
sha1_to_hex(parent->object.sha1));
- if(fill_util_info(parent, path)) {
+ if (fill_util_info(parent)) {
num_parents--;
continue;
}
@@ -511,6 +524,135 @@ static void process_commits(struct rev_i
} while ((commit = get_revision(rev)) != NULL);
}
+
+static int compare_tree_path(struct rev_info* revs,
+ struct commit* c1, struct commit* c2)
+{
+ const char* paths[2];
+ struct util_info* util = c2->object.util;
+ paths[0] = util->pathname;
+ paths[1] = NULL;
+
+ diff_tree_setup_paths(get_pathspec(revs->prefix, paths));
+ return rev_compare_tree(c1->tree, c2->tree);
+}
+
+
+static int same_tree_as_empty_path(struct rev_info *revs, struct tree* t1,
+ const char* path)
+{
+ const char* paths[2];
+ paths[0] = path;
+ paths[1] = NULL;
+
+ diff_tree_setup_paths(get_pathspec(revs->prefix, paths));
+ return rev_same_tree_as_empty(t1);
+}
+
+static const char* find_rename(struct commit* commit, struct commit* parent)
+{
+ struct util_info* cutil = commit->object.util;
+ struct diff_options diff_opts;
+ const char *paths[1];
+ int i;
+
+ if (DEBUG) {
+ printf("find_rename commit: %s ",
+ sha1_to_hex(commit->object.sha1));
+ puts(sha1_to_hex(parent->object.sha1));
+ }
+
+ diff_setup(&diff_opts);
+ diff_opts.recursive = 1;
+ diff_opts.detect_rename = DIFF_DETECT_RENAME;
+ paths[0] = NULL;
+ diff_tree_setup_paths(paths);
+ if (diff_setup_done(&diff_opts) < 0)
+ die("diff_setup_done failed");
+
+ diff_tree_sha1(commit->tree->object.sha1, parent->tree->object.sha1,
+ "", &diff_opts);
+ diffcore_std(&diff_opts);
+
+ for (i = 0; i < diff_queued_diff.nr; i++) {
+ struct diff_filepair *p = diff_queued_diff.queue[i];
+
+ if (p->status == 'R' && !strcmp(p->one->path, cutil->pathname)) {
+ if (DEBUG)
+ printf("rename %s -> %s\n", p->one->path, p->two->path);
+ return p->two->path;
+ }
+ }
+
+ return 0;
+}
+
+static void simplify_commit(struct rev_info *revs, struct commit *commit)
+{
+ struct commit_list **pp, *parent;
+
+ if (!commit->tree)
+ return;
+
+ if (!commit->parents) {
+ struct util_info* util = commit->object.util;
+ if (!same_tree_as_empty_path(revs, commit->tree,
+ util->pathname))
+ commit->object.flags |= TREECHANGE;
+ return;
+ }
+
+ pp = &commit->parents;
+ while ((parent = *pp) != NULL) {
+ struct commit *p = parent->item;
+
+ if (p->object.flags & UNINTERESTING) {
+ pp = &parent->next;
+ continue;
+ }
+
+ parse_commit(p);
+ switch (compare_tree_path(revs, p, commit)) {
+ case REV_TREE_SAME:
+ parent->next = NULL;
+ commit->parents = parent;
+ get_util(p)->pathname = get_util(commit)->pathname;
+ return;
+
+ case REV_TREE_NEW:
+ {
+
+ struct util_info* util = commit->object.util;
+ if (revs->remove_empty_trees &&
+ same_tree_as_empty_path(revs, p->tree,
+ util->pathname)) {
+ const char* new_name = find_rename(commit, p);
+ if (new_name) {
+ struct util_info* putil = get_util(p);
+ if (!putil->pathname)
+ putil->pathname = strdup(new_name);
+ } else {
+ *pp = parent->next;
+ continue;
+ }
+ }
+ }
+
+ /* fallthrough */
+ case REV_TREE_DIFFERENT:
+ pp = &parent->next;
+ if (!get_util(p)->pathname)
+ get_util(p)->pathname =
+ get_util(commit)->pathname;
+ continue;
+ }
+ die("bad tree compare for commit %s",
+ sha1_to_hex(commit->object.sha1));
+ }
+ commit->object.flags |= TREECHANGE;
+}
+
+
struct commit_info
{
char* author;
@@ -569,6 +711,18 @@ static const char* format_time(unsigned
return time_buf;
}
+static void topo_setter(struct commit* c, void* data)
+{
+ struct util_info* util = c->object.util;
+ util->topo_data = data;
+}
+
+static void* topo_getter(struct commit* c)
+{
+ struct util_info* util = c->object.util;
+ return util->topo_data;
+}
+
int main(int argc, const char **argv)
{
int i;
@@ -580,8 +734,8 @@ int main(int argc, const char **argv)
int sha1_len = 8;
int compability = 0;
int options = 1;
+ struct commit* start_commit;
- int num_args;
const char* args[10];
struct rev_info rev;
@@ -634,28 +788,29 @@ int main(int argc, const char **argv)
strcpy(filename_buf, filename);
filename = filename_buf;
- {
- struct commit* c;
- if (get_sha1(commit, sha1))
- die("get_sha1 failed, commit '%s' not found", commit);
- c = lookup_commit_reference(sha1);
-
- if (fill_util_info(c, filename)) {
- printf("%s not found in %s\n", filename, commit);
- return 1;
- }
+ if (get_sha1(commit, sha1))
+ die("get_sha1 failed, commit '%s' not found", commit);
+ start_commit = lookup_commit_reference(sha1);
+ get_util(start_commit)->pathname = filename;
+ if (fill_util_info(start_commit)) {
+ printf("%s not found in %s\n", filename, commit);
+ return 1;
}
- num_args = 0;
- args[num_args++] = NULL;
- args[num_args++] = "--topo-order";
- args[num_args++] = "--remove-empty";
- args[num_args++] = commit;
- args[num_args++] = "--";
- args[num_args++] = filename;
- args[num_args] = NULL;
- setup_revisions(num_args, args, &rev, "HEAD");
+ init_revisions(&rev);
+ rev.remove_empty_trees = 1;
+ rev.topo_order = 1;
+ rev.prune_fn = simplify_commit;
+ rev.topo_setter = topo_setter;
+ rev.topo_getter = topo_getter;
+ rev.limited = 1;
+
+ commit_list_insert(start_commit, &rev.commits);
+
+ args[0] = filename;
+ args[1] = NULL;
+ diff_tree_setup_paths(args);
prepare_revision_walk(&rev);
process_commits(&rev, filename, &initial);
@@ -665,17 +820,21 @@ int main(int argc, const char **argv)
for (i = 0; i < num_blame_lines; i++) {
struct commit *c = blame_lines[i];
+ struct util_info* u;
+
if (!c)
c = initial;
+ u = c->object.util;
get_commit_info(c, &ci);
fwrite(sha1_to_hex(c->object.sha1), sha1_len, 1, stdout);
if(compability)
printf("\t(%10s\t%10s\t%d)", ci.author,
format_time(ci.author_time, ci.author_tz), i+1);
else
- printf(" (%-15.15s %10s %*d) ", ci.author,
- format_time(ci.author_time, ci.author_tz),
+ printf(" %s (%-15.15s %10s %*d) ", u->pathname,
+ ci.author, format_time(ci.author_time,
+ ci.author_tz),
max_digits, i+1);
if(i == num_blame_lines - 1) {
^ permalink raw reply related
* [PATCH 2/3] rev-lib: Make it easy to do rename tracking (take 2)
From: Fredrik Kuivinen @ 2006-03-10 9:21 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <20060310092135.24015.26510.stgit@c165>
prune_fn in the rev_info structure is called in place of
try_to_simplify_commit. This makes it possible to do rename tracking
with a custom try_to_simplify_commit-like function.
This commit also introduces init_revisions which initialises the rev_info
structure with default values.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
rev-list.c | 6 ++--
revision.c | 100 ++++++++++++++++++++++++++++++++++--------------------------
revision.h | 18 ++++++++++-
3 files changed, 76 insertions(+), 48 deletions(-)
diff --git a/rev-list.c b/rev-list.c
index 8e4d83e..812d237 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -190,7 +190,7 @@ static int count_distance(struct commit_
if (commit->object.flags & (UNINTERESTING | COUNTED))
break;
- if (!revs.paths || (commit->object.flags & TREECHANGE))
+ if (!revs.prune_fn || (commit->object.flags & TREECHANGE))
nr++;
commit->object.flags |= COUNTED;
p = commit->parents;
@@ -224,7 +224,7 @@ static struct commit_list *find_bisectio
nr = 0;
p = list;
while (p) {
- if (!revs.paths || (p->item->object.flags & TREECHANGE))
+ if (!revs.prune_fn || (p->item->object.flags & TREECHANGE))
nr++;
p = p->next;
}
@@ -234,7 +234,7 @@ static struct commit_list *find_bisectio
for (p = list; p; p = p->next) {
int distance;
- if (revs.paths && !(p->item->object.flags & TREECHANGE))
+ if (revs.prune_fn && !(p->item->object.flags & TREECHANGE))
continue;
distance = count_distance(p);
diff --git a/revision.c b/revision.c
index 2a33637..b41f961 100644
--- a/revision.c
+++ b/revision.c
@@ -197,31 +197,27 @@ static int everybody_uninteresting(struc
return 1;
}
-#define TREE_SAME 0
-#define TREE_NEW 1
-#define TREE_DIFFERENT 2
-static int tree_difference = TREE_SAME;
+static int tree_difference = REV_TREE_SAME;
static void file_add_remove(struct diff_options *options,
int addremove, unsigned mode,
const unsigned char *sha1,
const char *base, const char *path)
{
- int diff = TREE_DIFFERENT;
+ int diff = REV_TREE_DIFFERENT;
/*
- * Is it an add of a new file? It means that
- * the old tree didn't have it at all, so we
- * will turn "TREE_SAME" -> "TREE_NEW", but
- * leave any "TREE_DIFFERENT" alone (and if
- * it already was "TREE_NEW", we'll keep it
- * "TREE_NEW" of course).
+ * Is it an add of a new file? It means that the old tree
+ * didn't have it at all, so we will turn "REV_TREE_SAME" ->
+ * "REV_TREE_NEW", but leave any "REV_TREE_DIFFERENT" alone
+ * (and if it already was "REV_TREE_NEW", we'll keep it
+ * "REV_TREE_NEW" of course).
*/
if (addremove == '+') {
diff = tree_difference;
- if (diff != TREE_SAME)
+ if (diff != REV_TREE_SAME)
return;
- diff = TREE_NEW;
+ diff = REV_TREE_NEW;
}
tree_difference = diff;
}
@@ -232,7 +228,7 @@ static void file_change(struct diff_opti
const unsigned char *new_sha1,
const char *base, const char *path)
{
- tree_difference = TREE_DIFFERENT;
+ tree_difference = REV_TREE_DIFFERENT;
}
static struct diff_options diff_opt = {
@@ -241,19 +237,19 @@ static struct diff_options diff_opt = {
.change = file_change,
};
-static int compare_tree(struct tree *t1, struct tree *t2)
+int rev_compare_tree(struct tree *t1, struct tree *t2)
{
if (!t1)
- return TREE_NEW;
+ return REV_TREE_NEW;
if (!t2)
- return TREE_DIFFERENT;
- tree_difference = TREE_SAME;
+ return REV_TREE_DIFFERENT;
+ tree_difference = REV_TREE_SAME;
if (diff_tree_sha1(t1->object.sha1, t2->object.sha1, "", &diff_opt) < 0)
- return TREE_DIFFERENT;
+ return REV_TREE_DIFFERENT;
return tree_difference;
}
-static int same_tree_as_empty(struct tree *t1)
+int rev_same_tree_as_empty(struct tree *t1)
{
int retval;
void *tree;
@@ -285,7 +281,7 @@ static void try_to_simplify_commit(struc
return;
if (!commit->parents) {
- if (!same_tree_as_empty(commit->tree))
+ if (!rev_same_tree_as_empty(commit->tree))
commit->object.flags |= TREECHANGE;
return;
}
@@ -300,19 +296,20 @@ static void try_to_simplify_commit(struc
}
parse_commit(p);
- switch (compare_tree(p->tree, commit->tree)) {
- case TREE_SAME:
+ switch (rev_compare_tree(p->tree, commit->tree)) {
+ case REV_TREE_SAME:
parent->next = NULL;
commit->parents = parent;
return;
- case TREE_NEW:
- if (revs->remove_empty_trees && same_tree_as_empty(p->tree)) {
+ case REV_TREE_NEW:
+ if (revs->remove_empty_trees &&
+ rev_same_tree_as_empty(p->tree)) {
*pp = parent->next;
continue;
}
/* fallthrough */
- case TREE_DIFFERENT:
+ case REV_TREE_DIFFERENT:
pp = &parent->next;
continue;
}
@@ -358,8 +355,8 @@ static void add_parents_to_list(struct r
* simplify the commit history and find the parent
* that has no differences in the path set if one exists.
*/
- if (revs->paths)
- try_to_simplify_commit(revs, commit);
+ if (revs->prune_fn)
+ revs->prune_fn(revs, commit);
parent = commit->parents;
while (parent) {
@@ -381,9 +378,6 @@ static void limit_list(struct rev_info *
struct commit_list *newlist = NULL;
struct commit_list **p = &newlist;
- if (revs->paths)
- diff_tree_setup_paths(revs->paths);
-
while (list) {
struct commit_list *entry = list;
struct commit *commit = list->item;
@@ -435,6 +429,23 @@ static void handle_all(struct rev_info *
for_each_ref(handle_one_ref);
}
+void init_revisions(struct rev_info *revs)
+{
+ memset(revs, 0, sizeof(*revs));
+ revs->lifo = 1;
+ revs->dense = 1;
+ revs->prefix = setup_git_directory();
+ revs->max_age = -1;
+ revs->min_age = -1;
+ revs->max_count = -1;
+
+ revs->prune_fn = NULL;
+ revs->prune_data = NULL;
+
+ revs->topo_setter = topo_sort_default_setter;
+ revs->topo_getter = topo_sort_default_getter;
+}
+
/*
* Parse revision information, filling in the "rev_info" structure,
* and removing the used arguments from the argument list.
@@ -448,14 +459,8 @@ int setup_revisions(int argc, const char
const char **unrecognized = argv + 1;
int left = 1;
- memset(revs, 0, sizeof(*revs));
- revs->lifo = 1;
- revs->dense = 1;
- revs->prefix = setup_git_directory();
- revs->max_age = -1;
- revs->min_age = -1;
- revs->max_count = -1;
-
+ init_revisions(revs);
+
/* First, search for "--" */
seen_dashdash = 0;
for (i = 1; i < argc; i++) {
@@ -464,7 +469,7 @@ int setup_revisions(int argc, const char
continue;
argv[i] = NULL;
argc = i;
- revs->paths = get_pathspec(revs->prefix, argv + i + 1);
+ revs->prune_data = get_pathspec(revs->prefix, argv + i + 1);
seen_dashdash = 1;
break;
}
@@ -628,7 +633,7 @@ int setup_revisions(int argc, const char
if (lstat(argv[j], &st) < 0)
die("'%s': %s", arg, strerror(errno));
}
- revs->paths = get_pathspec(revs->prefix, argv + i);
+ revs->prune_data = get_pathspec(revs->prefix, argv + i);
break;
}
commit = get_commit_reference(revs, arg, sha1, flags ^ local_flags);
@@ -642,8 +647,13 @@ int setup_revisions(int argc, const char
commit = get_commit_reference(revs, def, sha1, 0);
add_one_commit(commit, revs);
}
- if (revs->paths)
+
+ if (revs->prune_data) {
+ diff_tree_setup_paths(revs->prune_data);
+ revs->prune_fn = try_to_simplify_commit;
revs->limited = 1;
+ }
+
return left;
}
@@ -653,7 +663,9 @@ void prepare_revision_walk(struct rev_in
if (revs->limited)
limit_list(revs);
if (revs->topo_order)
- sort_in_topological_order(&revs->commits, revs->lifo);
+ sort_in_topological_order_fn(&revs->commits, revs->lifo,
+ revs->topo_setter,
+ revs->topo_getter);
}
static int rewrite_one(struct commit **pp)
@@ -709,7 +721,7 @@ struct commit *get_revision(struct rev_i
return NULL;
if (revs->no_merges && commit->parents && commit->parents->next)
goto next;
- if (revs->paths && revs->dense) {
+ if (revs->prune_fn && revs->dense) {
if (!(commit->object.flags & TREECHANGE))
goto next;
rewrite_parents(commit);
diff --git a/revision.h b/revision.h
index 31e8f61..6c2beca 100644
--- a/revision.h
+++ b/revision.h
@@ -7,6 +7,10 @@
#define SHOWN (1u<<3)
#define TMP_MARK (1u<<4) /* for isolated cases; clean after use */
+struct rev_info;
+
+typedef void (prune_fn_t)(struct rev_info *revs, struct commit *commit);
+
struct rev_info {
/* Starting list */
struct commit_list *commits;
@@ -14,7 +18,8 @@ struct rev_info {
/* Basic information */
const char *prefix;
- const char **paths;
+ void *prune_data;
+ prune_fn_t *prune_fn;
/* Traversal flags */
unsigned int dense:1,
@@ -33,9 +38,20 @@ struct rev_info {
int max_count;
unsigned long max_age;
unsigned long min_age;
+
+ topo_sort_set_fn_t topo_setter;
+ topo_sort_get_fn_t topo_getter;
};
+#define REV_TREE_SAME 0
+#define REV_TREE_NEW 1
+#define REV_TREE_DIFFERENT 2
+
/* revision.c */
+extern int rev_same_tree_as_empty(struct tree *t1);
+extern int rev_compare_tree(struct tree *t1, struct tree *t2);
+
+extern void init_revisions(struct rev_info *revs);
extern int setup_revisions(int argc, const char **argv, struct rev_info *revs, const char *def);
extern void prepare_revision_walk(struct rev_info *revs);
extern struct commit *get_revision(struct rev_info *revs);
^ permalink raw reply related
* [PATCH 1/3] Make it possible to not clobber object.util in sort_in_topological_order (take 2)
From: Fredrik Kuivinen @ 2006-03-10 9:21 UTC (permalink / raw)
To: git; +Cc: junkio
In-Reply-To: <20060310092135.24015.26510.stgit@c165>
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
---
commit.c | 30 ++++++++++++++++++++++++------
commit.h | 16 +++++++++++++++-
2 files changed, 39 insertions(+), 7 deletions(-)
diff --git a/commit.c b/commit.c
index 06d5439..013683a 100644
--- a/commit.c
+++ b/commit.c
@@ -569,11 +569,29 @@ int count_parents(struct commit * commit
return count;
}
+void topo_sort_default_setter(struct commit *c, void *data)
+{
+ c->object.util = data;
+}
+
+void *topo_sort_default_getter(struct commit *c)
+{
+ return c->object.util;
+}
+
/*
* Performs an in-place topological sort on the list supplied.
*/
void sort_in_topological_order(struct commit_list ** list, int lifo)
{
+ sort_in_topological_order_fn(list, lifo, topo_sort_default_setter,
+ topo_sort_default_getter);
+}
+
+void sort_in_topological_order_fn(struct commit_list ** list, int lifo,
+ topo_sort_set_fn_t setter,
+ topo_sort_get_fn_t getter)
+{
struct commit_list * next = *list;
struct commit_list * work = NULL, **insert;
struct commit_list ** pptr = list;
@@ -596,7 +614,7 @@ void sort_in_topological_order(struct co
next=*list;
while (next) {
next_nodes->list_item = next;
- next->item->object.util = next_nodes;
+ setter(next->item, next_nodes);
next_nodes++;
next = next->next;
}
@@ -606,7 +624,7 @@ void sort_in_topological_order(struct co
struct commit_list * parents = next->item->parents;
while (parents) {
struct commit * parent=parents->item;
- struct sort_node * pn = (struct sort_node *)parent->object.util;
+ struct sort_node * pn = (struct sort_node *) getter(parent);
if (pn)
pn->indegree++;
@@ -624,7 +642,7 @@ void sort_in_topological_order(struct co
next=*list;
insert = &work;
while (next) {
- struct sort_node * node = (struct sort_node *)next->item->object.util;
+ struct sort_node * node = (struct sort_node *) getter(next->item);
if (node->indegree == 0) {
insert = &commit_list_insert(next->item, insert)->next;
@@ -637,12 +655,12 @@ void sort_in_topological_order(struct co
sort_by_date(&work);
while (work) {
struct commit * work_item = pop_commit(&work);
- struct sort_node * work_node = (struct sort_node *)work_item->object.util;
+ struct sort_node * work_node = (struct sort_node *) getter(work_item);
struct commit_list * parents = work_item->parents;
while (parents) {
struct commit * parent=parents->item;
- struct sort_node * pn = (struct sort_node *)parent->object.util;
+ struct sort_node * pn = (struct sort_node *) getter(parent);
if (pn) {
/*
@@ -667,7 +685,7 @@ void sort_in_topological_order(struct co
*pptr = work_node->list_item;
pptr = &(*pptr)->next;
*pptr = NULL;
- work_item->object.util = NULL;
+ setter(work_item, NULL);
}
free(nodes);
}
diff --git a/commit.h b/commit.h
index 70a7c75..15c798a 100644
--- a/commit.h
+++ b/commit.h
@@ -65,15 +65,29 @@ int count_parents(struct commit * commit
/*
* Performs an in-place topological sort of list supplied.
*
- * Pre-conditions:
+ * Pre-conditions for sort_in_topological_order:
* all commits in input list and all parents of those
* commits must have object.util == NULL
*
+ * Pre-conditions for sort_in_topological_order_fn:
+ * all commits in input list and all parents of those
+ * commits must have getter(commit) == NULL
+ *
* Post-conditions:
* invariant of resulting list is:
* a reachable from b => ord(b) < ord(a)
* in addition, when lifo == 0, commits on parallel tracks are
* sorted in the dates order.
*/
+
+typedef void (*topo_sort_set_fn_t)(struct commit*, void *data);
+typedef void* (*topo_sort_get_fn_t)(struct commit*);
+
+void topo_sort_default_setter(struct commit *c, void *data);
+void *topo_sort_default_getter(struct commit *c);
+
void sort_in_topological_order(struct commit_list ** list, int lifo);
+void sort_in_topological_order_fn(struct commit_list ** list, int lifo,
+ topo_sort_set_fn_t setter,
+ topo_sort_get_fn_t getter);
#endif /* COMMIT_H */
^ permalink raw reply related
* [PATCH 0/3] Teach git-blame about renames (take 2)
From: Fredrik Kuivinen @ 2006-03-10 9:21 UTC (permalink / raw)
To: git; +Cc: junkio
Changes since the previous version:
* Fix the things pointed out by Junio.
* Some other minor clean-ups
---
This patch series teaches git-blame about renames. To do this I have
changed the revision.h interface a bit. In particular, it is now
possible for the user of revision.h to specify a
try_to_simply_commit-like function. That function can then do the
rename tracking.
I have also made a small change to sort_in_topological_order to make
it possible to use the object.util field at the same time as a
topological sort is done. Previously the object.util field was
clobbered by the topological sort. In the new interface the auxiliary
data that the topological sort needs to store for each commit object
is stored with a setter function and retrieved by a getter. Pointers
to those functions are passed to sort_in_topological_order_fn.
- Fredrik
^ permalink raw reply
* Re: git-rev-list bug?
From: Junio C Hamano @ 2006-03-10 8:20 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git, Linus Torvalds
In-Reply-To: <7vacc0iten.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> "Catalin Marinas" <catalin.marinas@gmail.com> writes:
>
>> Sorry if this was previously discussed. I ran git-rev-list on a linear
>> graph and tried to filter the results by a file name:
>>
>> git rev-list since.. path/to/file
>>
>> but it always shows the child commit of "since" even if it didn't
>> touch the file. The same behaviour is for git-log (since it uses
>> git-rev-list) but git-whatchanged seems to be fine.
>>
>> Is this the intended behaviour? The "stg patches" command based on
>> git-rev-list used to work fine a few weeks ago but now it is always
>> reporting the bottom patch in the stack as modifying a given file.
>
> I can confirm that this is a recent breakage, but since it is
> unfortunately my day-job day the more detailed analysis and fix
> needs to wait. Sorry.
To my surprise, it turns out that this regression was not very
recent. Bisecting points at this commite:
diff-tree 461cf59... (from 6b94f1e...)
Author: Linus Torvalds <torvalds@osdl.org>
Date: Wed Jan 18 14:47:30 2006 -0800
rev-list: stop when the file disappears
The one thing I've considered doing (I really should) is to add a "stop
when you don't find the file" option to "git-rev-list". This patch does
some of the work towards that: it removes the "parent" thing when the
file disappears, so a "git annotate" could do do something like
git-rev-list --remove-empty --parents HEAD -- "$filename"
and it would get a good graph that stops when the filename disappears
(it's not perfect though: it won't remove all the unintersting commits).
It also simplifies the logic of finding tree differences a bit, at the
cost of making it a tad less efficient.
The old logic was two-phase: it would first simplify _only_ merges tree as
it traversed the tree, and then simplify the linear parts of the remainder
independently. That was pretty optimal from an efficiency standpoint
because it avoids doing any comparisons that we can see are unnecessary,
but it made it much harder to understand than it really needed to be.
The new logic is a lot more straightforward, and compares the trees as it
traverses the graph (ie everything is a single phase). That makes it much
easier to stop graph traversal at any point where a file disappears.
I haven't had time to dig into this deeper yet...
^ permalink raw reply
* Re: Make test broken w/ 180b0d7483711120e28289ff7d9fa346eddd5cb7
From: Junio C Hamano @ 2006-03-10 6:42 UTC (permalink / raw)
To: gitzilla; +Cc: git, Petr Baudis
In-Reply-To: <441119DB.3020207@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> *** t1200-tutorial.sh ***
> * ok 1: blob
> * ok 2: blob 557db03
> * ok 3: git-diff-files -p
> * ok 4: git diff
> * ok 5: tree
> * ok 6: commit
> * ok 7: git-diff-index -p HEAD
> * ok 8: git diff HEAD
> * ok 9: git-whatchanged -p --root
> * ok 10: git tag my-first-tag
> * ok 11: git checkout -b mybranch
> * ok 12: git branch
> * ok 13: git resolve now fails
> * ok 14: git show-branch
> * FAIL 15: git resolve
> cmp resolve.expect resolve.output
> * ok 16: git show-branch
> * ok 17: git repack
> * ok 18: git prune-packed
> * ok 19: -> only packed objects
> * failed 1 among 19 test(s)
Thanks. Will push out a fix but it should be trivial.
---
diff --git a/t/t1200-tutorial.sh b/t/t1200-tutorial.sh
index c8a85f9..1002413 100755
--- a/t/t1200-tutorial.sh
+++ b/t/t1200-tutorial.sh
@@ -128,7 +128,7 @@ test_expect_success 'git show-branch' 'c
git checkout mybranch
cat > resolve.expect << EOF
-Updating from VARIABLE to VARIABLE.
+Updating from VARIABLE to VARIABLE
example | 1 +
hello | 1 +
2 files changed, 2 insertions(+), 0 deletions(-)
^ permalink raw reply related
* Make test broken w/ 180b0d7483711120e28289ff7d9fa346eddd5cb7
From: A Large Angry SCM @ 2006-03-10 6:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
*** t1200-tutorial.sh ***
* ok 1: blob
* ok 2: blob 557db03
* ok 3: git-diff-files -p
* ok 4: git diff
* ok 5: tree
* ok 6: commit
* ok 7: git-diff-index -p HEAD
* ok 8: git diff HEAD
* ok 9: git-whatchanged -p --root
* ok 10: git tag my-first-tag
* ok 11: git checkout -b mybranch
* ok 12: git branch
* ok 13: git resolve now fails
* ok 14: git show-branch
* FAIL 15: git resolve
cmp resolve.expect resolve.output
* ok 16: git show-branch
* ok 17: git repack
* ok 18: git prune-packed
* ok 19: -> only packed objects
* failed 1 among 19 test(s)
^ permalink raw reply
* Re: git-applymbox fails to extract patch.
From: Dave Jones @ 2006-03-10 5:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603092130030.18022@g5.osdl.org>
On Thu, Mar 09, 2006 at 09:35:11PM -0800, Linus Torvalds wrote:
>
>
> On Fri, 10 Mar 2006, Dave Jones wrote:
> >
> > What am I missing ?
>
> Do you have "Content-Type:" headers with a multi-part boundary? That can
> cause it.
ahhh.
I was sent a MIME mail, and saved the attachment, then deleted
the junk from the body, and inlined it.
Never crossed my mind to check the headers. That'll be it.
Now I remember why I hate hand-munging mails.
*snip snip*
$ git-applymbox -k ~/Mail/mbox
1 patch(es) to process.
Applying '[CPUFREQ] Fix the p4-clockmod N60 errata workaround.'
Wrote tree 6d7d2dfd2309675446f727a6b4b2a6ff475835fb
Committed: 6d373ea012b2974e627b9ee830e75cf3bf3c4c24
Sweet. I'm happy again.
Thanks,
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: git-applymbox fails to extract patch.
From: Linus Torvalds @ 2006-03-10 5:35 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20060310050446.GA20764@redhat.com>
On Fri, 10 Mar 2006, Dave Jones wrote:
>
> What am I missing ?
Do you have "Content-Type:" headers with a multi-part boundary? That can
cause it.
Also, empty X-IMAP messages at the beginning of a mbox (pine does those,
others probably do too) will cause things like that. The extra "email"
will have no patch in it..
Linus
^ permalink raw reply
* Re: git-rev-list feature request
From: Linus Torvalds @ 2006-03-10 5:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0603092056300.18022@g5.osdl.org>
On Thu, 9 Mar 2006, Linus Torvalds wrote:
>
> Ahh, ok, you actually wanted something simpler than I thought you might.
Btw, what I _thought_ you migth want is to do the current "strong
pruning", and then look up - from the stuff left behind - which ones reach
to a ref or a tag. That's where the reverse refs would come in, and it
requires some fundamental surgery (but it shouldn't be hard at all).
Linus
^ permalink raw reply
* Re: git-rev-list feature request
From: Linus Torvalds @ 2006-03-10 5:14 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <17425.1459.786864.172060@cargo.ozlabs.ibm.com>
On Fri, 10 Mar 2006, Paul Mackerras wrote:
> Linus Torvalds writes:
>
> > Yeah. I _think_ what you want is
> >
> > - phase 1: generate the current graph that we already do for
> >
> > git-rev-list --all ^cmit
> >
> > - phase 2: start at "cmit", and mark everything that refers to it as
> > "show me" (including "cmit" itself, which was originally marked
> > uninteresting)
>
> I'm not sure if that's what I want. Is that how "git-rev-list -- foo"
> works?
Nope. "git-rev-list -- foo" will just start from the heads given, and walk
down.
> What I want is basically just what "git-rev-list -- foo" does, but
> with some extra flexibility in choosing what commits are interesting -
> that is, to be able to say that a commit is interesting if it affects
> some file, has a reference under .git/refs, or if it is one of a set
> of specified commits.
Ahh, ok, you actually wanted something simpler than I thought you might.
What you want is (in its most trivial form) really trivial: mark the
special commits you want to save with TREECHANGE, so that they aren't
pruned by the logic that prunes off the "this commit doesn't change the
file, so ignore it" commits.
HOWEVER. That trivial thing has problems. What if the history got
simplified at a merge because one side of the merge changed it, and the
other one did not - in that case we'll follow the history down the leg
that didn't change (since that's the history that ended up being the final
one). Now, that means that we will totally prune out the other parent
info, and the commits you want to remain simply won't be "connected" any
more.
To explain that better, let's say that history looks like this:
a
/ \
b c
| |
d e
\ /
f
and you're following file "foo", which is the same in "a" and "c". The
fact that they are the same there means that the name pruning will decide
that the history that led to "a" through "b" wasn't interesting, so it
will prune that out, and make the whole history be
a
|
c
|
e
|
f
and then after that, it will remove all commits that didn't actually
change foo at all (we know "a" was such a commit since we already
simplified the merge, but let's say that "e" was one too), so you get
c
|
f
as the final simplified history right now.
Now, the problem is that what should you do if you want to tag "d" and "e"
as inherently interesting (perhaps because they are tagged releases)?
Now, the "e" case is the above trivial case: just mark any "inherently
interesting" commit with the TREECHANGE flag, and the history won't be
pruned away. So it now looks like
c
|
e <- faked "interesting"
|
f
however, the fact that you did the same to "d" means that we will have
that too on our list of "interesting" commits, even though we've pruned
away all of the history leading _from_ it, so the trivial algorithm would
actually result in
c
|
d e
\ /
f
in that case. We'd see "d" because it's somehow intrisically interesting,
but it ends up being shown as that "dead tip", because the merge that
would reach it was simplified away.
Is that what you'd want?
If so, then the appended trivial path should effectively do what you ask
for. It keeps all the revs you passed in as "interesting" whether they are
or not, so now you can effectively just pass in all the refs you want, and
it will never remove any of the positive refs you passed it.
If you want a commit that has a ref pointing to it be marked as
interesting only if we see it while parsing the tree, then you need to do
slightly more (in "rewrite_one()", you should look up whether that commit
has a ref pointing to it).
Linus
----
diff --git a/revision.c b/revision.c
index 713f27e..90d3764 100644
--- a/revision.c
+++ b/revision.c
@@ -149,7 +149,8 @@ static struct commit *get_commit_referen
if (flags & UNINTERESTING) {
mark_parents_uninteresting(commit);
revs->limited = 1;
- }
+ } else
+ object->flags |= TREECHANGE;
return commit;
}
^ permalink raw reply related
* git-applymbox fails to extract patch.
From: Dave Jones @ 2006-03-10 5:04 UTC (permalink / raw)
To: git
Since my munged versions of Linus' original apply-mbox scripts
no longer work on current git, I figured I'd try and use the
ones provided with it.
I'm totally confused as to what's going on here.
Here's what I'm trying to apply..
http://userweb.kernel.org/~davej/mbox.txt
And here's what happens..
(04:59:42:davej@hera:cpufreq)$ git-applymbox -k ~/Mail/mbox
1 patch(es) to process.
Applying ''
fatal: No changes
What am I missing ?
Dave
^ permalink raw reply
* Re: [PATCH] Add git-imap-send.
From: Mike McCormack @ 2006-03-10 4:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacbz7vod.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>>[imap]
>> Host = imap.server.com
>> User = bob
>> Password = pwd
>> Port = 143
>
> These I am not so sure. It _might_ make sense to have something
> like this under $HOME/. Isn't there an established convention
> for storing something like this for existing MUAs?
It seems better to keep all the configuration in the same place. It's
possible (although unlikely) that somebody uses two different IMAP
servers to send mail... maybe one for work and one for play?
I think it would also be good to be able to specify these as command
line options, as some people might be uncomfortable with having their
password in a file (though it would be better to use an ssh tunnel).
>>+ * As a special exception, mbsync may be linked with the OpenSSL library,
>>+ * despite that library's more restrictive license.
> Hmmm.
I'll remove this, and all the SSL specific code, as it also complicates
the Makefile and adds an extra dependency.
I've fixed all the other issues you pointed out, and will resend the patch.
Mike
^ permalink raw reply
* [PATCH] Describe how to add extra mail header lines in mail generated by git-format-patch.
From: Mike McCormack @ 2006-03-10 4:47 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 112 bytes --]
---
Documentation/git-format-patch.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
[-- Attachment #2: 38fb623a9fe06cb56f96ee1f25a64d576372f997.diff --]
[-- Type: text/x-patch, Size: 547 bytes --]
38fb623a9fe06cb56f96ee1f25a64d576372f997
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index bc85a62..7cc7faf 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -64,6 +64,15 @@ OPTIONS
Create attachments instead of inlining patches.
+CONFIGURATION
+-------------
+You can specify extra mail header lines to be added to each
+message in the repository configuration as follows:
+
+[format]
+ headers = "Organization: git-foo\n"
+
+
EXAMPLES
--------
^ permalink raw reply related
* [PATCH] Document the --attach flag.
From: Mike McCormack @ 2006-03-10 4:47 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 108 bytes --]
---
Documentation/git-format-patch.txt | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
[-- Attachment #2: 2dbe606be2d9fadb7d8e84f5fed0d1c4a34377b7.diff --]
[-- Type: text/x-patch, Size: 711 bytes --]
2dbe606be2d9fadb7d8e84f5fed0d1c4a34377b7
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index 7c467c5..bc85a62 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -9,7 +9,7 @@ git-format-patch - Prepare patches for e
SYNOPSIS
--------
[verse]
-'git-format-patch' [-n | -k] [-o <dir> | --stdout] [-s] [-c]
+'git-format-patch' [-n | -k] [-o <dir> | --stdout] [--attach] [-s] [-c]
[--diff-options] <his> [<mine>]
DESCRIPTION
@@ -60,6 +60,9 @@ OPTIONS
standard output, instead of saving them into a file per
patch and implies --mbox.
+--attach::
+ Create attachments instead of inlining patches.
+
EXAMPLES
--------
^ permalink raw reply related
* Re: git-rev-list feature request
From: Paul Mackerras @ 2006-03-10 4:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0603091950360.18022@g5.osdl.org>
Linus Torvalds writes:
> Yeah. I _think_ what you want is
>
> - phase 1: generate the current graph that we already do for
>
> git-rev-list --all ^cmit
>
> - phase 2: start at "cmit", and mark everything that refers to it as
> "show me" (including "cmit" itself, which was originally marked
> uninteresting)
I'm not sure if that's what I want. Is that how "git-rev-list -- foo"
works?
What I want is basically just what "git-rev-list -- foo" does, but
with some extra flexibility in choosing what commits are interesting -
that is, to be able to say that a commit is interesting if it affects
some file, has a reference under .git/refs, or if it is one of a set
of specified commits.
Paul.
^ permalink raw reply
* Re: git-rev-list feature request
From: Linus Torvalds @ 2006-03-10 4:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Paul Mackerras, git
In-Reply-To: <7vhd663owv.fsf@assigned-by-dhcp.cox.net>
On Thu, 9 Mar 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > So phase 1 already exists and was the hard part. phase 2 is just walking
> > the graph (that is now all in memory) from "cmit" using the "object->refs"
> > reverse references that got built up during phase 1.
>
> Eh,... what reverse references???
Heh. Exercise left to the reader. Right now we do only forward references
(and rev-list.c actually turns that off, since it has no use for them).
But doing reverse refs should be easy - in the same place we do the
forward ones. I'd suggest making "track_object_refs == -1" mean "reverse
refs".
(I think the only thing that uses forwards refs is fsck. Nobody else wants
them, or would prefer the reverse kind - since forwards refs you can
just look up yourself anyway).
Linus
^ permalink raw reply
* Re: git-rev-list feature request
From: Junio C Hamano @ 2006-03-10 4:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, git
In-Reply-To: <Pine.LNX.4.64.0603091950360.18022@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> So phase 1 already exists and was the hard part. phase 2 is just walking
> the graph (that is now all in memory) from "cmit" using the "object->refs"
> reverse references that got built up during phase 1.
Eh,... what reverse references???
^ permalink raw reply
* Re: git-rev-list feature request
From: Linus Torvalds @ 2006-03-10 3:56 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Junio C Hamano, git
In-Reply-To: <17424.53563.622642.738307@cargo.ozlabs.ibm.com>
On Fri, 10 Mar 2006, Paul Mackerras wrote:
>
> It would be nice also to be able to combine that with the existing
> ability to output a dense graph containing the commits that modify a
> specified set of files or directories.
>
> In other words, I would like to be able to select any combination of
> (a) some explicitly specified commits
> (b) commits that have a reference
> (c) commits that affect specified files or directories
>
> and have git-rev-list output a graph that shows the relationship of
> those commits.
>
> Possible?
Yeah. I _think_ what you want is
- phase 1: generate the current graph that we already do for
git-rev-list --all ^cmit
- phase 2: start at "cmit", and mark everything that refers to it as
"show me" (including "cmit" itself, which was originally marked
uninteresting)
So phase 1 already exists and was the hard part. phase 2 is just walking
the graph (that is now all in memory) from "cmit" using the "object->refs"
reverse references that got built up during phase 1.
The only question is how to show the ref-names, or, more properly, what to
do when we have a ref-name, but the commit it points to wasn't interesting
because it didn't change the set of files we used to determine interest...
And where to find the sucker^H^H^H^H^H^Hhelpful soul to actually do the
work.
Linus
^ permalink raw reply
* Re: [PATCH] allow double click on current HEAD id after git-pull
From: Petr Baudis @ 2006-03-10 1:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Olaf Hering, git
In-Reply-To: <7vy7zj2oom.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Fri, Mar 10, 2006 at 12:17:29AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> Well I kind of like ending a sentence with a full stop. Isn't
> this something you can do by confuguiring your cut&paste?
I wouldn't think cut'n'paste is usually that flexible and/or easy to
configure.
> But I do not have a _very_ strong feeling either way. If
> majority of the list wants it that way I do not mind.
Being able to easily cut'n'paste is IMHO an important usability thing,
and with that long sha1s, who's going to notice a missing fullstop far
at the right? ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* git-rev-list feature request
From: Paul Mackerras @ 2006-03-10 1:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
I'd like to implement a new features in gitk to enable it to show the
relationship of a given commit to the tags and other references. What
I would like is for git-rev-list to be able to output a dense graph
containing only one or more specified commits plus all the commits
that have a reference (i.e. a file under $GIT_DIR/refs that contains
their SHA1 ID), plus the merges that are needed to complete the
graph.
It would be nice also to be able to combine that with the existing
ability to output a dense graph containing the commits that modify a
specified set of files or directories.
In other words, I would like to be able to select any combination of
(a) some explicitly specified commits
(b) commits that have a reference
(c) commits that affect specified files or directories
and have git-rev-list output a graph that shows the relationship of
those commits.
Possible?
Thanks,
Paul.
^ permalink raw reply
* Re: [PATCH] allow double click on current HEAD id after git-pull
From: Mark Wooding @ 2006-03-10 0:49 UTC (permalink / raw)
To: git
In-Reply-To: <7vy7zj2oom.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Well I kind of like ending a sentence with a full stop. Isn't
> this something you can do by confuguiring your cut&paste?
Could do, but since . is a useful filename character it usually seems
like a good idea to include it in the set of characters considered a
`word' by the terminal double-click logic. I've not used xterm for
ages, but a quick check shows that Eterm isn't smart enough to be told
that . followed by a word-constituent is good and should be included in
a word, whereas a trailing . is a different thing which it doesn't want
to include.
So I'm in favour of killing the full-stops. Sorry. :-(
-- [mdw]
^ permalink raw reply
* Re: [PATCH] Add git-imap-send.
From: Mark Wooding @ 2006-03-10 0:38 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0603091445280.21440@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> I would be astonished if memcmp has to be timing proof for *all*
> applications, just to keep crypto people happy. I don't *want* a
> slow-down in my super-duper 3d shooter.
Oh, obviously that would be lunatic! ;-) Just making the point that it's
not /completely/ obvious that early stopping is what everyone wants...
-- [mdw]
^ 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