git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Kevin Bracey <kevin@bracey.fi>
Cc: git@vger.kernel.org
Subject: Re: [RFC/PATCH 2/3] simplify-merges: never remove all TREESAME parents
Date: Sat, 27 Apr 2013 16:02:55 -0700	[thread overview]
Message-ID: <7vli83shk0.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1367004718-30048-2-git-send-email-kevin@bracey.fi> (Kevin Bracey's message of "Fri, 26 Apr 2013 22:31:57 +0300")

Kevin Bracey <kevin@bracey.fi> writes:

> In the event of an odd merge, we may find ourselves TREESAME to
> apparently redundant parents. Prevent simplify_merges() from removing
> every TREESAME parent - in the event of such a merge it's useful to see
> where we came actually from came.
>
> Signed-off-by: Kevin Bracey <kevin@bracey.fi>
> ---
>  Documentation/rev-list-options.txt |  3 ++-
>  revision.c                         | 24 ++++++++++++++++++++++++
>  2 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
> index 380db48..0832004 100644
> --- a/Documentation/rev-list-options.txt
> +++ b/Documentation/rev-list-options.txt
> @@ -472,7 +472,8 @@ history according to the following rules:
>  +
>  * Replace each parent `P` of `C'` with its simplification `P'`.  In
>    the process, drop parents that are ancestors of other parents, and
> -  remove duplicates.
> +  remove duplicates, but take care to never drop all parents that
> +  we are TREESAME to.
>  +
>  * If after this parent rewriting, `C'` is a root or merge commit (has
>    zero or >1 parents), a boundary commit, or !TREESAME, it remains.
> diff --git a/revision.c b/revision.c
> index 176eb7b..4e27c9a 100644
> --- a/revision.c
> +++ b/revision.c
> @@ -2106,8 +2106,32 @@ static int remove_marked_parents(struct rev_info *revs, struct commit *commit)
>  {
>  	struct treesame_state *ts = lookup_decoration(&revs->treesame, &commit->object);
>  	struct commit_list **pp, *p;
> +	struct commit *su = NULL, *sm = NULL;

What do "su" and "sm" stand for?

>  	int n, removed = 0;
>  
> +	/* Prescan - look for both marked and unmarked TREESAME parents */
> +	for (p = commit->parents, n = 0; p; p = p->next, n++) {
> +		if (ts->treesame[n]) {
> +			if (p->item->object.flags & TMP_MARK) {
> +				if (!sm) sm = p->item;
> +			}
> +			else {
> +				if (!su) {
> +					su = p->item;
> +					break;
> +				}
> +			}
> +		}
> +	}
> +
> +	/* If we are TREESAME to a marked-for-deletion parent, but not to any
> +	 * unmarked parents, unmark the first TREESAME parent. We don't want
> +	 * to remove our "real" parent in the event of an "-s ours" type
> +	 * merge.

Could you explain here a bit more the reason why we do not want to
remove them and why "-s ours" is so significant that it deserves to
be singled out?  And why randomly picking one that is redundant
(because it is an ancestor of some other parent) is an improvement?

The "remove-redundant" logic first marks commits that are ancestors
of other commits in the original set, without taking treesame[] into
account at all.  If the final objective of the code is to keep paths
that consists of non-treesame[] commits, perhaps the logic needs to
be changed to reject non-treesame[] commits that are ancestors of
other non-treesame[] commits, or something?

> +	 */
> +	if (!su && sm)
> +		sm->object.flags &= ~TMP_MARK;
> +
>  	pp = &commit->parents;
>  	n = 0;
>  	while ((p = *pp) != NULL) {

  reply	other threads:[~2013-04-27 23:03 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-09 18:00 Locating merge that dropped a change Kevin Bracey
2013-04-11 17:28 ` Kevin Bracey
2013-04-11 19:21   ` Junio C Hamano
2013-04-22 19:23     ` [RFC/PATCH] Make --full-history consider more merges Kevin Bracey
2013-04-22 19:49       ` Junio C Hamano
2013-04-23 16:35         ` Kevin Bracey
2013-04-24 22:34           ` Junio C Hamano
2013-04-25  1:59             ` Junio C Hamano
2013-04-25 15:48               ` Kevin Bracey
2013-04-25 16:51                 ` Junio C Hamano
2013-04-25 17:11                   ` Kevin Bracey
2013-04-25 18:19                     ` Junio C Hamano
2013-04-26 19:18                       ` Kevin Bracey
2013-04-26 19:31                         ` [RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges Kevin Bracey
2013-04-26 19:31                           ` [RFC/PATCH 2/3] simplify-merges: never remove all TREESAME parents Kevin Bracey
2013-04-27 23:02                             ` Junio C Hamano [this message]
2013-04-28  7:10                               ` Kevin Bracey
2013-04-28 18:09                                 ` Junio C Hamano
2013-04-26 19:31                           ` [RFC/PATCH 3/3] simplify-merges: drop merge from irrelevant side branch Kevin Bracey
2013-04-27 22:36                           ` [RFC/PATCH 1/3] revision.c: tighten up TREESAME handling of merges Junio C Hamano
2013-04-27 22:57                             ` David Aguilar
2013-04-28  7:03                             ` Kevin Bracey
2013-04-28 18:38                               ` Junio C Hamano
2013-04-29 17:46                                 ` Kevin Bracey
2013-04-29 18:11                                   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vli83shk0.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=kevin@bracey.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).