threads / discuss / 8198

merge summaries

Subject: merge summaries

## tl;dr

18 messages between May 18, 2007 and May 20, 2007.

replies: 17people: 5as markdown or json

Steffen Prohaska· May 18, 2007, 05:44 UTC · lore

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
Linus Torvalds· May 18, 2007, 18:33 UTC · re: Steffen Prohaska · lore

Re: merge summaries

On Fri, 18 May 2007, Steffen Prohaska wrote:
Show 5 quoted lines
>
> 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
Junio C Hamano· May 18, 2007, 18:47 UTC · re: Linus Torvalds · lore

Re: merge summaries

Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 15 quoted lines
>> 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.

Linus Torvalds· May 18, 2007, 19:13 UTC · re: Junio C Hamano · lore

Re: merge summaries

On Fri, 18 May 2007, Junio C Hamano wrote:
Show 7 quoted lines
> 
> 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
J. Bruce Fields· May 18, 2007, 21:56 UTC · re: Linus Torvalds · lore

Re: merge summaries

On Fri, May 18, 2007 at 12:13:02PM -0700, Linus Torvalds wrote:
Show 13 quoted lines
> 
> 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.
Linus Torvalds· May 18, 2007, 23:12 UTC · re: J. Bruce Fields · lore

Re: merge summaries

On Fri, 18 May 2007, J. Bruce Fields wrote:
Show 5 quoted lines
> 
> 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
Junio C Hamano· May 18, 2007, 23:34 UTC · re: Linus Torvalds · lore

Re: merge summaries

Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 9 quoted lines
> 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" ;-).
Robin Rosenberg· May 20, 2007, 20:34 UTC · re: Linus Torvalds · lore

Re: merge summaries

lördag 19 maj 2007 skrev Linus Torvalds:
Show 10 quoted lines
> 
> 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
Steffen Prohaska· May 20, 2007, 16:00 UTC · re: J. Bruce Fields · lore

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

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
Steffen Prohaska· May 20, 2007, 16:12 UTC · re: Steffen Prohaska · lore

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

On May 20, 2007, at 6:00 PM, Steffen Prohaska wrote:
Show 5 quoted lines
> 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
Junio C Hamano· May 20, 2007, 18:36 UTC · re: Steffen Prohaska · lore

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

Steffen Prohaska <prohaska@zib.de> writes:
Show 10 quoted lines
> 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?

Steffen Prohaska· May 20, 2007, 20:38 UTC · re: Junio C Hamano · lore

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

On May 20, 2007, at 8:36 PM, Junio C Hamano wrote:
Show 20 quoted lines
> 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
Steffen Prohaska· May 19, 2007, 09:35 UTC · re: Junio C Hamano · lore

Re: merge summaries

On May 18, 2007, at 8:47 PM, Junio C Hamano wrote:
Show 22 quoted lines
>> 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
Junio C Hamano· May 19, 2007, 19:24 UTC · re: Steffen Prohaska · lore

Re: merge summaries

Steffen Prohaska <prohaska@zib.de> writes:
Show 6 quoted lines
> 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.

Junio C Hamano· May 19, 2007, 20:20 UTC · re: Junio C Hamano · lore

Re: merge summaries

Junio C Hamano <junkio@cox.net> writes:
Show 18 quoted lines
> 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").

Steffen Prohaska· May 20, 2007, 08:17 UTC · re: Junio C Hamano · lore

Re: merge summaries

On May 19, 2007, at 10:20 PM, Junio C Hamano wrote:
Show 9 quoted lines
> 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. ...

Show 9 quoted lines
> 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?

Show 10 quoted lines
> 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
Junio C Hamano· May 20, 2007, 08:27 UTC · re: Steffen Prohaska · lore

Re: merge summaries

Steffen Prohaska <prohaska@zib.de> writes:
Show 5 quoted lines
> 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").

Junio C Hamano· May 20, 2007, 09:07 UTC · re: Junio C Hamano · lore

Re: merge summaries

Junio C Hamano <junkio@cox.net> writes:
Show 7 quoted lines
> 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.

Show 6 quoted lines
> 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.

← back to recent threads