merge summaries

merge summaries

[Steffen Prohaska]

It took me some time to figure out how to get summaries of the merged  
branch into merge messages. Finally I recognized that I simply need  
to set

	git-config merge.summary true


I have two questions:
1) Why isn't 'true' the default setting? The two probably most  
prominent git repositories, git and kernel, both use merge summaries.  
After some time working with git I started to wonder, how these guys  
create the nicely formatted branch summaries. If merge summaries are  
apparently best practice, why are they missing in my local merges?

2) Why does git-merge have a switch '--no-summary' to switch  
summaries off, but doesn't have a switch '--summary' to switch them  
on? After some time of searching for the solution I started to  
believe that Linus and Junio might use some shell magic to create  
their merge messages, which they pipe to git-merge's -m switch. This  
inconsistency made finding the simple solution even harder.

- Steffen

Re: merge summaries

[Linus Torvalds]

On Fri, 18 May 2007, Steffen Prohaska wrote:
>
> It took me some time to figure out how to get summaries of the merged branch
> into merge messages. Finally I recognized that I simply need to set
> 
> 	git-config merge.summary true

Yes.

> I have two questions:
> 1) Why isn't 'true' the default setting? The two probably most prominent git
> repositories, git and kernel, both use merge summaries.

Think about _who_ uses it for those two prominent repositories for a while.

[ pause, ponder here ]

In other words, "merge.summary" should be true ONLY FOR TOP-LEVEL 
MAINTAINERS.

Making it true for anybody else is almost always a bug. Yes, I and Junio 
have it enabled, but pretty much nobody else should, because if they pull 
from me or Junio in order to merge, their merge summaries would be exactly 
the wrong way around!

> 2) Why does git-merge have a switch '--no-summary' to switch summaries off,
> but doesn't have a switch '--summary' to switch them on?

Probably because "normal users" should never use summaries in the first 
place, so it's just not been an issue.

		Linus

Re: merge summaries

[Junio C Hamano]

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

>> I have two questions:
>> 1) Why isn't 'true' the default setting? The two probably most prominent git
>> repositories, git and kernel, both use merge summaries.
>
> Think about _who_ uses it for those two prominent repositories for a while.
>
> [ pause, ponder here ]
>
> In other words, "merge.summary" should be true ONLY FOR TOP-LEVEL 
> MAINTAINERS.
>
> Making it true for anybody else is almost always a bug. Yes, I and Junio 
> have it enabled, but pretty much nobody else should, because if they pull 
> from me or Junio in order to merge, their merge summaries would be exactly 
> the wrong way around!

This does not necessarily mean that your lieutenants should not
use merge.summary when they pull from other trees (or inside
their own repository to merge in the topics).  They need to
however disable it with --no-summary when they pull from you
when they choose to merge instead of rebase to adjust to the
updated infrastructure in your tree.

Re: merge summaries

[Linus Torvalds]

On Fri, 18 May 2007, Junio C Hamano wrote:
> 
> This does not necessarily mean that your lieutenants should not
> use merge.summary when they pull from other trees (or inside
> their own repository to merge in the topics).  They need to
> however disable it with --no-summary when they pull from you
> when they choose to merge instead of rebase to adjust to the
> updated infrastructure in your tree.

Yes, the problem is that people *will* get it wrong, so right now I'd 
discourage people from even trying to enable merge summaries unless they 
are the top-level maintainer.

Of course, we could have some heuristics to make it possibly work well 
enough in practice that we could make it useful to more people:

 - take the "merge.summary" field from the "remote" description for any 
   shorthand cases, always defaulting to "off" (regardless of what the 
   "merge.summary" config value is)

   End result: "git pull origin" would never generate a merge summary, 
   unless somebody explicitly sets

	[remote "origin"]
		mergesummary = true

 - use the "merge.summary" flag only for explicitly named remotes (and 
   possibly add "--summary" so that people can choose to never do it by 
   default, but do it explicitly for when they pull from a sublieutenant)

Hmm?

		Linus

Re: merge summaries

[J. Bruce Fields]

On Fri, May 18, 2007 at 12:13:02PM -0700, Linus Torvalds wrote:
> 
> On Fri, 18 May 2007, Junio C Hamano wrote:
> > 
> > This does not necessarily mean that your lieutenants should not
> > use merge.summary when they pull from other trees (or inside
> > their own repository to merge in the topics).  They need to
> > however disable it with --no-summary when they pull from you
> > when they choose to merge instead of rebase to adjust to the
> > updated infrastructure in your tree.
> 
> Yes, the problem is that people *will* get it wrong, so right now I'd 
> discourage people from even trying to enable merge summaries unless they 
> are the top-level maintainer.

I never quite understood what they're for--do they add any information
not already available in the history?  If not, and if people still find
them helpful anyway, then I dunno, it looks like a sign of some sort of
failure of our history display tools.

--b.

Re: merge summaries

[Linus Torvalds]

On Fri, 18 May 2007, J. Bruce Fields wrote:
> 
> I never quite understood what they're for--do they add any information
> not already available in the history?  If not, and if people still find
> them helpful anyway, then I dunno, it looks like a sign of some sort of
> failure of our history display tools.

I don't think they add much in the case of a graphical viewer, but for 
"git log", it does make it look nicer..

		Linus

Re: merge summaries

[Junio C Hamano]

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

> On Fri, 18 May 2007, J. Bruce Fields wrote:
>> 
>> I never quite understood what they're for--do they add any information
>> not already available in the history?  If not, and if people still find
>> them helpful anyway, then I dunno, it looks like a sign of some sort of
>> failure of our history display tools.
>
> I don't think they add much in the case of a graphical viewer, but for 
> "git log", it does make it look nicer..

Especially if you do "git log --first-parent" ;-).

Re: merge summaries

[Steffen Prohaska]

On May 18, 2007, at 8:47 PM, Junio C Hamano wrote:

>> Think about _who_ uses it for those two prominent repositories for  
>> a while.
>>
>> [ pause, ponder here ]
>>
>> In other words, "merge.summary" should be true ONLY FOR TOP-LEVEL
>> MAINTAINERS.
>>
>> Making it true for anybody else is almost always a bug. Yes, I and  
>> Junio
>> have it enabled, but pretty much nobody else should, because if  
>> they pull
>> from me or Junio in order to merge, their merge summaries would be  
>> exactly
>> the wrong way around!
>
> This does not necessarily mean that your lieutenants should not
> use merge.summary when they pull from other trees (or inside
> their own repository to merge in the topics).  They need to
> however disable it with --no-summary when they pull from you
> when they choose to merge instead of rebase to adjust to the
> updated infrastructure in your tree.

[ ... pondering ... ]

Apparently parents of merge commits are not fully equal and summaries
can help to browse the history of a branch. If summaries are enabled
"git log --first-parent" gives hints to all changes at least in
short-log form. Changes along the first-parent-path to the initial
commit are listed in full. All changes that were merged in are
listed in the summaries of the merge. This seems to be a useful feature.

But isn't this true for any branch and any merge. If someone pulls from
you or Junio and runs "git log --first-parent" why shouldn't he see
a summary of the changes that were pulled? At that point his branch's
first-parent-path to the initial commit would not touch the changes
pulled from you. So the summary could help.

What is so wrong if merge summaries of pulls from you were committed
to topic branches. Later when you pull such branches the summaries
shouldn't be a problem. A short-log of the topic branch wouldn't
contain the summaries.

Probably I do not fully understand what "the wrong way around" means.

- Steffen

Re: merge summaries

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> What is so wrong if merge summaries of pulls from you were committed
> to topic branches. Later when you pull such branches the summaries
> shouldn't be a problem. A short-log of the topic branch wouldn't
> contain the summaries.
>
> Probably I do not fully understand what "the wrong way around" means.

I think you understand it very well.

As long as you stay as a "pull-only" person, and will never ask
the upstream to pull back from you, what first parent log would
show would make perfectly good sense.  However, once a pull from
you by the upstream happens, the resulting history would get the
summary in the merge you did, which is totally unwanted --- the
upstream already had those summarized commits long time ago in
its history.

Re: merge summaries

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> What is so wrong if merge summaries of pulls from you were committed
>> to topic branches. Later when you pull such branches the summaries
>> shouldn't be a problem. A short-log of the topic branch wouldn't
>> contain the summaries.
>>
>> Probably I do not fully understand what "the wrong way around" means.
>
> I think you understand it very well.
>
> As long as you stay as a "pull-only" person, and will never ask
> the upstream to pull back from you, what first parent log would
> show would make perfectly good sense.  However, once a pull from
> you by the upstream happens, the resulting history would get the
> summary in the merge you did, which is totally unwanted --- the
> upstream already had those summarized commits long time ago in
> its history.

Having said that.

The criteria to decide "wanted vs unwanted" all boil down to
essentially the question of who "owns" the history.  Although
Linus often says that the point of distributed development is
that nobody is special, at the end of day, once you asked the
"upstream" to pull from you, your history becomes part of HIS
history, and at that point, when HE browses the history (which
he now thinks as HIS history), the summary shows the summary the
wrong way.  So in that sense, merge.summary is going against the
philosophy of distributedness.

The summary message is useful in a very short term (i.e. while
it is still near the tip of the branch and running "git log"),
but I think JBF is correct to point out that it is showing a
shortcoming of our history browsing tools.  The information
recorded there can easily be reproduced on the fly.  Whenever
you see a merge commit, you can choose one parent to base your
view of the history upon (typically the first parent), and
summarize commits that are reachable from other parents but not
from that parent (e.g. for a typical two-parent merge, you would
run "git short-log $commit^1..$commit^2").

Re: merge summaries

[Steffen Prohaska]

On May 19, 2007, at 10:20 PM, Junio C Hamano wrote:

> Junio C Hamano <junkio@cox.net> writes:
>
>> As long as you stay as a "pull-only" person, and will never ask
>> the upstream to pull back from you, what first parent log would
>> show would make perfectly good sense.  However, once a pull from
>> you by the upstream happens, the resulting history would get the
>> summary in the merge you did, which is totally unwanted --- the
>> upstream already had those summarized commits long time ago in
>> its history.

Why would the summary of the upstream-to-topic-merge be so harmful?
It would not change the summary message of a pull from topic back to
the upstream. Af far as I can see, merge commits do not contribute
to a summary message. However, when browsing the full log the summary
might be distracting because a single commit may be listed at
various places, although it was already in the upstream. This is
kind of ugly. ...


> The criteria to decide "wanted vs unwanted" all boil down to
> essentially the question of who "owns" the history.  Although
> Linus often says that the point of distributed development is
> that nobody is special, at the end of day, once you asked the
> "upstream" to pull from you, your history becomes part of HIS
> history, and at that point, when HE browses the history (which
> he now thinks as HIS history), the summary shows the summary the
> wrong way.  So in that sense, merge.summary is going against the
> philosophy of distributedness.

... I'd say you only "own" the history of a branch along its
first-parent-path to the initial commit. This is what you control
either by directly committing to the branch or by pulling other
branches.

Isn't the history along the first parents especially important because
it documents the functionality of the project? If I want to say  
something
about git at a certain point in time, I'd talk about master of the  
official
git repository. "git log --first-parent" in some sense completely
describes the history of git. At merges at least a summary of features
pulled from topic branches is given.

But this is true not only for the upstream master but for every branch.
The first-parent-path of any commit documents (at least in summaries)
which features were introduced to the branch at which place. If a
topic pulls from upstream, features already available in the upstream
are introduced to the topic at this time. Why not summarize this?


> The summary message is useful in a very short term (i.e. while
> it is still near the tip of the branch and running "git log"),
> but I think JBF is correct to point out that it is showing a
> shortcoming of our history browsing tools.  The information
> recorded there can easily be reproduced on the fly.  Whenever
> you see a merge commit, you can choose one parent to base your
> view of the history upon (typically the first parent), and
> summarize commits that are reachable from other parents but not
> from that parent (e.g. for a typical two-parent merge, you would
> run "git short-log $commit^1..$commit^2").

I find the summary messages quite useful when browsing merges. The  
summary
allows to quickly locate the branch that was merged at that point.  
You just
look at the list of summaries and locate the mentioned commits in gitk.

Minimal merge messages like "Merge branch 'maint' of URL into maint" are
much harder to understand. The branches mentioned in the message do  
no longer
have any meaning. They either ceased to exist or advanced to  
somewhere else.
The URL typically means nothing to me, although it may have meant a  
lot to
the one who pulled at the time of the pull. Such minimal messages do
not help browsing history.

It would probably be more useful to name the merged branch by the  
summary
of its head at the time of the merge. For example
"Merge branch 'user-manual: reorganize public git repo discussion'"
would give more hints where to continue browsing than
"Merge branch 'maint' of URL into maint".

- Steffen

Re: merge summaries

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> But this is true not only for the upstream master but for every branch.
> The first-parent-path of any commit documents (at least in summaries)
> which features were introduced to the branch at which place. If a
> topic pulls from upstream, features already available in the upstream
> are introduced to the topic at this time. Why not summarize this?

Strictly speaking, it is not even correct with the upstream
master.  I believe even my own 'maint' has fast forward merge
that I pulled from other people, and that part of the history if
you follow first-parent, you would not be following the "project's"
history (if there is such a thing, and if you are equating it
with "JC's view of the history").

Re: merge summaries

[Junio C Hamano]

Junio C Hamano <junkio@cox.net> writes:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> But this is true not only for the upstream master but for every branch.
>> The first-parent-path of any commit documents (at least in summaries)
>> which features were introduced to the branch at which place. If a
>> topic pulls from upstream, features already available in the upstream
>> are introduced to the topic at this time. Why not summarize this?

Because it does not matter from the overall picture at that
point.  In an earlier message I said that the summary is useful
in a very short term -- the summary messages are useful while
the person who did the merge (or somebody who is simply
following him) is looking at near the tip of the branch, but
when you are later viewing the older parts of the history from
10,000 feet above, the distinction between what were pulled into
the local branch of the person who made the merge vs what the
person already had on the branch when he made the merge becomes
more or less irrelevant.  The end result is that the project now
got the fruits of labor that happened on both sides.

> Strictly speaking, it is not even correct with the upstream
> master.  I believe even my own 'maint' has fast forward merge
> that I pulled from other people, and that part of the history if
> you follow first-parent, you would not be following the "project's"
> history (if there is such a thing, and if you are equating it
> with "JC's view of the history").

Regrettably, I have to say that --first-parent is, although it is
often a useful way to get an approximation, a bad option that
tends to instill a wrong mental model to people new to git.

In git, unlike CVS and SVN (I do not know now Monotone,
Mercurial and BitKeeper's branches work with this respect),
branches in git do not have their "own" identity in global
history that is recorded in the commit ancestry graph.  The only
way you can ask "how did this branch come about to this state?"
is to look at your own reflog, and that is strictly a local
thing (i.e. the history as you observed it).

Even when you are "the upstream maintainer" [*1*], there are
cases where you pushed your tips out to the open, other people
built their work on top of it while you were not adding anything
to your tree, and you end up pulling from them.  Such a pull
will result in a fast-forward merge, and that is rightly so.
They did all the work, and the collective history of the project
during that time literally followed what the other person did,
not the "upstream maintainer".  However, from the point of view
of somebody who is following the upstream maintainer's tree,
what he would observe is that at one point of the time the tip
of the tree was the last commit the upstream maintainer pushed
out (which became the base of the other person's work), and then
the next time you look at the tree there are bunch of commits by
the other person, appearing all at once even though there is no
"real" merge commit that summarizes the work done on the "side
branch".  Which some of the readers might feel a bit confusing
and inconsistent, but that is really the correct interpretation
of the history.  The reason I feel --first-parent helps this
confusion is that people would think it would be consistent if
we do not allow fast-forward merges and instead always forced a
real merge in such a case (then you would consistently get the
merge summary).  In other words, the first parent is not
inherently special -- and people should view history that way,
but --first-parent and merge.summary give this false impression
that it is somehow special.

Anyhow, enough rambling for a day.  Now I have two releases
to do tonight ;-)

[Footnote]

*1* In git, strictly speaking, there is no up or down, but as a
social convention, I get updates from Shawn, Paulus, Bruce and
few other people via pull, and it would not be too incorrect to
say I'm more upstream than they are, and all others are more
downstream.

[PATCH] rev-list: '--indent' oneline output

[Steffen Prohaska]

Summaries in oneline output are indented to show the location of
parents in merge commits. Indentation level is computed as the
smallest sum of parent locations along all paths that reach the
commit.

As a result, the output of
    git-rev-list --pretty=oneline --topo-order --indent
is formatted in a way that resembles merge summaries. All commits that
were pulled from a branch are indented with one additional space below
the summary of the merge commit.

WARNING: this patch changes the binary layout of commit.h. This could
probably be avoided by putting a bit more effort into the
implementation.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 builtin-rev-list.c |    7 ++++++-
 commit.h           |    1 +
 revision.c         |   19 +++++++++++++++----
 revision.h         |    3 ++-
 4 files changed, 24 insertions(+), 6 deletions(-)

diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index ebf53f5..fd880b0 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -50,6 +50,7 @@ static const char *header_prefix;
 
 static void show_commit(struct commit *commit)
 {
+	int i;
 	if (show_timestamp)
 		printf("%lu ", commit->date);
 	if (header_prefix)
@@ -86,8 +87,12 @@ static void show_commit(struct commit *commit)
 		     parents = parents->next)
 			parents->item->object.flags &= ~TMP_MARK;
 	}
-	if (revs.commit_format == CMIT_FMT_ONELINE)
+	if (revs.commit_format == CMIT_FMT_ONELINE) {
 		putchar(' ');
+		if (revs.indent)
+			for (i = 0; i < commit->level; i++)
+				putchar(' ');
+	}
 	else
 		putchar('\n');
 
diff --git a/commit.h b/commit.h
index 86e8dca..e0e7955 100644
--- a/commit.h
+++ b/commit.h
@@ -17,6 +17,7 @@ struct commit {
 	struct commit_list *parents;
 	struct tree *tree;
 	char *buffer;
+	int level;
 };
 
 extern int save_commit_buffer;
diff --git a/revision.c b/revision.c
index 0125d41..c965a23 100644
--- a/revision.c
+++ b/revision.c
@@ -372,7 +372,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit, str
 {
 	struct commit_list *parent = commit->parents;
 	unsigned left_flag;
-	int add, rest;
+	int add, rest, indent;
 
 	if (commit->object.flags & ADDED)
 		return 0;
@@ -421,18 +421,24 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit, str
 	left_flag = (commit->object.flags & SYMMETRIC_LEFT);
 
 	rest = !revs->first_parent_only;
-	for (parent = commit->parents, add = 1; parent; add = rest) {
+	for (parent = commit->parents, add = 1, indent = 0; parent; add = rest, indent++) {
 		struct commit *p = parent->item;
 
 		parent = parent->next;
 		if (parse_commit(p) < 0)
 			return -1;
 		p->object.flags |= left_flag;
-		if (p->object.flags & SEEN)
+		if (p->object.flags & SEEN) {
+			if (commit->level + indent < p->level) {
+				p->level = commit->level + indent;
+			}
 			continue;
+		}
 		p->object.flags |= SEEN;
-		if (add)
+		if (add) {
+			p->level = commit->level + indent;
 			insert_by_date(p, list);
+		}
 	}
 	return 0;
 }
@@ -1080,6 +1086,10 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
 				revs->commit_format = get_commit_format(arg+8);
 				continue;
 			}
+			if (!strcmp(arg, "--indent")) {
+				revs->indent = 1;
+				continue;
+			}
 			if (!strcmp(arg, "--root")) {
 				revs->show_root_diff = 1;
 				continue;
@@ -1252,6 +1262,7 @@ int prepare_revision_walk(struct rev_info *revs)
 		if (commit) {
 			if (!(commit->object.flags & SEEN)) {
 				commit->object.flags |= SEEN;
+				commit->level = 0;
 				insert_by_date(commit, &revs->commits);
 			}
 		}
diff --git a/revision.h b/revision.h
index 2845167..2a45955 100644
--- a/revision.h
+++ b/revision.h
@@ -63,7 +63,8 @@ struct rev_info {
 
 	/* Format info */
 	unsigned int	shown_one:1,
-			abbrev_commit:1;
+			abbrev_commit:1,
+			indent:1;
 	enum date_mode date_mode;
 
 	const char **ignore_packed; /* pretend objects in these are unpacked */
-- 
1.5.2.rc3.88.g9f73-dirty

Re: [PATCH] rev-list: '--indent' oneline output

[Steffen Prohaska]

On May 20, 2007, at 6:00 PM, Steffen Prohaska wrote:

> As a result, the output of
>     git-rev-list --pretty=oneline --topo-order --indent
> is formatted in a way that resembles merge summaries. All commits that
> were pulled from a branch are indented with one additional space below
> the summary of the merge commit.

I created the patch to illustrate how the history could be formatted to
replace summaries.

For example
     git-rev-list --pretty=oneline --topo-order --indent 404fdef2 |  
cut -d ' ' -f 2-
outputs

Merge branch 'maint'
  Documentation: Reformatted SYNOPSIS for several commands
  Documentation: Added [verse] to SYNOPSIS where necessary
  Documentation/git.txt: Update links to older documentation pages.
gitweb: Fix "Use of uninitialized value" warning in git_feed
Merge branch 'sp/cvsexport'
  Optimized cvsexportcommit: calling 'cvs status' once instead of  
once per touched file.
Add link to 1.5.1.5 release notes.
Merge 1.5.1.5 in
  GIT v1.5.1.5
  Merge branch 'maint' of git://linux-nfs.org/~bfields/git into maint
   user-manual: reorganize public git repo discussion
   user-manual: listing commits reachable from some refs not others
   user-manual: introduce git
   user-manual: add a "counting commits" example
   user-manual: move howto/using-topic-branches into manual
   user-manual: move howto/make-dist.txt into user manual
   Documentation: remove howto's now incorporated into manual
   user-manual: move quick-start to an appendix
   glossary: expand and clarify some definitions, prune cross-references
   user-manual: revise birdseye-view chapter
   Add a birdview-on-the-source-code section to the user manual
  Documentation: git-rev-list's "patterns"
gitweb: Remove redundant $searchtype setup
[...]

- Steffen

Re: [PATCH] rev-list: '--indent' oneline output

[Junio C Hamano]

Steffen Prohaska <prohaska@zib.de> writes:

> Summaries in oneline output are indented to show the location of
> parents in merge commits. Indentation level is computed as the
> smallest sum of parent locations along all paths that reach the
> commit.
>
> As a result, the output of
>     git-rev-list --pretty=oneline --topo-order --indent
> is formatted in a way that resembles merge summaries. All commits that
> were pulled from a branch are indented with one additional space below
> the summary of the merge commit.

I would have expected this kind of UI level tweak to be done not
as a rev-list feature, but the subject of the e-mail to read
something like "--pretty=oneline: allow indentation levels",
i.e. wouldn't the feature apply not just rev-list but also
git-log?

Re: merge summaries

[Robin Rosenberg]

lördag 19 maj 2007 skrev Linus Torvalds:
> 
> On Fri, 18 May 2007, J. Bruce Fields wrote:
> > 
> > I never quite understood what they're for--do they add any information
> > not already available in the history?  If not, and if people still find
> > them helpful anyway, then I dunno, it looks like a sign of some sort of
> > failure of our history display tools.
> 
> I don't think they add much in the case of a graphical viewer, but for 
> "git log", it does make it look nicer..

It is nice for git-cvsexportcommit too. 

-- robin

Re: [PATCH] rev-list: '--indent' oneline output

[Steffen Prohaska]

On May 20, 2007, at 8:36 PM, Junio C Hamano wrote:

> Steffen Prohaska <prohaska@zib.de> writes:
>
>> Summaries in oneline output are indented to show the location of
>> parents in merge commits. Indentation level is computed as the
>> smallest sum of parent locations along all paths that reach the
>> commit.
>>
>> As a result, the output of
>>     git-rev-list --pretty=oneline --topo-order --indent
>> is formatted in a way that resembles merge summaries. All commits  
>> that
>> were pulled from a branch are indented with one additional space  
>> below
>> the summary of the merge commit.
>
> I would have expected this kind of UI level tweak to be done not
> as a rev-list feature, but the subject of the e-mail to read
> something like "--pretty=oneline: allow indentation levels",
> i.e. wouldn't the feature apply not just rev-list but also
> git-log?

It's only a proof of concept. I do not expect to see it added in
the current form. I'm not yet convinced if it's really a useful feature.

I'm also not sure if changing 'struct commit' is a good idea.
gitk is able to display the commit graph by parsing output of the
existing git-rev-list. It should be possible to do similar for log
formatting without changing 'struct commit'.

- Steffen