fatal: git checkout: updating paths is incompatible with switching branches.

Issue #105 closed
Frank Löffler created an issue

Trying to checkout from a non-existing git branch gives the following error message:

fatal: git checkout: updating paths is incompatible with switching branches.

GetComponents gives an error, but only for the first link into such a repository, and the directories and links are also there after the checkout - but not of any other than the master branch. If someone overlooks the error at the end, a full and possibly working configuration could be built, but it would use the wrong version of the git repo. GetComponents should not checkout repositories if the given branch was not found, even with error message at the end. (updating by rerunning GetComponents later doesn't show this difference in braches as well, only indicating that all is there and well).

It would be nice (but not important, if too complicated), if a better message could be given in this case.

Keyword:

Comments (10)

  1. Eric Seidel
    • changed status to open
    • removed comment

    OK, so we should probably just delete the repository if the branch checkout fails. This will prevent any confusion as to whether the repository was properly checked out or not. It would also make any checking for the update phase unnecessary.

  2. Erik Schnetter
    • removed comment

    Actually, GetComponents should never delete anything. Imagine if the user has local modifications that are then deleted, or if this confusion is due to a typo in the thorn list.

    If GetComponents is really sure that all that is deleted was just checked out (and didn't exist beforehand locally), then it may delete things. But this is still dangerous, especially while GetComponents is debugged.

    Instead of deleting it could rename, which would also avoid confusion, e.g. to "repo-thisdidnotworkout".

  3. Eric Seidel
    • removed comment

    That's a good point. Do you know of an easy way in Perl to attach an increasing number to the end of the directory name, i.e. "repo-thisdidnotworkout-1", "repo-thisdidnotworkout-2" (in case this happens multiple times, a second mv command will fail and the directory name will be unchanged).

  4. Eric Seidel
    • changed status to resolved
    • removed comment

    This issue has been resolved in svn-revision 707. GetComponents will report the error, and change the repo name to "<repo>-branch-failed"

  5. Erik Schnetter
    • changed status to open
    • removed comment

    The code that renames the repository does not check whether the "*-branch-failed" name already exists. It should do something clever in this case.

    The error message should also indicate that the repository was renamed. In the case of a git repository, many symlinks will now be broken.

    The code for git repositories contains a "cd ..", while the code for hg repositories does not. Is that intentional?

  6. Eric Seidel
    • removed comment

    GetComponents will now warn users that the symlinks will be broken, and it will add a timestamp to the repository ("$repo.branch.failed.$month.$day.$year"). I think this is probably sufficient, do you agree? The "cd .. " bit has been completely removed with the new run_command structure.

  7. Eric Seidel
    • changed status to resolved
    • removed comment

    I changed my mind and just implemented an increasing number as the extension, ie carpet.branch.failed, carpet.branch.failed.1, etc.

  8. Log in to comment