Re: Question about git merge -s ort command‏‏

Hi,

Please do not top-post on this mailing list.

On Wed, Sep 29, 2021 at 11:58 PM Ariel Man [off-list ref] wrote:

Hi,
Thanks for the detailed answer, but just to clarify, my main question
is regarding ORT strategy, and not recursive.

Since you simply linked to three posts in your original email, and the
first showed a segfault, this wasn't at all clear.

Mainly in this case, where ORT didn't behave as I expected:
https://stackoverflow.com/questions/69150777/git-mv-doesnt-work-as-expected-wrong-files-location#:~:text=test3.py%0A%E2%94%82%20%20%20%E2%94%94%E2%94%80%E2%94%80%20dir3-,UPDATE,-I%27m%20adding%20one

As I wrote, this specific case is where new folder and files were
created after the consolidation (and not new files under the existing
folder). As you can see, when only new files were added to the
existing folder, the git ORT recognized it and moved the folder
python1 with its files test1.py and test4.py to the right place
(dir2). But when new folder was created on the target (new_test with
the file test5.py), when I ran the ORT command, the GIT didn't
recognized it and created again the folder python1 on the old path
(dir1-->python1-->new_test-->test5.py).

Yes, I read through that and pointed out your examples weren't fully
specified.  You haven't stated what else exists in all these
directories, what kind of contents files had, if there were big
binaries, etc.

I believe you can reproduce it yourself on your repository and see the
behaviour.

Nope, I can't.  I went through the trouble of setting up the testcases
as close as I could from your diagrams.  When using the recursive
strategy, I do see that test4.py and test5.py are left behind in dir1,
but when using the ort strategy, it behaves exactly as you said you
wanted (with *both* test4.py and test5.py appearing somewhere under
dir2 rather than dir1).

Here's the output from my script showing all the files that exist in
each of the relevant commits:

=== Original ===
dir1/otherfile
dir1/python1/test1.py
dir2/otherfile
dir2/python2/test2.py
dir3/otherfile
dir3/python3/test3.py

=== Consolidated ===
dir1/otherfile
dir2/otherfile
dir2/python1/test1.py
dir2/python2/test2.py
dir2/python3/test3.py
dir3/otherfile

=== New files ===
dir1/otherfile
dir1/python1/new_test/test5.py
dir1/python1/test1.py
dir1/python1/test4.py
dir2/otherfile
dir2/python2/test2.py
dir3/otherfile
dir3/python3/test3.py

=== Merged result ===
dir1/otherfile
dir2/otherfile
dir2/python1/new_test/test5.py
dir2/python1/test1.py
dir2/python1/test4.py
dir2/python2/test2.py
dir2/python3/test3.py
dir3/otherfile


and here's the script I used to run this testcase and generate the above output:

#!/bin/bash

git init -b main nukeme
cd nukeme

echo '''
│   └── dir1
│   │   └── python1
│   │   │   └── test1.py
│   └── dir2
│   │   └── python2
│   │   │   └── test2.py
│   └── dir3
│   │   └── python3
│   │   │   └── test3.py
''' >/dev/null
for i in $(seq 1 3); do
    mkdir -p dir$i/python$i
    echo $i >dir$i/python$i/test$i.py
    >dir$i/otherfile
done

git add .
git commit -qm "Initial"

git branch consolidated
git branch newfiles

git checkout consolidated
echo '''
│   └── dir1
│   └── dir2
│   │   └── python1
│   │   │   └── test1.py
│   │   └── python2
│   │   │   └── test2.py
│   │   └── python3
│   │   │   └── test3.py
│   └── dir3
''' >/dev/null
git mv dir1/python1 dir2/
git mv dir3/python3 dir2/
git commit -qm consolidated

git checkout newfiles
echo 4 >dir1/python1/test4.py
git add dir1/python1/test4.py
mkdir dir1/python1/new_test
echo 5 >dir1/python1/new_test/test5.py
git add dir1/python1/new_test/test5.py
git commit -qm newfiles

git checkout -qb merged consolidated
git merge --no-edit -s ort newfiles

echo
echo "=== Original ==="
git ls-tree -r --name-only main
echo
echo "=== Consolidated ==="
git ls-tree -r --name-only consolidated
echo
echo "=== New files ==="
git ls-tree -r --name-only newfiles
echo
echo "=== Merged result ==="
git ls-tree -r --name-only merged