Hi Eckhard,
On Mon, Apr 30, 2018 at 1:03 AM, Eckhard Maaß
wrote:
> On Fri, Apr 27, 2018 at 01:23:20PM -0700, Elijah Newren wrote:
>> I doubt it has ever been discussed before this thread. But, if you're
>> curious, I'll try to dump a few thoughts.
>
> Thank you, I try to dump some of mine, too.
On Fri, Apr 27, 2018 at 01:23:20PM -0700, Elijah Newren wrote:
> I doubt it has ever been discussed before this thread. But, if you're
> curious, I'll try to dump a few thoughts.
Thank you, I try to dump some of mine, too. Maybe let me first stress
that for me copy detection without --find-copies
On Fri, Apr 27, 2018 at 11:37 AM, Eckhard Maaß
wrote:
> On Fri, Apr 27, 2018 at 11:23:56AM +0900, Junio C Hamano wrote:
>> I think demoting from copy to rename-only is a good idea, at least
>> for now, because I do not believe we have figured out what we want
>> to happen when we detect copied fil
On Fri, Apr 27, 2018 at 11:23:56AM +0900, Junio C Hamano wrote:
> I think demoting from copy to rename-only is a good idea, at least
> for now, because I do not believe we have figured out what we want
> to happen when we detect copied files are involved in a merge.
Does anyone know some threads c
Hi Dsco,
On Fri, Apr 27, 2018 at 12:23 AM, Johannes Schindelin
wrote:
> Hi,
>
> Guys, you argued long and hard that one config setting (diff.renames)
> should magically imply another one (merge.renames), on the basis that they
> essentially do the same.
I apologize for any frustration; I've pro
Hi,
On Thu, 26 Apr 2018, Elijah Newren wrote:
> On Thu, Apr 26, 2018 at 7:23 PM, Junio C Hamano wrote:
> > Ben Peart writes:
> >
> >> Color me puzzled. :) The consensus was that the default value for
> >> merge.renames come from diff.renames. diff.renames supports copy
> >> detection which me
On Thu, Apr 26, 2018 at 5:54 PM, Ben Peart wrote:
> On 4/26/2018 6:52 PM, Elijah Newren wrote:
>> On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart
>> wrote:
>>
>>> diff --git a/merge-recursive.h b/merge-recursive.h
>>> index 80d69d1401..0c5f7eff98 100644
>>> --- a/merge-recursive.h
>>> +++ b/merge-recu
On Thu, Apr 26, 2018 at 7:23 PM, Junio C Hamano wrote:
> Ben Peart writes:
>
>> Color me puzzled. :) The consensus was that the default value for
>> merge.renames come from diff.renames. diff.renames supports copy
>> detection which means that merge.renames will inherit that value. My
>> assum
Ben Peart writes:
> Color me puzzled. :) The consensus was that the default value for
> merge.renames come from diff.renames. diff.renames supports copy
> detection which means that merge.renames will inherit that value. My
> assumption was that is what was intended so when I reimplemented it,
On 4/26/2018 6:52 PM, Elijah Newren wrote:
On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart wrote:
+merge.renames::
+ Whether and how Git detects renames. If set to "false",
+ rename detection is disabled. If set to "true", basic rename
+ detection is enabled. If set to "copies
On Thu, Apr 26, 2018 at 1:52 PM, Ben Peart wrote:
> +merge.renames::
> + Whether and how Git detects renames. If set to "false",
> + rename detection is disabled. If set to "true", basic rename
> + detection is enabled. If set to "copies" or "copy", Git will
> + detect c
Add the ability to control rename detection for merge via a config setting.
This setting behaves the same and defaults to the value of diff.renames but only
applies to merge.
Reviewed-by: Johannes Schindelin
Signed-off-by: Ben Peart
---
Documentation/merge-config.txt| 6 ++
Doc
12 matches
Mail list logo
