Problem pointed out by naddy for FreeBSD -portable. Discussed with millert, thomas adam, and naddy.

Commands which perform merges will now install bad symlinks as symlinks in the work tree, instead of creating them as regular files. This means bad symlinks committed with 'got commit -S' (or Git) will be preserved. The decision to introduce a bad symlink is done at commit-time and merges should not forcefully reverse this decision. The cherrypick and backout commands require a manual commit step, and a merge result with bad symlinks will require use of 'got commit -S'. Additional testing by thomas adam

ok stsp

When 'got update' tried to add a new file to the work tree and this file was obstructed by, say, a directory on disk, the update failed: $ got update ? new got: new: Is a directory $ And the work tree was not updated. With this commit this situation is properly detected as an obstruction and the update succeeds: $ got update ~ new Updated to refs/heads/master: c1f85b4938dc4c668a88f13df2b98a520fc077cc File paths obstructed by a non-regular file: 1 $ Extend a corresponding test case to cover this issue. ok tracey

Specifically, obstructed files are versioned files which should be on disk but have been replaced on disk by a non-regular file (e.g. by a directory). The man page used the phrase "deletion was obstructed" which is unrelated to the above concept and can be expressed as "deletion was prevented" instead.

Tyring to write a test to cover this case I found that obstructed files are (correctly) detected as local modifications in the work tree. Thus they trigger the pre-condition check for local modications and 'got merge' will not even start to do any work in the presence of obstructed files.

Additional testing by Thomas Adam. ok tracey

ok tracey