Tentative built-in "git show"

Tentative built-in "git show"

[Linus Torvalds]

This uses the "--no-walk" flag that I never actually implemented (but I'm 
sure I mentioned it) to make "git show" be essentially the same thing as 
"git whatchanged --no-walk".

It just refuses to add more interesting parents to the revision walking 
history, so you don't actually get any history, you just get the commit 
you asked for.

I was going to add "--no-walk" as a real argument flag to git-rev-list 
too, but I'm not sure anybody actually needs it. Although it might be 
useful for porcelain, so I left the door open.

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

This is obviously against Junio's current "next" branch, which has the 
log/whatchanged unification.

That special-case of

	if (!strcmp(av[0], "show"...

is truly ugly, but it needs to happen after setup_revisions(), for all the 
same reasons that I suggested it might be a good idea to split up 
"init_revisions()" out of setup_revisions().

diff --git a/git.c b/git.c
index 939a34c..c87accf 100644
--- a/git.c
+++ b/git.c
@@ -363,6 +363,20 @@ static int cmd_whatchanged(int ac, const
 	return cmd_log_wc(ac, av, ep, &wcopt);
 }
 
+static int cmd_show(int ac, const char **av, char **ep)
+{
+	struct whatchanged_opt wcopt;
+
+	memset(&wcopt, 0, sizeof(wcopt));
+	wcopt.do_diff = 1;
+	init_log_tree_opt(&wcopt.logopt);
+	wcopt.logopt.ignore_merges = 0;
+	wcopt.logopt.combine_merges = 1;
+	wcopt.logopt.dense_combined_merges = 1;
+	wcopt.logopt.diffopt.recursive = 1;
+	return cmd_log_wc(ac, av, ep, &wcopt);
+}
+
 static void handle_internal_command(int argc, const char **argv, char **envp)
 {
 	const char *cmd = argv[0];
@@ -373,6 +387,7 @@ static void handle_internal_command(int 
 		{ "version", cmd_version },
 		{ "help", cmd_help },
 		{ "log", cmd_log },
+		{ "show", cmd_show },
 		{ "whatchanged", cmd_whatchanged },
 	};
 	int i;
diff --git a/log-tree.c b/log-tree.c
index cb0d0b1..17e976a 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -182,6 +182,8 @@ int parse_whatchanged_opt(int ac, const 
 	int left = 1;
 
 	ac = setup_revisions(ac, av, rev, "HEAD");
+	if (!strcmp(av[0], "show"))
+		rev->no_walk = 1;
 	while (1 < ac) {
 		const char *arg = av[1];
 		if (!strncmp(arg, "--pretty", 8)) {
diff --git a/log-tree.h b/log-tree.h
diff --git a/revision.c b/revision.c
index 0505f3f..0c3c392 100644
--- a/revision.c
+++ b/revision.c
@@ -375,6 +375,9 @@ static void add_parents_to_list(struct r
 	if (revs->prune_fn)
 		revs->prune_fn(revs, commit);
 
+	if (revs->no_walk)
+		return;
+
 	parent = commit->parents;
 	while (parent) {
 		struct commit *p = parent->item;
@@ -714,6 +717,8 @@ int setup_revisions(int argc, const char
 
 void prepare_revision_walk(struct rev_info *revs)
 {
+	if (revs->no_walk)
+		return;
 	sort_by_date(&revs->commits);
 	if (revs->limited)
 		limit_list(revs);
diff --git a/revision.h b/revision.h
index 8970b57..ff2a13e 100644
--- a/revision.h
+++ b/revision.h
@@ -26,6 +26,7 @@ struct rev_info {
 	/* Traversal flags */
 	unsigned int	dense:1,
 			no_merges:1,
+			no_walk:1,
 			remove_empty_trees:1,
 			lifo:1,
 			topo_order:1,

Re: Tentative built-in "git show"

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> This uses the "--no-walk" flag that I never actually implemented (but I'm 
> sure I mentioned it) to make "git show" be essentially the same thing as 
> "git whatchanged --no-walk".

I sometimes do "git show -4" myself, and wondered why defaulting
to "-n 1"is insufficient, but if you do something like this to
check the tip of each branch:

	git show master next pu

this may make sense.

Otherwise, it feels to me that (I haven't had caffeine nor
nicotine yet, so I need to re-think this later) log, show and
whatchanged are the same program in disguise with different set
of defaults.

        log		--pretty
        show		--pretty -n1 -p
        whatchanged	--pretty -r

... which implies that some of them might become historical
curiosity and no real reason to teach about each of them in the
tutorial.

Re: Tentative built-in "git show"

[Linus Torvalds]

On Sat, 15 Apr 2006, Junio C Hamano wrote:
> 
> I sometimes do "git show -4" myself, and wondered why defaulting
> to "-n 1"is insufficient

I detest -n1 for a variety of reasons, and giving multiple refs is just 
one of them.

The reason I like "--no-walk" is that it's conceptually much stronger, and 
more efficient. Remember how we tried to optimize "-1" (as used by gitweb) 
by adding magic special cases to get_revision()? And how they always ended
up being problematic because of how they interact with all the other 
options?

So we don't do it any more, and as a result, "git-rev-list -1 HEAD" will 
actually walk all the parents too.

In contrast, "--no-walk" just does exactly what you tell it: don't start 
walking the parents. It's kind of equivalent to -1 with one argument, but 
in the presense of path limiting it actually does the RightThing(tm), 
unlike -1.

Try this as a replacement for "git show":

	git log -1 kernel/
	git log --no-walk kernel/

on the current kernel source tree to see the difference. "--no-walk" gives 
the right answer (for some definition of "right"). While -1 gives a 
totally random answer that has nothing to do with the current HEAD (except 
that it's _reachable_ from the current HEAD).

So I think "-n 1" is fundamentally incompatible with "git show". Git 
"show" is "show _this_ commit". While "-1" fundamentally means "show the 
_first_ commit when you walk the tree". Which is really really 
fundamentally different.

In contrast "--no-walk" tells you exactly what it is about. Don't walk the 
tree. Show _this_ commit.

(Now, the reason I said 'for _some_ definition of "right"' is that the 
question about path limiting in the absense of commit walking is somewhat 
ambiguous. The current "git show" shows the commit regardless. My 
suggested patch will potentially prune the commit away, and if the 
specified commit does not touch the path, no commit is shown at all. 
Both make sense. While "git-rev-list -1" does _not_ make sense)

			Linus