git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: git discussion list <git@vger.kernel.org>
Subject: Re: Our merge bases sometimes suck
Date: Fri, 20 Jun 2014 10:53:14 +0200	[thread overview]
Message-ID: <53A3F67A.80501@alum.mit.edu> (raw)
In-Reply-To: <xmqqtx7gdqbt.fsf@gitster.dls.corp.google.com>

On 06/20/2014 08:53 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> It just looks asymmetric, but actually it is symmetric, which was kindof
>> surprising when I realized it....
>>
>> Since "|branch ∧ master|" is the same for all candidates, minimizing N
>> is the same as maximizing |candidate|, which is the same as
>>
>>     git rev-list --count --no-merges $candidate
>>
>> This is clearly symmetric in master vs. base.
> 
> Hmph, but that obviously will become very expensive to compute as
> project grows.

This formulation is theoretically interesting because it shows the
symmetry of the criterion, but that doesn't mean it is the most
practical to use.  Given that multiple formulations are equivalent, any
of them can be used.

> When we (potentially) have multiple merge-bases, after finding all
> the candidates by traversing from the two commits to be merged, we
> already make another set of traversals, starting from the candidates
> and painting the ancestors down to their common ancestors.  This is
> done to discover if each candidate is reachable from any other
> candidate (in which case the reachable one is not a merge-base).
> 
> The resulting graph of this traversal is currently used only to cull
> non-merge-bases out of the candidates, but I wonder if you can
> *count* the nodes in it in each color and use that number (which is
> essentially the number of commits that can be reached only from one
> candidate and not from other candidates) to derive a score for each
> candidate, and use it to assess the goodness of merge-bases, just
> like the number you are counting in the above full traversal.

It sounds promising.  Let's see if I correctly understand the algorithm
that you described:

"common_ancestors" = intersection of all candidates' histories
"painting_from($candidate)" = $candidate - common_ancestors
discard $candidate if $candidate is in painting_from($other_candidate)
(i.e., it is not a merge base)

If that is correct, then the candidate with the most commits in
painting_from($candidate) should be the best merge base, because
common_ancestors is a subset of the candidate's history, so

    |painting_from($candidate)| = |$candidate| - |common_ancestors|

Since |common_ancestors| is the same for all candidates, minimizing
|painting_from($candidate)| is the same as minimizing |$candidate|.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

  reply	other threads:[~2014-06-20  8:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-12 22:12 Our merge bases sometimes suck Michael Haggerty
2014-06-13  9:38 ` Michael J Gruber
2014-06-13 10:13   ` Michael Haggerty
2014-06-13 15:52   ` Jakub Narębski
2014-06-13 22:14     ` Michael Haggerty
2014-06-13 22:35     ` Junio C Hamano
2014-06-17 15:08 ` Junio C Hamano
2014-06-17 15:44   ` Michael Haggerty
2014-06-20  6:53     ` Junio C Hamano
2014-06-20  8:53       ` Michael Haggerty [this message]
2014-06-20 21:17       ` Nico Williams
2014-06-23 11:43         ` Jakub Narębski

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=53A3F67A.80501@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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).