Hi Elijah, On Tue, 24 Apr 2018, Elijah Newren wrote:
> On Tue, Apr 24, 2018 at 4:58 AM, Johannes Schindelin > <johannes.schinde...@gmx.de> wrote: > > > > 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. I would really hesitate to go to a different merge strategy. The recursive strategy really has the best track record in general, and we have to use all kinds of branching models (including heavily criss-crossed ones) with GVFS Git. Ciao, Dscho
