Re: [PATCH 07/10] merge-strategies.txt: explain why no-renames might be useful

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Elijah Newren <newren@xxxxxxxxx> writes:

>> >  no-renames;;
>> > -     Turn off rename detection. This overrides the `merge.renames`
>> > -     configuration variable.
>> > -     See also linkgit:git-diff[1] `--no-renames`.
>> > +     Turn off rename detection, which can be computationally
>> > +     expensive.  This overrides the `merge.renames`
>> > +     configuration variable.  See also linkgit:git-diff[1]
>> > +     `--no-renames`.
>>
>> Other reasons are that we may find a pair that the user did not
>> intend to when they made the change (i.e. it was done purely a
>> creation and a deletion but we found similarity), or we may find a
>> wrong original to consolidate changes from a side branch into, and
>> these are fundamental as it is our early design choice not to
>> record renames at the time of committing.
>
> Good points.  Trying to describe all of that makes it somewhat
> lengthy; does it make sense to include all of that, or should I just
> drop this patch?

What do the git-diff page say?  If it is not worth saying there,
perhaps we should not have to do so here, either.

We should have _somewhere_ that lists these pitfalls that the users
may want to be aware of, that is common to all the features that
ends up using and relying on the rename machinery.  I do not think
merge strategies documentation is the place.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux