I have a GitHub repository which I use for all my development projects. One of my customers recently asked me to switch to BitBucket instead and hook up with Jira. During that process something went terribly wrong, and I decided to recover to my faithful GitHub.
Apparently I must have deleted some local git repositories, because all of the sudden I can't check out my 'development' branch, because it is already checked out in a nonexistent repository (or at least I can't find it).
As per now I have no waiting commits of local changes and everything. How do I do a reverse checkout on a nonexistent repository?
Edit: the output of:
git branch -vv
is:
development f6822f0 (D:/Development/VSJ5.WPF/.git_master_UserInterface)
origin 386d25f (D:/Development/VSJ5.WPF/.git_master)
doing a git checkout development I get:
fatal: 'development' is already checked out
at 'D:/Development/VSJ5.WPF/.git_master_UserInterface'
Problem is that these are not referring to my .git repository and as such not available.
CodePudding user response：
In this particular situation I simply did a full delete of the current directory and cloned it again from the GitHub. In this process I had to accept, that some commits were not included, whick actual were committed before into the 'extra' repositories.
CodePudding user response：
Your output indicates that you have not (well, had not) deleted the repository at all. Instead, you had used git worktree add to add a secondary working tree to your existing repository. Use git worktree list to view your added working trees. Remember that the .git folder is normally hidden from view, so that you don't see it; in added working trees, instead of a .git folder, Git stores a .git file that records where the actual repository is stored.1
In your own answer, you mention that you subsequently deleted the repository, and then re-cloned. Deleting the repository destroys all the commits within that repository, including any commits being used by any added working trees. There is no in-Git recovery for this, though any backups your system made (such as those made by macOS Time Machine) might be useful.
1Remember that a Git repository is, to a first approximation, just a pair of databases. One holds all the commits and other supporting objects, which Git finds by their numbered hash IDs. The other database holds names, where each name—branch name, tag name, or any other name—holds a single hash ID, of something important to be able to find. For branch names, the stored hash ID is, by definition, the latest commit on the branch. Making a new commit while being "on" some branch creates a new commit with a new, never-before-used hash ID, and then stores that new commit's hash ID into the branch name.
It's the commits in the repository that hold what you are interested in—or what Git, at least, cares about. The names let you and Git find the "most interesting"—most recent—commits, from which Git will find earlier commits. The stuff inside the commits is strictly read-only: your OS can remove the database entirely, but not even Git can overwrite any of the commits stored within the database (unless there are severe bugs in Git that is).
You do not work in the Git repository. Instead, a standard clone copies all the commits of some other repository to a new repository, then creates one branch name in your own clone to remember your own latest commit (but starting with some copied commit, until you make a new commit). This clone then has one standard working tree or work-tree. Git copies the commit's files, which are read-only, from the commit to your working tree. You then work within your working tree. The main working tree, created at the time you create the clone, holds one checked-out branch. Added working trees from git worktree add hold one other checked-out branch each.
A so-called bare clone is one with no working tree. The usual purpose of such a clone is to act as a storage area for commits, with no work to be done on, with, or in any of the branches. Because a bare clone has no working tree, you cannot do any work on or with it. You can, however, add working trees to a bare clone. This is not a mode of use that was anticipated by the core Git team and it does not work very well in current versions of Git, but this is being remedied now, around Git 2.35 or 2.36 or so. There may still be some bugs in this area and I advise against doing this yet.
Your own git branch -vv output suggests that you had made a bare clone and then added two separate working trees. Since this is not well supported yet, you may have run into some Git bugs.