libgit2sharp icon indicating copy to clipboard operation
libgit2sharp copied to clipboard

The set filemode is incorrect

Open georgii-sosnovikov opened this issue 3 years ago • 8 comments

Reproduction steps

Azure DevOps

  1. Create YAML Pipeline just for monitoring filemode (show all files with filemode, script: git ls-files --stage) and create build validation policy for main branch

  2. Create file "test1.sh" in folder "folder1", create PR to main and complete it

  3. On new branch make changes, push it, hard reset to previous commit, create "folder2", move "test1.sh" to this folder, change filemode to 100755 (git update-index --chmod=+x file_name), force push, create PR to main and complete it

  4. Switch to previous commit (before changing folder and file mode), push any changes, create PR to main and check build validation pipeline logs on the PR

Expected behavior

File mode is 100755 (new)

Actual behavior

File mode is 100644 (old)

Version of LibGit2Sharp (release number or SHA1)

14.0.29222.1

Operating system(s) tested; .NET runtime tested

Windows 10, .NET 4.8

georgii-sosnovikov avatar Mar 30 '22 10:03 georgii-sosnovikov

I'm not sure exactly what you mean by these actions:

On new branch make changes, push it, hard reset to previous commit

...and...

Switch to previous commit (before changing folder and file mode), push any changes,

What LibGit2Sharp methods are you invoking to do this work? Can you share sample code that reproduces this?

Also:

14.0.29222.1

is not a LibGit2Sharp version. Can you be more precise about the version of LibGit2Sharp that you're using?

ethomson avatar Mar 30 '22 16:03 ethomson

I found simpler reproduction steps:

Azure DevOps:

  1. Create branch dev1 from main, create file1.sh in folder1, merge to main
  2. Create branch test based on main
  3. Create branch dev2 from main, move file1.sh to folder2 and change mode for file1.sh, merge to main
  4. Checkout to test branch, push any changes.
  5. Merge test branch to main branch (OK, file1.sh 100755 mode)
  6. Check mode for file1.sh

Expected: file1.sh 100755 mode Actual: file1.sh 100644 mode

When doing step 5 using git bash, the problem does not occur.

Method that returns the wrong file mode - MergeCommitsIntoIndex with the following mergeOptions: FailOnConflict - false, FindRenames - true, MergeFileFlavor - Normal, RenameThreshold - 100, SkipReuc - false, TargetLimit - 500

LibGit2Sharp version - 0.26

georgii-sosnovikov avatar May 03 '22 21:05 georgii-sosnovikov

@ethomson Gentle ping, it is still problem for us

georgii-sosnovikov avatar Jul 07 '22 13:07 georgii-sosnovikov

I added a thumbs-up on the previous comment, but I'll add another gentle ping as I suspect that doesn't bump the thread.

jrb-github avatar Nov 16 '22 13:11 jrb-github

@ethomson , could you please look into this?

georgii-sosnovikov avatar Apr 04 '24 13:04 georgii-sosnovikov

I'm sorry, I don't understand what the problem is. Can you show me some .NET code?

Are you reporting a bug in Azure DevOps?

ethomson avatar Apr 04 '24 14:04 ethomson

Err.. @georgii-sosnovikov — I see that you're part of the Microsoft org in GitHub. Are you on the Azure DevOps team?

ethomson avatar Apr 04 '24 15:04 ethomson

Hi @ethomson , yes, I am.

Let me please add a bit of context here. When merging with pull requests, the MergeCommitsIntoIndex method from LibGit2Sharp is used and in one of the cases we found, there is some unexpected behavior

The 1st case (where we see the bug)

The source branch, let's call it "test", contains:

  • folder1/file1.sh file with "hello" content (same as in the target branch) and has filemode 100644
  • README.md file with "readme changed" content

The target branch to merge into is called "main" and contains:

  • folder2/file1.sh file (the folder was renamed after the "test" branch was created) with the content "hello" and has filemode 100755 (filemode was changed after the "test" branch was created)
  • README.md file with "readme" content

When the PR is created (test -> main), you can see that only the README.md file is actually modified (the comparison is done through the base commit of both branches) and file1.sh should not be changed. But during the PR merge, the MergeCommitsIntoIndex method returns folder2/file1.sh with a NonExecutableFile mode 100644, when it should remain as 100755 in main, no changes were made to this file in this PR.

image

The passed mergeOptions you can see in my comment above

The 2nd case (everything is fine here)

The source branch, let's call it "test", contains

  • folder1/file1.sh file with content "hello" and has filemode 100644
  • README.md file with "readme changed" content

The target branch to merge into is called "main" and contains:

  • folder1/file1.sh file with the content "hello changed" (the content was changed after the "test" branch was created) and has filemode 100755 (the filemode was also changed after the "test" branch was created)
  • README.md file with "readme" content

In this case, the only change the PR (test -> main) introduces is a change to the README.md file (just like in the first case) and file1.sh file should not be changed during merge and in fact when the PR is finished, file1.sh file is not changed. The MergeCommitsIntoIndex method returns the expected result and everything after that works correctly.

I hope it's going to shed some light on the issue

georgii-sosnovikov avatar Apr 08 '24 16:04 georgii-sosnovikov