Re: [HACKERS] git diff --patience

2010-10-01 Thread Greg Stark
On Fri, Oct 1, 2010 at 7:15 AM, Kevin Grittner
 wrote:
> An interesting exercise it so think about what
> real-life lines you could have which would have multiple occurrences
> in this pattern, and think about whether you would then prefer the
> --patience output, especially if this were part of a larger file.

The linux-kernel mailing list had examples of this occurring in real
life too. In real C programs function signatures usually end up being
the unique lines which is what you want but it can happen that
surprising lines are unique. Even braces can be unique if a given
indentation level is only used once.

The discussion basically convinced me that using uniqueness alone is a
bad idea but that the basic idea of trying to identify the important
lines is a fine idea. It's just that uniqueness turns out to be a
relatively weak signal for interesting lines. Linus suggested
line-length but it's pretty debatable which is better.

-- 
greg

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-10-01 Thread Kevin Grittner
Gurjeet Singh  wrote:
> Alvaro Herrera wrote:
 
>> There is a very simple example posted on some of the blog posts
>> that goes something like
>>
>> 
>> 
>> 
>> 
>> 
>> 
>> xyz
>>
>> and the "xyz" is moved to the front.  In this corner case, the
>> patience diff is a lot worse.
>>
> 
> Sorry, but that example didn't make much sense to me. Can you
> please elaborate, or maybe share those blog posts you are referring
to.
 
I tried it out.  Here are the results:
 
git diff --color
diff --git a/a1 b/a1
index bd0586b..32736d1 100644
--- a/a1
+++ b/a1
@@ -1,7 +1,7 @@
+xyz
 
 
 
 
 
 
-xyz
git diff --color --patience
diff --git a/a1 b/a1
index bd0586b..32736d1 100644
--- a/a1
+++ b/a1
@@ -1,7 +1,7 @@
-
-
-
-
-
-
 xyz
+
+
+
+
+
+
 
This is because lines which only occur once in a file are the
"anchors" around which lines which occur multiple times move -- 
after keeping intact any leading and trailing lines which match
between the files.  An interesting exercise it so think about what
real-life lines you could have which would have multiple occurrences
in this pattern, and think about whether you would then prefer the
--patience output, especially if this were part of a larger file. 
Even in this supposed "worst case" example, I'm not at all sure I
wouldn't prefer --patience, personally, even though more lines are
flagged.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-10-01 Thread Gurjeet Singh
On Fri, Oct 1, 2010 at 9:38 AM, Alvaro Herrera
wrote:

> Excerpts from Kevin Grittner's message of jue sep 30 16:38:11 -0400 2010:
>
> > When I read the description of the algorithm, I can't imagine a
> > situation where --patience would make the diff *worse*.  I was
> > somewhat afraid (based on the name) that it would be slow; but
> > if it is slower, it hasn't been by enough for me to notice it.
>
> There is a very simple example posted on some of the blog posts that
> goes something like
>
> 
> 
> 
> 
> 
> 
> xyz
>
> and the "xyz" is moved to the front.  In this corner case, the patience
> diff is a lot worse.
>

Sorry, but that example didn't make much sense to me. Can you please
elaborate, or maybe share those blog posts you are referring to.

Regards,
-- 
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com

singh.gurj...@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device


Re: [HACKERS] git diff --patience

2010-10-01 Thread Alvaro Herrera
Excerpts from Kevin Grittner's message of jue sep 30 16:38:11 -0400 2010:

> When I read the description of the algorithm, I can't imagine a
> situation where --patience would make the diff *worse*.  I was
> somewhat afraid (based on the name) that it would be slow; but
> if it is slower, it hasn't been by enough for me to notice it.

There is a very simple example posted on some of the blog posts that
goes something like







xyz

and the "xyz" is moved to the front.  In this corner case, the patience
diff is a lot worse.

-- 
Álvaro Herrera 
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-09-30 Thread Kevin Grittner
Gurjeet Singh  wrote:
 
> The with-patience version has only two hunks, removal of a big
> block of comment and addition of a big block of code.
> 
> The without-patience patience is riddled with the mix of two
> hunks, spread until line 120.
> 
> --patience is a clear winner here.
 
When I read the description of the algorithm, I can't imagine a
situation where --patience would make the diff *worse*.  I was
somewhat afraid (based on the name) that it would be slow; but
if it is slower, it hasn't been by enough for me to notice it.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-09-30 Thread Gurjeet Singh
Attached are two versions of the same patch, with and without --patience.

The with-patience version has only two hunks, removal of a big block of
comment and addition of a big block of code.

The without-patience patience is riddled with the mix of two hunks, spread
until line 120.

--patience is a clear winner here.

Regards,

On Wed, Sep 29, 2010 at 5:10 PM, Kevin Grittner  wrote:

> Peter Eisentraut  wrote:
>
> > Do you have an existing commit where you see a difference so I can
> > try it and see if there is some other problem that my local
> > configuration has?
>
> Random poking around in the postgresql.git commits didn't turn up
> any where it mattered, so here's before and after files for the
> example diff files already posted.  If you create branch, commit the
> before copy, and copy in the after copy, you should be able to
> replicate the results I posted.
>
> -Kevin
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>


-- 
gurjeet.singh
@ EnterpriseDB - The Enterprise Postgres Company
http://www.EnterpriseDB.com

singh.gurj...@{ gmail | yahoo }.com
Twitter/Skype: singh_gurjeet

Mail sent from my BlackLaptop device


diff_without_patience.patch
Description: Binary data


diff_with_patience.patch
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-09-29 Thread Kevin Grittner
Peter Eisentraut  wrote:
 
> Do you have an existing commit where you see a difference so I can
> try it and see if there is some other problem that my local
> configuration has?
 
Random poking around in the postgresql.git commits didn't turn up
any where it mattered, so here's before and after files for the
example diff files already posted.  If you create branch, commit the
before copy, and copy in the after copy, you should be able to
replicate the results I posted.
 
-Kevin


predicate.h-before
Description: Binary data


predicate.h-after
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-09-29 Thread Kevin Grittner
Peter Eisentraut  wrote:
 
> I have tried this switch various times now and haven't seen any
> difference at all in the output.  Do you have an existing commit
> where you see a difference so I can try it and see if there is
> some other problem that my local configuration has?
 
Having looked at it more, I find that the output with the switch is
usually the same as without; but when they differ, I always have
preferred the version with it on.  Attached is the diff which caused
me to see if there was a way to make the diff output smarter, and
the result of adding the --patience flag.
 
This is the unified form that git puts out by default, but the
benefit is there after filterdiff --format=context, too.
 
-Kevin
 



patience-off.diff
Description: Binary data


patience-on.diff
Description: Binary data

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-09-29 Thread Peter Eisentraut
On ons, 2010-09-15 at 12:58 -0500, Kevin Grittner wrote:
> I just discovered the --patience flag on the git diff command, and
> I'd like to suggest that we encourage people to use it when possible
> for building patches.  I just looked at output with and without it
> (and for good measure, before and after filterdiff --format=context
> for both), and the results were much better with this switch.

I have tried this switch various times now and haven't seen any
difference at all in the output.  Do you have an existing commit where
you see a difference so I can try it and see if there is some other
problem that my local configuration has?


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] git diff --patience

2010-09-16 Thread Bruce Momjian
Kevin Grittner wrote:
> I just discovered the --patience flag on the git diff command, and
> I'd like to suggest that we encourage people to use it when possible
> for building patches.  I just looked at output with and without it
> (and for good measure, before and after filterdiff --format=context
> for both), and the results were much better with this switch.
>  
> Here's a reference to the algorithm:
>  
> http://bramcohen.livejournal.com/73318.html
>  
> I think that page understates the benefits, though.

I have seen the bracket example shown and the --patience output is
clearly nicer.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

  + It's impossible for everything to be true. +

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] git diff --patience

2010-09-15 Thread Kevin Grittner
I just discovered the --patience flag on the git diff command, and
I'd like to suggest that we encourage people to use it when possible
for building patches.  I just looked at output with and without it
(and for good measure, before and after filterdiff --format=context
for both), and the results were much better with this switch.
 
Here's a reference to the algorithm:
 
http://bramcohen.livejournal.com/73318.html
 
I think that page understates the benefits, though.
 
-Kevin

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers