| commit | 07b45f8c1754a13bca67f70b600bf51ba33cf98d | |
| author | Lars Hjemli <hjemli@gmail.com> | |
| Tue, 25 Sep 2007 06:36:38 +0000 (25 08:36 +0200) | ||
| committer | Junio C Hamano <gitster@pobox.com> | |
| Wed, 31 Oct 2007 00:27:40 +0000 (30 17:27 -0700) | ||
| tree | d7e5a35444596a83b0bafc3db87a6724402f872d | treesnapshot (tar.gz zip) |
| parent | 04bd8e5fea48a00816b461b0fb934627cfd2c45f | commitdiff |
Make merge-recursive honor diff.renamelimit
It might be a sign of source code management gone bad, but when two branches
has diverged almost beyond recognition and time has come for the branches to
merge, the user is going to need all the help his tool can give him. Honoring
diff.renamelimit has great potential as a painkiller in such situations.
The painkiller effect could have been achieved by e.g. 'merge.renamelimit',
but the flexibility gained by a separate option is questionable: our user
would probably expect git to detect renames equally good when merging as
when diffing (I known I did).
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It might be a sign of source code management gone bad, but when two branches
has diverged almost beyond recognition and time has come for the branches to
merge, the user is going to need all the help his tool can give him. Honoring
diff.renamelimit has great potential as a painkiller in such situations.
The painkiller effect could have been achieved by e.g. 'merge.renamelimit',
but the flexibility gained by a separate option is questionable: our user
would probably expect git to detect renames equally good when merging as
when diffing (I known I did).
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
| merge-recursive.c | diffblobblamehistory |