2

Why I get this patch:

@@ -129,8 +132,9 @@ sub _preprocess_message {
 sub _process_message {
     my ($self, $message) = @_;

-    my $method = ref($message) eq 'HASH' ? $message->{method} : undef;
+    my $time =  [ gettimeofday ];

+    my $method = ref($message) eq 'HASH' ? $message->{method} : undef;
     return $self->send_error(ERROR_REQUEST_INVALID)
         unless defined($method);

When remove empty line after my $method = ...:

@@ -129,6 +132,8 @@ sub _preprocess_message {
 sub _process_message {
     my ($self, $message) = @_;

+    my $time =  [ gettimeofday ];
+
     my $method = ref($message) eq 'HASH' ? $message->{method} : undef;

     return $self->send_error(ERROR_REQUEST_INVALID)

I expect to see this patch instead of showed first one:

@@ -129,6 +132,8 @@ sub _preprocess_message {
 sub _process_message {
     my ($self, $message) = @_;

+    my $time =  [ gettimeofday ];
+
     my $method = ref($message) eq 'HASH' ? $message->{method} : undef;
-     
     return $self->send_error(ERROR_REQUEST_INVALID)

The my $method = ref($message) eq 'HASH' ? $message->{method} : undef; did not changed at all: there is no change in whitespace and EOL is same

Maybe should I supply some extra options to git to get this behaviour?

Eugen Konkov
  • 22,193
  • 17
  • 108
  • 158
  • Does it really matter? The end result is the same and that's just how diff aligned the lines. – Mad Physicist Nov 11 '16 at 15:07
  • 1
    @MadPhysicist Yet. it have matter. The author of original line is changed. And later somebody should take extra step while `git-blame`. But that line actually is not changed/moved – Eugen Konkov Nov 11 '16 at 15:23

2 Answers2

3

Git's diff implements a specific variant of the generalized minimal edit distance or string to string edit problem. We're given some initial set of symbols and some final set, and we are told to come up with the fewest edit instructions out of some limited set of edit commands.

In our particular case, the only allowed instructions are "delete symbol" and "add symbol" (there is no "move" allowed, but see below). Moreover, we have no knowledge of what each symbol means, but each "symbol" is a source line.

The two "symbols" are the same if and only if they match exactly, or (with certain end-of-line and/or white-space options turned on) match after stripping some items away (white space or carriage returns, mainly). Our job is to produce the smallest number of "delete" and "insert new" commands.

The diff you show has two "insert"s and one "delete". The diff Git produces also has two "insert"s and one "delete". As far as Git can tell, this makes them equal. The one it chooses is just a matter of which of several "equal" trace-back paths it chooses through a comparison matrix.

The code in git blame allows a different algorithm that does allow moves. Solving the problem when allowing moves is much harder, so git diff just doesn't bother. To enable move detection in git blame, use -M.

torek
  • 448,244
  • 59
  • 642
  • 775
  • It seems that will be very usefull for each symbol store additional meta info as source line length. So in this case when `git` counter two equal sequence of commands it will do further comparison: Adds 23 chars deletes none VS adds 75 chars deletes 46. I think this will be not so hard as move detection and this meta info will be useful for other things/places. – Eugen Konkov Nov 20 '16 at 22:31
  • That's actually a pretty good idea for breaking ties. You should try implementing it in Git, since the code is widely available. In the current version it is in `xdiff/xdiffi.c`. – torek Nov 21 '16 at 01:32
1

git diff --patience produces the result that you expect. The method tries hard not to mark lines as added or removed when they did not change. It is not the default because it is computationally expensive. (And when the purpose is to generate a patch that is applied later, it does not matter most of the time whether a diff looks the one way or the other.)

j6t
  • 9,150
  • 1
  • 15
  • 35
  • That have matter. The author of original line is changed. And later somebody should take extra step while `git-blame`. But that line actually is not changed/moved – Eugen Konkov Nov 21 '16 at 11:56
  • @Eugen It looks like `git blame --patience` is accepted, but the flag is ignored :(. – j6t Nov 21 '16 at 13:37