[Q] Abbreviated history graph?

[Q] Abbreviated history graph?

[Brian Foster]

Hello,

  A colleague and I recently wanted to examine the
 history in a broad sense without worrying too much
 about the individual commits.  What we (think we)
 wanted is a ‘gitk --all’ history graph showing only
 “named” historical points; i.e., tags and branch
 HEADs, perhaps with an indication of whether or not
 it's a “linear” change sequence that leads from one
 to another.  That is, hypothetically, if the history
 looks something like (where ‘A’ &tc has a name as
 per above, and ‘*’ does not):

     A--->*--->*--->C--->D--->*----->E
      \                   \         /
       \->*-->B            \->*--->*--->F

 What we wanted to see is something like:

     A------>C--->D--->E
      \       \       /
       \->B    \-----/--->F

 Is there some way of doing something similar to that
 (git v1.6.0.2)?  In addition to ‘gitk’, we also (rather
 quickly!) tried both ‘qgit’ and ‘giggle’, but without
 any apparent success.

cheers!
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

Re: [Q] Abbreviated history graph?

[Santi Béjar]

[-- Attachment #1: Type: text/plain, Size: 2075 bytes --]

On Mon, Nov 3, 2008 at 2:39 PM, Brian Foster
<brian.foster@innova-card.com> wrote:
>
> Hello,
>
>  A colleague and I recently wanted to examine the
>  history in a broad sense without worrying too much
>  about the individual commits.  What we (think we)
>  wanted is a 'gitk --all' history graph showing only
>  "named" historical points; i.e., tags and branch
>  HEADs, perhaps with an indication of whether or not
>  it's a "linear" change sequence that leads from one
>  to another.  That is, hypothetically, if the history
>  looks something like (where 'A' &tc has a name as
>  per above, and '*' does not):
>
>     A--->*--->*--->C--->D--->*----->E
>      \                   \         /
>       \->*-->B            \->*--->*--->F
>
>  What we wanted to see is something like:
>
>     A------>C--->D--->E
>      \       \       /
>       \->B    \-----/--->F
>
>  Is there some way of doing something similar to that
>  (git v1.6.0.2)?  In addition to 'gitk', we also (rather
>  quickly!) tried both 'qgit' and 'giggle', but without
>  any apparent success.

Not in git.git but you can use the script at the bottom (also attached
in case it is whitespace damage).
It could be much faster if "git log" stops when finding a tag/branch.

HTH,
Santi

[git-overview]
#!/bin/sh

TMP=$(mktemp -t git-overview.XXXXXXXXXXX)
trap 'rm -f "$TMP"' 0 1 2 3 15

git log --reverse --pretty=short --decorate --pretty=format:%H%d $@ |\
    awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | \
    while read hash ; do
    # Independent tags/branches parents:
    # Notes:
    #   * -n 1000 to limit the search, ideally "git log" could stop
    #     traversing the history when hits a tag/branch tip
    #   * head -n 25 because "git show-branch --independent" has this limit
    ancestors=$(git log -n 1000 --pretty=short --decorate
--pretty=format:%H%d $hash^@ |\
    awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | head -n 25)
    if [ -n "$ancestors" ] ; then
	echo $hash $(git show-branch --independent $ancestors)
    else
	echo $hash
    fi
done > $TMP
GIT_GRAFT_FILE=$TMP gitk "$@" -d

[-- Attachment #2: git-overview --]
[-- Type: application/octet-stream, Size: 806 bytes --]

#!/bin/sh

TMP=$(mktemp -t git-overview.XXXXXXXXXXX)
trap 'rm -f "$TMP"' 0 1 2 3 15

git log --reverse --pretty=short --decorate --pretty=format:%H%d $@ |\
    awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | \
    while read hash ; do
    # Independent tags/branches parents:
    # Notes:
    #   * -n 1000 to limit the search, ideally "git log" could stop
    #     traversing the history when hits a tag/branch tip
    #   * head -n 25 because "git show-branch --independent" has this limit
    ancestors=$(git log -n 1000 --pretty=short --decorate --pretty=format:%H%d $hash^@ |\
    awk 'BEGIN {FS="[ ,()]*"} NF>=2 {print $1}' | head -n 25)
    if [ -n "$ancestors" ] ; then
	echo $hash $(git show-branch --independent $ancestors)
    else
	echo $hash
    fi
done > $TMP
GIT_GRAFT_FILE=$TMP gitk "$@" -d

Re: [Q] Abbreviated history graph?

[Santi Béjar]

On Mon, Nov 3, 2008 at 3:20 PM, Santi Béjar <santi@agolina.net> wrote:
> On Mon, Nov 3, 2008 at 2:39 PM, Brian Foster
> <brian.foster@innova-card.com> wrote:
>>
>> Hello,
>>
>>  A colleague and I recently wanted to examine the
>>  history in a broad sense without worrying too much
>>  about the individual commits.  What we (think we)
>>  wanted is a 'gitk --all' history graph showing only
>>  "named" historical points; i.e., tags and branch
>>  HEADs, perhaps with an indication of whether or not
>>  it's a "linear" change sequence that leads from one
>>  to another.  That is, hypothetically, if the history
>>  looks something like (where 'A' &tc has a name as
>>  per above, and '*' does not):
>>
>>     A--->*--->*--->C--->D--->*----->E
>>      \                   \         /
>>       \->*-->B            \->*--->*--->F
>>
>>  What we wanted to see is something like:
>>
>>     A------>C--->D--->E
>>      \       \       /
>>       \->B    \-----/--->F
>>
>>  Is there some way of doing something similar to that
>>  (git v1.6.0.2)?  In addition to 'gitk', we also (rather
>>  quickly!) tried both 'qgit' and 'giggle', but without
>>  any apparent success.
>
> Not in git.git but you can use the script at the bottom (also attached
> in case it is whitespace damage).
> It could be much faster if "git log" stops when finding a tag/branch.
>

Just to add that it would be great if gitk's "List references" showed
them in this way (possibly with a toggle to show them in alphabetical
order).

Santi

Re: [Q] Abbreviated history graph?

[Brian Foster]

On Monday 03 November 2008 15:20:30 Santi Béjar wrote:
>[ ... ]
> >  Is there some way of doing something similar [ the example ]
> >  (git v1.6.0.2)?  In addition to 'gitk', we also (rather
> >  quickly!) tried both 'qgit' and 'giggle', but without
> >  any apparent success.
> 
> Not in git.git but you can use the script at the bottom [ ... ].

Santi,

   Thanks.  Unfortunately, neither I nor my colleague can try
  it at the moment:  It uses  `git log --pretty=format:%d'
  which is very new (added c.9-Sept) and not in the versions
  of git we are currently using.  End result is the tempfile
  is always empty, and hence `gitk' shows everything.

cheers!
	-blf-

-- 
“How many surrealists does it take to   | Brian Foster
 change a lightbulb? Three. One calms   | somewhere in south of France
 the warthog, and two fill the bathtub  |   Stop E$$o (ExxonMobil)!
 with brightly-coloured machine tools.” |      http://www.stopesso.com

Re: [Q] Abbreviated history graph?

[Santi Béjar]

On Mon, Nov 3, 2008 at 4:46 PM, Brian Foster
<brian.foster@innova-card.com> wrote:
> On Monday 03 November 2008 15:20:30 Santi Béjar wrote:
>>[ ... ]
>> >  Is there some way of doing something similar [ the example ]
>> >  (git v1.6.0.2)?  In addition to 'gitk', we also (rather
>> >  quickly!) tried both 'qgit' and 'giggle', but without
>> >  any apparent success.
>>
>> Not in git.git but you can use the script at the bottom [ ... ].
>
> Santi,
>
>   Thanks.  Unfortunately, neither I nor my colleague can try
>  it at the moment:  It uses  `git log --pretty=format:%d'
>  which is very new (added c.9-Sept) and not in the versions
>  of git we are currently using.  End result is the tempfile
>  is always empty, and hence `gitk' shows everything.


Ups! So you could get the same information with the uglier (and slower):

$ git log --reverse --pretty=short --decorate | grep ^commit

but then you should change "NF>=2" with "NF>=3", or use an older one I
sent to the list (search for git-overview).

Santi

Re: [Q] Abbreviated history graph?

[Linus Torvalds]

On Mon, 3 Nov 2008, Brian Foster wrote:
> 
>   A colleague and I recently wanted to examine the
>  history in a broad sense without worrying too much
>  about the individual commits.  What we (think we)
>  wanted is a ‘gitk --all’ history graph showing only
>  “named” historical points;

Ok, this is actually really easy to do with git. We have all the 
infrastructure in place, and what you're asking for is fundamentally 
really just an odd form of commit history simplification. Instead of 
comparing the *contents* of the commits (the trees) to see if they are 
interesting, you'd only check if there is a decoration (ie a tag or a 
branch) pointing to the commit.

I'll post a simple series of four commits in a moment. They're all 
trivial, and the first three are just setting stuff up (in fact, the very 
first one is a commit I've already posted, and it's technically totally 
unrelated, but since it touches the same area as one of the other ones, 
I'm too lazy to try to separate it out).

Patchbombing to commence in 5.. 4.. 3.. 2.. 1..

		Linus

[PATCH 1/4] Add a 'source' decorator for commits

[Linus Torvalds]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon, 27 Oct 2008 12:51:59 -0700

We already support decorating commits by tags or branches that point to
them, but especially when we are looking at multiple branches together,
we sometimes want to see _how_ we reached a particular commit.

We can abuse the '->util' field in the commit to keep track of that as
we walk the commit lists, and get a reasonably useful view into which
branch or tag first reaches that commit.

Of course, if the commit is reachable through multiple sources (which is
common), our particular choice of "first" reachable is entirely random
and depends on the particular path we happened to follow.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---

This is strictly unrelated to the rest, but as mentioned, it touches the 
same areas, and I'm too lazy to split it out. I had it in my tree. It 
won't hurt.

 builtin-log.c      |    2 ++
 builtin-rev-list.c |    2 +-
 log-tree.c         |    8 +++++---
 log-tree.h         |    2 +-
 revision.c         |    4 ++++
 revision.h         |    1 +
 6 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index a0944f7..176cbce 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -56,6 +56,8 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
 		if (!strcmp(arg, "--decorate")) {
 			load_ref_decorations();
 			decorate = 1;
+		} else if (!strcmp(arg, "--source")) {
+			rev->show_source = 1;
 		} else
 			die("unrecognized argument: %s", arg);
 	}
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 06cdeb7..857742a 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -100,7 +100,7 @@ static void show_commit(struct commit *commit)
 			children = children->next;
 		}
 	}
-	show_decorations(commit);
+	show_decorations(&revs, commit);
 	if (revs.commit_format == CMIT_FMT_ONELINE)
 		putchar(' ');
 	else
diff --git a/log-tree.c b/log-tree.c
index cec3c06..cf7947b 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -52,11 +52,13 @@ static void show_parents(struct commit *commit, int abbrev)
 	}
 }
 
-void show_decorations(struct commit *commit)
+void show_decorations(struct rev_info *opt, struct commit *commit)
 {
 	const char *prefix;
 	struct name_decoration *decoration;
 
+	if (opt->show_source && commit->util)
+		printf(" %s", (char *) commit->util);
 	decoration = lookup_decoration(&name_decoration, &commit->object);
 	if (!decoration)
 		return;
@@ -279,7 +281,7 @@ void show_log(struct rev_info *opt)
 		fputs(diff_unique_abbrev(commit->object.sha1, abbrev_commit), stdout);
 		if (opt->print_parents)
 			show_parents(commit, abbrev_commit);
-		show_decorations(commit);
+		show_decorations(opt, commit);
 		if (opt->graph && !graph_is_commit_finished(opt->graph)) {
 			putchar('\n');
 			graph_show_remainder(opt->graph);
@@ -352,7 +354,7 @@ void show_log(struct rev_info *opt)
 			printf(" (from %s)",
 			       diff_unique_abbrev(parent->object.sha1,
 						  abbrev_commit));
-		show_decorations(commit);
+		show_decorations(opt, commit);
 		printf("%s", diff_get_color_opt(&opt->diffopt, DIFF_RESET));
 		if (opt->commit_format == CMIT_FMT_ONELINE) {
 			putchar(' ');
diff --git a/log-tree.h b/log-tree.h
index 3c8127b..f2a9008 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -12,7 +12,7 @@ int log_tree_diff_flush(struct rev_info *);
 int log_tree_commit(struct rev_info *, struct commit *);
 int log_tree_opt_parse(struct rev_info *, const char **, int);
 void show_log(struct rev_info *opt);
-void show_decorations(struct commit *commit);
+void show_decorations(struct rev_info *opt, struct commit *commit);
 void log_write_email_headers(struct rev_info *opt, const char *name,
 			     const char **subject_p,
 			     const char **extra_headers_p,
diff --git a/revision.c b/revision.c
index 2f646de..d45f05a 100644
--- a/revision.c
+++ b/revision.c
@@ -199,6 +199,8 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object
 			mark_parents_uninteresting(commit);
 			revs->limited = 1;
 		}
+		if (revs->show_source && !commit->util)
+			commit->util = (void *) name;
 		return commit;
 	}
 
@@ -484,6 +486,8 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
 
 		if (parse_commit(p) < 0)
 			return -1;
+		if (revs->show_source && !p->util)
+			p->util = commit->util;
 		p->object.flags |= left_flag;
 		if (!(p->object.flags & SEEN)) {
 			p->object.flags |= SEEN;
diff --git a/revision.h b/revision.h
index 2fdb2dd..51a4863 100644
--- a/revision.h
+++ b/revision.h
@@ -53,6 +53,7 @@ struct rev_info {
 			left_right:1,
 			rewrite_parents:1,
 			print_parents:1,
+			show_source:1,
 			reverse:1,
 			reverse_output_stage:1,
 			cherry_pick:1,
-- 
1.6.0.3.616.gf1239d6.dirty

[PATCH 2/4] revision: make tree comparison functions take commits rather than trees

[Linus Torvalds]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon, 3 Nov 2008 10:45:41 -0800
Subject: [PATCH 2/4] revision: make tree comparison functions take commits rather than trees

This will make it easier to do various clever things that don't depend
on the pure tree contents.  It also makes the parameter passing much
simpler - the callers doesn't really look at trees anywhere else, and
it's really the function that should look at the low-level details.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---

This is a trivial no-op change that just passes commits instead of trees 
to the commit compare functions. The whole point is that we can now start 
comparing them based on not just contents of the trees, but other 
attributes too.

The patch makes no semantic changes. Just preparation.

 revision.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/revision.c b/revision.c
index d45f05a..56b09eb 100644
--- a/revision.c
+++ b/revision.c
@@ -294,8 +294,11 @@ static void file_change(struct diff_options *options,
 	DIFF_OPT_SET(options, HAS_CHANGES);
 }
 
-static int rev_compare_tree(struct rev_info *revs, struct tree *t1, struct tree *t2)
+static int rev_compare_tree(struct rev_info *revs, struct commit *parent, struct commit *commit)
 {
+	struct tree *t1 = parent->tree;
+	struct tree *t2 = commit->tree;
+
 	if (!t1)
 		return REV_TREE_NEW;
 	if (!t2)
@@ -308,12 +311,13 @@ static int rev_compare_tree(struct rev_info *revs, struct tree *t1, struct tree
 	return tree_difference;
 }
 
-static int rev_same_tree_as_empty(struct rev_info *revs, struct tree *t1)
+static int rev_same_tree_as_empty(struct rev_info *revs, struct commit *commit)
 {
 	int retval;
 	void *tree;
 	unsigned long size;
 	struct tree_desc empty, real;
+	struct tree *t1 = commit->tree;
 
 	if (!t1)
 		return 0;
@@ -347,7 +351,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
 		return;
 
 	if (!commit->parents) {
-		if (rev_same_tree_as_empty(revs, commit->tree))
+		if (rev_same_tree_as_empty(revs, commit))
 			commit->object.flags |= TREESAME;
 		return;
 	}
@@ -367,7 +371,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
 			die("cannot simplify commit %s (because of %s)",
 			    sha1_to_hex(commit->object.sha1),
 			    sha1_to_hex(p->object.sha1));
-		switch (rev_compare_tree(revs, p->tree, commit->tree)) {
+		switch (rev_compare_tree(revs, p, commit)) {
 		case REV_TREE_SAME:
 			tree_same = 1;
 			if (!revs->simplify_history || (p->object.flags & UNINTERESTING)) {
@@ -387,7 +391,7 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
 
 		case REV_TREE_NEW:
 			if (revs->remove_empty_trees &&
-			    rev_same_tree_as_empty(revs, p->tree)) {
+			    rev_same_tree_as_empty(revs, p)) {
 				/* We are adding all the specified
 				 * paths from this parent, so the
 				 * history beyond this parent is not
-- 
1.6.0.3.616.gf1239d6.dirty

[PATCH 3/4] Make '--decorate' set an explicit 'show_decorations' flag

[Linus Torvalds]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon, 3 Nov 2008 11:23:57 -0800
Subject: [PATCH 3/4] Make '--decorate' set an explicit 'show_decorations' flag

We will want to add decorations without necessarily showing them, so add
an explicit revisions info flag as to whether we're showing decorations
or not.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---

Another really trivial preparatory patch. Instead of writing to a totally 
unused and pointless local variable (yeah, don't ask me why it does that, 
it's probably my brainfart from long ago), set a "revs->show_decorations" 
flag that we actually _use_ to decide if we want to show decorations or 
not when outputting logs.

This makes no semantic difference, since there are only two users of 
decorations:
 - format_decoration() which does everything by hand
 - show_decorations() that now looks at the flag that we set when we 
   preload them.

It _will_ matter in the next commit, though. Because soon we'll start 
loading decorations without actually wanting to necessarily show them!

 builtin-log.c |    3 +--
 log-tree.c    |    2 ++
 revision.h    |    1 +
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/builtin-log.c b/builtin-log.c
index 176cbce..82ea07b 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -28,7 +28,6 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
 		      struct rev_info *rev)
 {
 	int i;
-	int decorate = 0;
 
 	rev->abbrev = DEFAULT_ABBREV;
 	rev->commit_format = CMIT_FMT_DEFAULT;
@@ -55,7 +54,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
 		const char *arg = argv[i];
 		if (!strcmp(arg, "--decorate")) {
 			load_ref_decorations();
-			decorate = 1;
+			rev->show_decorations = 1;
 		} else if (!strcmp(arg, "--source")) {
 			rev->show_source = 1;
 		} else
diff --git a/log-tree.c b/log-tree.c
index cf7947b..5444f08 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -59,6 +59,8 @@ void show_decorations(struct rev_info *opt, struct commit *commit)
 
 	if (opt->show_source && commit->util)
 		printf(" %s", (char *) commit->util);
+	if (!opt->show_decorations)
+		return;
 	decoration = lookup_decoration(&name_decoration, &commit->object);
 	if (!decoration)
 		return;
diff --git a/revision.h b/revision.h
index 51a4863..0a1806a 100644
--- a/revision.h
+++ b/revision.h
@@ -54,6 +54,7 @@ struct rev_info {
 			rewrite_parents:1,
 			print_parents:1,
 			show_source:1,
+			show_decorations:1,
 			reverse:1,
 			reverse_output_stage:1,
 			cherry_pick:1,
-- 
1.6.0.3.616.gf1239d6.dirty

[PATCH 4/4] Add support for 'namespace' history simplification

[Linus Torvalds]

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Mon, 3 Nov 2008 11:25:46 -0800
Subject: [PATCH 4/4] Add support for 'namespace' history simplification

Maybe this is mis-named, but what it does is to simplify history not by
the contents of the tree, but whether a commit has been named (ie it's
referred to by some branch or tag) or not.

This makes it possible to see the relationship between different named
commits, without actually seeing any of the details.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---

This is the actual real meat of the logic, and it's really trivial. The 
actual code is really just a simple

    if (simplify-by-namespace)
        return lookup_decoration(..) ? REV_TREE_DIFFERENT : REV_TREE_SAME;

but it's a few more lines of addition than that because of parsing the 
argument and setting the appropriate flags, and writing the above 
two-liner as five lines with a comment in order to make it more readable.

No docs. I don't do docs. But you can use it like so:

	gitk --simplify-namespace

and you're all done. 

Ta-daa!


 revision.c |   20 ++++++++++++++++++++
 revision.h |    1 +
 2 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/revision.c b/revision.c
index 56b09eb..b48e626 100644
--- a/revision.c
+++ b/revision.c
@@ -11,6 +11,7 @@
 #include "reflog-walk.h"
 #include "patch-ids.h"
 #include "decorate.h"
+#include "log-tree.h"
 
 volatile show_early_output_fn_t show_early_output;
 
@@ -301,6 +302,17 @@ static int rev_compare_tree(struct rev_info *revs, struct commit *parent, struct
 
 	if (!t1)
 		return REV_TREE_NEW;
+
+	/*
+	 * If we do history simplification by _name_, ignore the
+	 * actual tree contents, and just check if we have a
+	 * decoration
+	 */
+	if (revs->simplify_namespace) {
+		struct name_decoration *name;
+		name = lookup_decoration(&name_decoration, &commit->object);
+		return name ? REV_TREE_DIFFERENT : REV_TREE_SAME;
+	}
 	if (!t2)
 		return REV_TREE_DIFFERENT;
 	tree_difference = REV_TREE_SAME;
@@ -1041,6 +1053,14 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
 		revs->rewrite_parents = 1;
 		revs->simplify_history = 0;
 		revs->limited = 1;
+	} else if (!strcmp(arg, "--simplify-namespace")) {
+		revs->simplify_merges = 1;
+		revs->rewrite_parents = 1;
+		revs->simplify_history = 0;
+		revs->simplify_namespace = 1;
+		revs->limited = 1;
+		revs->prune = 1;
+		load_ref_decorations();
 	} else if (!strcmp(arg, "--date-order")) {
 		revs->lifo = 0;
 		revs->topo_order = 1;
diff --git a/revision.h b/revision.h
index 0a1806a..bd1ec0d 100644
--- a/revision.h
+++ b/revision.h
@@ -43,6 +43,7 @@ struct rev_info {
 			lifo:1,
 			topo_order:1,
 			simplify_merges:1,
+			simplify_namespace:1,
 			tag_objects:1,
 			tree_objects:1,
 			blob_objects:1,
-- 
1.6.0.3.616.gf1239d6.dirty

Re: [PATCH 4/4] Add support for 'namespace' history simplification

[Santi Béjar]

On Mon, Nov 3, 2008 at 8:43 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Mon, 3 Nov 2008 11:25:46 -0800
> Subject: [PATCH 4/4] Add support for 'namespace' history simplification
>
> Maybe this is mis-named, but what it does is to simplify history not by
> the contents of the tree, but whether a commit has been named (ie it's
> referred to by some branch or tag) or not.

Maybe --simplify-refs, or --simplify-overview.

>
> This makes it possible to see the relationship between different named
> commits, without actually seeing any of the details.
>
> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> ---
>
> This is the actual real meat of the logic, and it's really trivial. The
> actual code is really just a simple
>
>    if (simplify-by-namespace)
>        return lookup_decoration(..) ? REV_TREE_DIFFERENT : REV_TREE_SAME;

I tried it once, but I had problems simplifying the merges, and it is trivial...

Not that it matters a lot, but if you try it on master you get some
extra merges without a ref like:

373a273 (Merge git-gui 0.11.0, 2008-08-17)
f44bc33 (Sync with 1.5.6.5, 2008-08-06)

Thanks,
Santi

Re: [PATCH 4/4] Add support for 'namespace' history simplification

[Linus Torvalds]

On Mon, 3 Nov 2008, Santi Béjar wrote:
> 
> I tried it once, but I had problems simplifying the merges, and it is trivial...

It depends on the new --simplify-merges code which does that.

> Not that it matters a lot, but if you try it on master you get some
> extra merges without a ref like:
> 
> 373a273 (Merge git-gui 0.11.0, 2008-08-17)

Umm? Your point is?

That merge itself doesn't have a ref, but it's required becase there are 
refs along both legs of the merge - one side has the "gitgui-0.11.0" tag, 
while the other has (for example) v16.0-rc3.

> f44bc33 (Sync with 1.5.6.5, 2008-08-06)

Again, the merge doesn't have a ref, but it's needed because there are 
refs on both parents (v1.5.6.5 vs v1.6.0-rc[01]).

So no, --simplify-namespace in no way guarantees that all resulting 
commits will have refs pointing to them, because it also needs to return 
enough of the merges to make it a real and meaningful DAG.

The one thing I note is that when you have lots and lots of refs in the 
gitk output, the gitk window itself becomes very ugly. I'd love to get rid 
of the black line between the ref (tag or branch name) and the circle, 
because with "gitk --simplify-namespace" it ends up looking like some kind 
of insane "ladder" due to all those vertical lines.

And they really aren't necessary, and it would probably be better to just 
make selecting a commit highlight the whole row (and thus avoid any 
ambiguity between that highlighted commit message and the circle in the 
graph it goes with if you have a very wide graph).

But I can't read tcl/tk enough to even figure out where it's being 
painted.

			Linus

Re: [PATCH 4/4] Add support for 'namespace' history simplification

[Santi Béjar]

On Mon, Nov 3, 2008 at 11:05 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>
> On Mon, 3 Nov 2008, Santi Béjar wrote:
>>
>> I tried it once, but I had problems simplifying the merges, and it is trivial...
>
> It depends on the new --simplify-merges code which does that.
>
>> Not that it matters a lot, but if you try it on master you get some
>> extra merges without a ref like:
>>
>> 373a273 (Merge git-gui 0.11.0, 2008-08-17)
>
> Umm? Your point is?
>
> That merge itself doesn't have a ref, but it's required becase there are
> refs along both legs of the merge - one side has the "gitgui-0.11.0" tag,
> while the other has (for example) v16.0-rc3.
>
>> f44bc33 (Sync with 1.5.6.5, 2008-08-06)
>
> Again, the merge doesn't have a ref, but it's needed because there are
> refs on both parents (v1.5.6.5 vs v1.6.0-rc[01]).
>
> So no, --simplify-namespace in no way guarantees that all resulting
> commits will have refs pointing to them, because it also needs to return
> enough of the merges to make it a real and meaningful DAG.

I thought of it as "for each ref rewrite its parents to the
independent set of refs that are ancestors". So in the case of 373a273
(Merge git-gui 0.11.0, 2008-08-17), its parents (gitgui-0.11.0 and
v1.6.0-rc3) would be the parents of ea02eef (GIT 1.6.0, 2008-08-17).

Santi

Re: [PATCH 4/4] Add support for 'namespace' history simplification

[Robin Rosenberg]

måndag 03 november 2008 20:43:00 skrev Linus Torvalds:
> 
> From: Linus Torvalds <torvalds@linux-foundation.org>
> Date: Mon, 3 Nov 2008 11:25:46 -0800
> Subject: [PATCH 4/4] Add support for 'namespace' history simplification
> 
> Maybe this is mis-named, but what it does is to simplify history not by
> the contents of the tree, but whether a commit has been named (ie it's
> referred to by some branch or tag) or not.

You could reuse the decoration term here, i.e. --simplify-decorated.

-- robin

Re: [PATCH 4/4] Add support for 'namespace' history simplification

[Clemens Buchacher]

On Mon, Nov 03, 2008 at 11:43:00AM -0800, Linus Torvalds wrote:
> 	gitk --simplify-namespace

Very nice. git log --graph seems to give slightly different results though.
In particular, in git.git if I do

git for-each-ref --format="%(refname)" refs/remotes/origin | \
xargs git log --simplify-namespace --graph --pretty='format:%H%n' | \
git name-rev --stdin --name-only | \
less

some of the history is not connected. Is this a known limitation of
git log --graph?

Re: [Q] Abbreviated history graph?

[Linus Torvalds]

On Mon, 3 Nov 2008, Linus Torvalds wrote:
>
> I'll post a simple series of four commits in a moment. They're all 
> trivial, and the first three are just setting stuff up (in fact, the very 
> first one is a commit I've already posted, and it's technically totally 
> unrelated, but since it touches the same area as one of the other ones, 
> I'm too lazy to try to separate it out).

Side note: it's certainly possible that we could improve on this. Right 
now, "--simplify-namespace" will totally override any path simplification, 
so you can't get a combination of pathnames _and_ naming commits. I don't 
know exactly what the rules should be, but I could imagine that we could 
do something like:

 - if no pathnames are given, work the way the current patch-series works.

 - if path-names are given, make rev_compare_tree() truen 
   REV_TREE_DIFFERENT if a name decoration _or_ a tree difference exists.

Anyway, that's a fairly trivial extension to the idea, and doesn't really 
matter for the basic code. It can easily be left for later.

		Linus

Re: [Q] Abbreviated history graph?

[Linus Torvalds]

On Mon, 3 Nov 2008, Linus Torvalds wrote:
> 
> Side note: it's certainly possible that we could improve on this. Right 
> now, "--simplify-namespace" will totally override any path simplification, 
> so you can't get a combination of pathnames _and_ naming commits. I don't 
> know exactly what the rules should be, but I could imagine that we could 
> do something like:
> 
>  - if no pathnames are given, work the way the current patch-series works.
> 
>  - if path-names are given, make rev_compare_tree() truen 
>    REV_TREE_DIFFERENT if a name decoration _or_ a tree difference exists.

The incremental diff to do this would be something like the appended.

		Linus
---
 revision.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/revision.c b/revision.c
index b48e626..1b716c7 100644
--- a/revision.c
+++ b/revision.c
@@ -311,7 +311,10 @@ static int rev_compare_tree(struct rev_info *revs, struct commit *parent, struct
 	if (revs->simplify_namespace) {
 		struct name_decoration *name;
 		name = lookup_decoration(&name_decoration, &commit->object);
-		return name ? REV_TREE_DIFFERENT : REV_TREE_SAME;
+		if (name)
+			return REV_TREE_DIFFERENT;
+		if (!revs->prune_data)
+			return REV_TREE_SAME;
 	}
 	if (!t2)
 		return REV_TREE_DIFFERENT;

Re: [Q] Abbreviated history graph?

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Mon, 3 Nov 2008, Linus Torvalds wrote:
>>
>> I'll post a simple series of four commits in a moment.
> ...
> Side note: it's certainly possible that we could improve on this. Right 
> now, "--simplify-namespace" will totally override any path simplification, 
> so you can't get a combination of pathnames _and_ naming commits. I don't 
> know exactly what the rules should be, but I could imagine that we could 
> do something like:
>
>  - if no pathnames are given, work the way the current patch-series works.
>
>  - if path-names are given, make rev_compare_tree() truen 
>    REV_TREE_DIFFERENT if a name decoration _or_ a tree difference exists.
>
> Anyway, that's a fairly trivial extension to the idea, and doesn't really 
> matter for the basic code. It can easily be left for later.

Thanks.

Including this (and the --source one), the series looks reasonable.