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 <arielman22@gmail.com> 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.
Show 12 quoted lines
> 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
donegit 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
