Hi Dscho, On Tue, Apr 24, 2018 at 4:58 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi Junio, > > On Tue, 24 Apr 2018, Junio C Hamano wrote: > >> 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. I agree you need a config option, but I think Junio has a good point that it's worth at least checking out the possibility of a different one. In particular, you could add a merge.defaultStrategy (or maybe merge.twohead to be similar to pull.twohead??) that is set to 'resolve', and use that to avoid rename detection. Perhaps performance considerations rule out the resolve strategy and favor recursive, or maybe you need the 'recursive' part of the recursive strategy (rather than the rename part), or perhaps there's some other special reason you need to go this route, but since you are avoiding renames right now it's at least worth considering the resolve strategy. Elijah
