git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: Re: [PATCH 0/7] Rejecting useless merge bases
Date: Wed, 19 Oct 2016 14:34:29 -0700	[thread overview]
Message-ID: <xmqqr37cja56.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: 20161019042345.29766-1-gitster@pobox.com

Junio C Hamano <gitster@pobox.com> writes:

> This is a continuation of
>
>     http://public-inbox.org/git/xmqqmvi2sj8f.fsf@gitster.mtv.corp.google.com

I scanned all two-parent merges in git.git leading to 'next' and
'pu' and reproduced them with or without the new --fp-base-only
option.  I also did the same experiment in linux.git, but only for
the latest 10,000 merges.

This exercise yielded some interesting numbers.

Among the total 10,995 merges, 10,487 merges had only one merge base
and that merge base was on the first-parent chain, i.e. the result
of reproduction is the same with or without "--fp-base-only".

There were 65 merges with multiple merge-bases but all of these
merge bases were on the first-parent chain, i.e. again the result is
the same with or without "--fp-base-only".

The remaining 443 merges had merge bases that are not on the
first-parent chain.  These merges, when recreated with
"--fp-base-only", would use different/reduced set of merge bases to
drive merge-recursive machinery and could produce different results.

Among these 443, "git merge" with or without the "--fp-base-only"
option successfully auto-resolved and produced the same result as
recorded in the real history for 214 of them.  They stopped in
conflicts but "git ls-files -s" output in their conflicted states
were the same, i.e. they left the identical conflicts, for 221 of
them.

The remaining 8 merges were auto-resolved the same way with or
without the "--fp-base-only" option, but they were different from
the merge in the real history (i.e. the real history had an evil
merge there to adjust for non-textual conflicts).

The most important numbers was 0.  There was no merges whose
reproduction with and without "--fp-base-only" produced different
results.


For linux.git the numbers are:

 - total merges looked at:                         10,000
 - single merge base:                               9,705
 - multi merge base all on the first parent chain:    123
 - fp-base-only eligible:                             172
 - cleanly resolved the same way w/ or w/o fp-only:   118
 - conflicted the same way w/ or w/o fp-only:          54
 - evil merges among fp-base-only eligible merges:      0
 - fp-base-only mismerges:                              0

  parent reply	other threads:[~2016-10-19 21:34 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-17 22:28 [RFD] should all merge bases be equal? Junio C Hamano
2016-10-19  4:23 ` [PATCH 0/7] Rejecting useless merge bases Junio C Hamano
2016-10-19  4:23   ` [PATCH 1/7] commit: simplify fastpath of merge-base computation Junio C Hamano
2016-10-19  4:23   ` [PATCH 2/7] sha1_name: remove ONELINE_SEEN bit Junio C Hamano
2016-10-19  4:23   ` [PATCH 3/7] merge-base: stop moving commits around in remove_redundant() Junio C Hamano
2016-10-19  4:23   ` [PATCH 4/7] merge-base: expose get_merge_bases_many_0() a bit more Junio C Hamano
2016-10-19  4:23   ` [PATCH 5/7] merge-base: mark bases that are on first-parent chain Junio C Hamano
2016-10-19 17:42     ` Junio C Hamano
2016-10-19  4:23   ` [PATCH 6/7] merge-base: limit the output to " Junio C Hamano
2016-10-19  4:23   ` [PATCH 7/7] merge: allow to use only the fp-only merge bases Junio C Hamano
2016-10-19 21:34   ` Junio C Hamano [this message]
2017-02-09 14:44 ` [RFD] should all merge bases be equal? Michael Haggerty
2017-02-09 16:57   ` 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=xmqqr37cja56.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /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).