Kevin Bracey <kevin@xxxxxxxxx> writes:
> diff --git a/revision.c b/revision.c
> index eb98128..96fe3f5 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -516,8 +516,14 @@ static void try_to_simplify_commit(struct rev_info *revs, struct commit *commit)
> }
> die("bad tree compare for commit %s", sha1_to_hex(commit->object.sha1));
> }
> - if (tree_changed && !tree_same)
> - return;
> +
> + if (tree_changed) {
> + if (!tree_same)
> + return;
> +
> + if (!revs->simplify_history && !revs->simplify_merges)
> + return;
So in addition to "have some change and there is no same parent"
case, under _some_ condition we avoid marking a merge not worth
showing (i.e. TREESAME) if there is any change.
And the condition is !simplify_history and !simplify_merges, which
would cover --full-history, but I am not sure if requiring
!simplify_merges is correct.
Do you need it and if so why? The --simplify-merges option is
defined as a post-processing operation over what full-history
produces in the list limiting code (which involves the logic the
patch is touching). The --ancestry-path option works the same way
but its post-processing is done inside the limit_list() function.
So it feels more natural if the patch were ignoring simplify_merges
and paid attention only to simplify_history.
> + }
> commit->object.flags |= TREESAME;
> }
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html