git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Geert Bosch <bosch@adacore.com>
To: Morten Welinder <mwelinder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, Kevin <ikke@ikke.info>,
	git <git@vger.kernel.org>
Subject: Re: possible Improving diff algoritm
Date: Wed, 12 Dec 2012 23:58:57 -0500	[thread overview]
Message-ID: <B1564B28-9BB9-48A2-B59E-7D7C0B0DDECF@adacore.com> (raw)
In-Reply-To: <CANv4PNnC1J54TSpHuBOpY=rbuU_naysYkmoyi=utNF0vWK1CnA@mail.gmail.com>


On Dec 12, 2012, at 20:55, Morten Welinder <mwelinder@gmail.com> wrote:
> I was merely asking if an algorithm to pick between the
> 2+ choices was allowed to look at the contents of the
> lines.
> 
> I.e., an algorithm would look at the C comment
> example and determine that the choice starting containing
> a full inserted comment is preferable over the one that
> appears to close one comment and open a new.
> 
> And the in inserted-function case it would prefer the one
> where the matching { and } are in correct order.

        /**                         +    /**                         
   +     * Default parent           +     * Default parent           
   +     *                          +     *                          
   +     * @var int                 +     * @var int                 
   +     * @access protected        +     * @access protected        
   +     * @index                   +     * @index                   
   +     */                         +     */                         
   +    protected $defaultParent;   +    protected $defaultParent;   
   +                                +                                
   +    /**                              /**                         

It would seem that just looking at the line length (stripped) of
the last line, might be sufficient for cost function to minimize.
Here the some would be 3 vs 0. In case of ties, use the last
possibility with minimum cost.

I think it would be nice if the cost function we choose does not
depend on file type, as that is something that is very dependent
on the exact local configuration and might hinder comparison of
patches. If something really simple gets us 90% there, that would
be preferable over extra complexity.

  -Geert

Junio's other example:

   }

  +void new_function(void)
  +{
  +  printf("hello, world.\n");
  +}
  +
   void existing_one(void)
   {
     printf("goodbye, world.\n");

=> Cost 0

  +}
  +
  +void new_function(void)
  +{
  +  printf("hello, world.\n");
   }
=> Cost 27

Kevin's example:
    /**
+     * Default parent
+     *
+     * @var int
+     * @access protected
+     * @index
+     */
+    protected $defaultParent;
+
+    /**

=> Cost 3

+   /**
+     * Default parent
+     *
+     * @var int
+     * @access protected
+     * @index
+     */
+    protected $defaultParent;
+
     /**
=> cost 0

  reply	other threads:[~2012-12-13  5:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAO54GHC4AXQO1MbU2qXMdcDO5mtUFhrXfXND5evc93kQhNfCrw@mail.gmail.com>
2012-12-12 15:03 ` Fwd: possible Improving diff algoritm Kevin
2012-12-12 18:29   ` Junio C Hamano
2012-12-12 18:48     ` Brian J. Murrell
2012-12-12 19:30     ` Kevin
2012-12-12 20:29     ` Junio C Hamano
2012-12-12 21:40     ` Morten Welinder
2012-12-12 21:53       ` Junio C Hamano
2012-12-12 22:34         ` Andrew Ardill
2012-12-12 23:32           ` Javier Domingo
2012-12-12 23:43             ` Junio C Hamano
2012-12-12 23:49               ` Javier Domingo
2012-12-13  0:00         ` Michael Haggerty
2012-12-13  1:55         ` Morten Welinder
2012-12-13  4:58           ` Geert Bosch [this message]
2012-12-13  6:26             ` Junio C Hamano
2012-12-14 12:20               ` Javier Domingo
2012-12-14 22:29                 ` Bernhard R. Link
2012-12-15 12:16                   ` Javier Domingo

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=B1564B28-9BB9-48A2-B59E-7D7C0B0DDECF@adacore.com \
    --to=bosch@adacore.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=ikke@ikke.info \
    --cc=mwelinder@gmail.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).