On Sun, Sep 19, 2021 at 8:12 PM Ariel Man <arielman22@xxxxxxxxx> wrote: > > Hi, > following the below thread, led me to do some tests: > https://stackoverflow.com/a/69114710/11705021 > > One of the test can be seen here, in the last example in my question: > https://stackoverflow.com/questions/69150777/git-mv-doesnt-work-as-expected-wrong-files-location > > I wanted to get confirmation for my case: > Does `git merge -s ort` command, doesn't know to detect new folder > location when merging it? It did worked for folders and files > renaming, and new files under existing folders (as describe here: > https://stackoverflow.com/a/52227201/6309) I mean, if you have a testcase and want to see how it works, you can just try it. merge-ort has been released and is part of git already. But I'll take a stab... Your testcase with new folders sounds like testcase 12f from t6423 in our testsuite (from commit 902c521a35 ("t6423: more involved directory rename test", 2020-10-15)), a case that works with the `ort` merge strategy but not with `recursive`. So, the `ort` strategy is likely to be better for your usecase than `recursive`, but it's hard for me to definitively state that it'll solve all your usecase(s) since you didn't fully describe them. This is especially important since you appear to have discovered a segfault (in the first post); I was not aware of any circumstances when the old merge machinery would do so. I'd be interested to know if the same issue repeats with the `ort` strategy, and, if so, whether you can get a stack trace, or find an example that reproduces the problem, or provide us with access to your repository. Also, in your second link, you allude to problems in a case that does not include new folders, in situations where I'd expect `recursive` and `ort` to behave the same. But it's hard to know the expected behavior since you didn't provide that many details about the setup -- e.g. you didn't cover the contents of any of the files (so it's hard to know if files are more similar to ones with different names than what you expected to be matched up), it's unclear if there are other files involved (e.g. if you have multiple copies of some library and the rename detection is detecting a different copy than you expected, or if there are lots of additional files besides those you are listing in your example and they are being renamed differently, etc.), whether you have lots of large files also being renamed (perhaps the VDI files you allude to somewhere?), etc., etc. If you can provide access to a repository and the commands you reported and what you expected vs. what you saw, I'd try to find some time to take a look. I hope that helps, though I'm not sure I've got enough details to answer all your questions. I guess if I were to summarize, I'd say: * the `ort` strategy would be better than `recursive` for you, for one particular type of issue, but probably behave the same on other areas * you seem to have useful testcases that might be different than ones we have in our testsuite or that I know about * you haven't provided enough information for me to investigate or answer any further, though. You have gotten me really curious about this segfaulting testcase -- whether it's just in the recursive backend or also afflicts merge-ort, and how to duplicate it.
