Re: [PATCH v1 1/2] merge: Add merge.renames config setting

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 24, 2018, 11:58 UTC
Message-ID: <nycvar.QRO.7.76.6.1804241354520.64@ZVAVAG-6OXH6DA.rhebcr.pbec.zvpebfbsg.pbz>
In-Reply-To: <xmqqy3hd8q2k.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Tue, 24 Apr 2018, Junio C Hamano wrote:

Show 16 quoted lines

> Ben Peart <peartben@gmail.com> writes:
> 
> >> I also had to wonder how "merge -s resolve" faired, if the project
> >> is not interested in renamed paths at all.
> >>
> >
> > To be clear, it isn't that we're not interested in detecting renamed
> > files and paths.  We're just opposed to it taking an hour to figure
> > that out!
> 
> Yeah, but as opposed to passing "oh, let's see if we can get a
> reasonable result without rename detection just this time" from the
> command line, configuring merge.renames=false in would mean exactly
> that: "we don't need rename detection, just want to skip the cycles
> spent for it".  That is why I wondered how well the resolve strategy
> would have fit your needs.

Please do not forget that the context is GVFS, where you would cause a lot of pain and suffering by letting users forget to specify that command-line option all the time, resulting in several gigabytes of objects having to be downloaded just for the sake of rename detection.

So there is a pretty good point in doing this as a config option.

Ciao, Dscho