Community
Participate
Working Groups
File mode check to determine 'dirty working tree' while merging fails even if the working tree is clean (verified with 'C' git implementation). Proposed temporary fix: Switch to suppress this check for API users when they are sure that they are not manipulating the working tree. Code: isWorktreeDirty() in org.eclipse.jgit.merge.ResolveMerger.java Marking as major severity because might prevent users from merging.
Hi, can you provide the steps to reproduce this behavior?
My workflow is: 1) fetch remote branch to FETCH_HEAD 2) create temporary branch starting at FETCH_HEAD 3) fetch remote ref to FETCH_HEAD 4) cherry-pick last commit from FETCH_HEAD this is were the cherry picking fails due to failing merge and gives DIRTY_WORKTREE as a cause line 574 in ResolveMerger.java: final boolean isDirty = nonTree(modeF)&& !(tw.idEqual(T_FILE, T_OURS) && modeO == modeF); the three booleans that isDirty is evaluated from are true, false, false respectively
Both JGit Status (returned by StatusCommand) and 'C' git show clean working tree at this point. I have tried doing a mock commit just before cherry-picking and it didn't work either.
Did you happen to record the raw modes being reported for both files?
Took a sec to retrieve, here you go: modeF = 33188 modeO = 33261
You can also try to write a JUnit test that would help detect the problem.
For the failing commit, do you know which file in the commit (if there is more than one) is causing this? Is it just a regular file? that exists in the current branch but is just being updated in the commit being cherry picked? Just trying to find a reduction case to work from.
Yes, it's a regular text file (.py in my case) that is already in the branch and get's updated in the cherry-picked commit (insertion).
Have you tried other cherry picks that have completed normally or are all failing?
It's my first test case and I stopped there since the error seemed to have nothing to do with the file. I am not modifying it and 'C' git cherry-picks fine if I stop the execution at this point.
Could the file be changing from regular to executable in that commit where the cherry pick is failing?
Doesn't look like it is changing (at least not when JGit is used to reproduce with exception ignored). -rwxr-xr-x before and after
What version of JGit are you using?
I am now using the repository source code but I had the same problem when using the latest release.
Would it be possible to share the repository you are seeing the issue on? That would make is much easier to debug.
Unfortunately no. There's nothing special about it though apart from the fact that it is ssh Gerrit based so ref is a Gerrit change.
Kevin, can you tell what the file modes that I have pulled tell you?
> modeF = 33188 > modeO = 33261 33188 (modeF) decodes to octal 100644 which means regular file 33261 (modeO) decodes to octal 100755 which means executable file
> Doesn't look like it is changing (at least not when JGit is used to reproduce > with exception ignored). -rwxr-xr-x before and after I need to take that back. I had checked it with msysgit which is bad at figuring out file modes.
Okay, I have some more information. The file permissions are not changed in the commit (X) that I cherry-pick. However, they are changing between parent of this commit and current head on the branch. Diff between A and D reads: diff --git a/gobuild/gobuild.py b/gobuild/gobuild.py index 8f487f4..2e9acfb 100755 --- a/gobuild/gobuild.py +++ b/gobuild/gobuild.py Before cherry-pick: A---B---C---D \ X After cherry-pick: A---B---C---D \ X Is it desirable to block cherry-picking changes from a file with different permissions? 'C' git seems to allow that.
Just to confirm, in your example, you are cherry picking commit X whose current parent is A and is being cherry picked onto D, and in commit B, C, or D a file is changed to executable that is also changed in X?
(In reply to comment #21) > Just to confirm, in your example, you are cherry picking commit X whose current > parent is A and is being cherry picked onto D, and in commit B, C, or D a file > is changed to executable that is also changed in X? Yes, I thought that's what I had written :) B, C and D are just symbolic in the example but the file has changed into executable somewhere on the way.
Created attachment 215509 [details] commit graph screenshot Yeah, it looked like the X commit was hanging off of C which I didn't completely get.
Created attachment 215510 [details] win 7 commit tree screenshot
(In reply to comment #24) > Created attachment 215510 [details] > win 7 commit tree screenshot Sorry, it's mono-spaced for me so I assumed it's like that for everyone.
Proposed fix pushed to https://git.eclipse.org/r/5961
This has been merged into stable-2.0 in commit 59a98b49d2bf1e4514967dfa0acbceea6b37dbd4
