- changed milestone to ET_2010_11
- removed comment
- changed watchers to ianhinder
fatal: git checkout: updating paths is incompatible with switching branches.
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 (9)
-
reporter -
reporter - changed version to ET_2010_11
- marked as
- changed milestone to ET_2011_06
- removed comment
- removed watchers
-
- 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.
-
- 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".
-
- 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).
-
- 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"
-
- 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?
-
- 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.
-
- 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.
- Log in to comment