Diff adds a new function inside an existing one, not after

Question

I started to pay a little more attention to the diff files that I create (using git), and I am unhappy with the clarity of the diff created by this situation.

I'll start with:

sub main { my $self = shift; return $self; } 

Then I add a second function and a call to it in the first to get:

 sub main { my $self = shift; $self -> process ( 'hello world!' ); return $self; } sub process { my $self = shift; print @_, "\n"; return $self; } 

The output of the diff that I get for this is:

 @@ -1,5 +1,15 @@ sub main { my $self = shift; + $self -> process ( 'hello world!' ); + + return $self; +} + +sub process { + my $self = shift; + + print @_, "\n"; + return $self; } 

It seems very untidy and incomprehensible to the reader to me. A piece of padding makes it look like I'm adding a lot of lines to the "main" function, when I actually have the most lines added after it. For example, I would expect diff to look like this:

 @@ -1,5 +1,15 @@ sub main { my $self = shift; + $self -> process ( 'hello world!' ); + return $self; } + +sub process { + my $self = shift; + + print @_, "\n"; + + return $self; +} 

I understand why diff creates this output (the easiest way to go from "a → b"), but I would like it to be clarified. Is it possible? Or am I looking at manually editing the differences or even splitting the addition of a new function and calling it into 2 separate patches / commits? [1]

I tried using the algorithms --no-minimal, -patience and -histogram, but the diff result is identical. Manually editing diff with "git add -p" does not matter; it is still the first, "fuzzy" difference.

[1] As a side question, is this separation what I should really do anyway?

Answer 1

Usually people do not share such changes into several commits. Typically, the rule is to try to use each commit position yourself. Even if you divide it into several commits, often people will look at the state before either of these commits and the state after both of them, and so see the same type of output that you see.

Using git add -p definitely not help affect diff output. This is just a way to have more control over which changes fall into the next commit. In any case, the commit consists only of the new contents of the tree you are working with; it does not write diff against the previous version. The differences displayed later are computed each time they are requested.

One thing that helps to avoid this is to put a comment, for example, # End of <function name> after closing the brackets of each function. But this has its own deformity to it. In real code, there is likely to be less generality between the various functions, and therefore the likelihood of being misleading. But in any case, this is what most people are used to.

Answer 2

According to git diff man page , the default context for diff is 3 lines. When two pieces of (possible) independent changes are closer and therefore overlap, they merge into one common hunk

You can live with it or always use the -U<n> option

Create diff with <n> context lines instead of the usual three

with your differences