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

Reply via email to