Re: [PATCH] Fix "git log --parent -m" from emitting duplicated parent info

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 9, 2007, 06:19 UTC
Message-ID: <7vodimw142.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <e5bfff550707082246k39286517o58fe89d80e05e08@mail.gmail.com>

"Marco Costalba" <mcostalba@gmail.com> writes:

> Indeed we can use and _do_ use --full-history not only for printing
> all revisions but to _walk_ the tree in a certain way, different from
> default.

Yes, --full-history essentially tells the machnery to walk all side branches even when a merge takes all the specified paths from one parent's version. You will end up walking all five branches from the first pentapus "addafaf" in git.git history, even if history simplification with pathspec would have narrowed it down to three paths if you did not give that option.

> IMHO --parents + --full-history is absolutely legal because the first
> flag indicate how to walk the tree and the second flag indicate what
> to show to the user.

I think we are in agreement. You are telling the machinery to walk all five branches with --full-history. But you are not telling the machinery to keep the intermediate commits (i.e. you do not give --sparse), so these five branches can be simplified to lead to the same parent. I think I was confused by dense vs simplify_history when I wrote that message in the thread Johannes pointed out:

	http://thread.gmane.org/gmane.comp.version-control.git/29222

Making the duplicate parent removal depend on "dense" makes sense, but the rewrite_parent() codepath is used only when dense anyway.

Thanks for a timely objection and sanity checking.