Details
-
Bug
-
Resolution: Unresolved
-
High
-
None
-
3.1.0-beta-2973
-
When performing a complex rebase deep into a tree, the operation will occasionally fail due to "index.lock" being present, with a message about another git process in operation. If the abort-rebase also fails, the repository can be left in an inconsistent state with possible data loss.
I suspect there is a background process in Sourcetree that is using a git command that monitors for changes/etc that remains active during the rebase process, and there is a race condition where sometimes it manages to grab the lock and causes the rebase to fail. The fix is probably to suspend this process during the rebase and resume afterwards.
To reproduce, select a commit ~15 commits behind the current branch, and select "rebase children of DEADBEEF interactively". Then squash some of the commits at the bottom, or edit some messages, etc to cause everything above it to be rebased onto the changed commit.
It does not occur every time, but farther back is more likely to cause it to reproduce, so try going farther back if you can't get it to reproduce.
Strangely, the bug does not seem to occur when running a command-line interactive rebase, even if SourceTree is still open (tested once or twice but not thoroughly confirmed)
When performing a complex rebase deep into a tree, the operation will occasionally fail due to "index.lock" being present, with a message about another git process in operation. If the abort-rebase also fails, the repository can be left in an inconsistent state with possible data loss. I suspect there is a background process in Sourcetree that is using a git command that monitors for changes/etc that remains active during the rebase process, and there is a race condition where sometimes it manages to grab the lock and causes the rebase to fail. The fix is probably to suspend this process during the rebase and resume afterwards. To reproduce, select a commit ~15 commits behind the current branch, and select "rebase children of DEADBEEF interactively". Then squash some of the commits at the bottom, or edit some messages, etc to cause everything above it to be rebased onto the changed commit. It does not occur every time, but farther back is more likely to cause it to reproduce, so try going farther back if you can't get it to reproduce. Strangely, the bug does not seem to occur when running a command-line interactive rebase, even if SourceTree is still open (tested once or twice but not thoroughly confirmed)
-
Severity 1 - Critical
Description
When performing a complex rebase deep into a tree, the operation will occasionally fail due to "index.lock" being present, with a message about another git process in operation. If the abort-rebase also fails, the repository can be left in an inconsistent state with possible data loss.
I suspect there is a background process in Sourcetree that is using a git command that monitors for changes/etc that remains active during the rebase process, and there is a race condition where sometimes it manages to grab the lock and causes the rebase to fail. The fix is probably to suspend this process during the rebase and resume afterwards.
To reproduce, select a commit ~15 commits behind the current branch, and select "rebase children of DEADBEEF interactively". Then squash some of the commits at the bottom, or edit some messages, etc to cause everything above it to be rebased onto the changed commit.
It does not occur every time, but farther back is more likely to cause it to reproduce, so try going farther back if you can't get it to reproduce.
Strangely, the bug does not seem to occur when running a command-line interactive rebase, even if SourceTree is still open (tested once or twice but not thoroughly confirmed)
