How to deal with "Detached Working Copy" message

Sometimes, the Git interface shows a "Detached Working Copy". This page describes some approaches to resolving the issue.

Generally, the "Detached Working Copy" state means that one or both of the following are true:

1. The git respository is in "Detached Head".

2. The git repository HEAD is pointing to a commit that is different to the commit expected by the image.

Another complication is that there may be changes in the image that should be committed.

Assuming you DON'T have uncommitted changes in the image...

... or you don't care about the changes in the image and just want the code as it exists in the repository.

In this case you need to checkout a branch, e.g. main:

GtGitRecoverDetachedHead new 
	repositoryName: '<repository name here>';
	mainBranchName: 'main';
	recover.
  

If you DO have uncommitted changes in the image...

In this case there are three basic strategies you can follow:

1. File out the changed code, get the repository back to the latest version, load it in the image and file in the changed code.

Pros:

It's easy if there are only a few changes.

Cons:

It will lose changes if filed out code is also modified as part of the repository recovery.

If there are a large number of changes, there's a risk that some changes won't be filed out.

The file-out code is buggy, subclasses can be filed-out before superclasses, resulting in a file that can't be loaded. This will need manual editing of the file to fix.

2. Get the repository back to the latest version, load it in the image and recover changes through Epicea.

Pros:

It's easy if there are only a few changes.

Cons:

It can lose changes if filed out code is also modified as part of the repository recovery. Checking each Epicea change against the image can avoid this, but it is a manual and error prone operation.

The more changes there are the greater the chance of a mistake.

3. Use a recovery branch in git

This has a larger number of steps and is more difficult to understand, but is the most reliable method as it uses git to catch any code conflicts.

Pros:

The most reliable of the three, git will catch any conflicts.

Cons:

The most steps.

Conflicts must be resolved by manually editing the tonel files.

The third approach is detailed below.

NOTE: This hasn't had enough testing yet!!!!!!!!!!!!

GtGitRecoverDetachedWithUncommittedChanges new
	repositoryName: '<repository name here>';
	commitMessage: 'Merge changes from image and repository';
	mainBranchName: 'main';
	"saveImage: true;"
	ensureDeleteRecoveryBranch;
	recover.
  

Earlier Notes

This happens when the code from the image is older than the code from the local git repository directory. This can happen when:

you modify code in an image,

you commit code to Git,

you close the image without saving, and then

you reopen the image.

To resolve this, you can repair the issue by synchronizing the code in the image with the one in the local directory.