Commit Briefs
show commit progress output when 'got merge -c' is used
Otherwise no progress output is shown at all with this command. Commit progress output will also display any additional changes which resulted from conflict resolution. ok millert@
for portability, handle errno variations upon open(2) failure with O_NOFOLLOW
Problem pointed out by naddy for FreeBSD -portable. Discussed with millert, thomas adam, and naddy.
allow bad symlinks to survive a merge
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
fix 'got update' of an added + obstructed file
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
stop using the term 'obstructed' ambiguously in the got.1 man page
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.
stop caring about obstructed versioned files in 'got merge'
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.
add a 'got merge' command for creating merge commits
Additional testing by Thomas Adam. ok tracey
fix histedit_no_op test which was failing randomly
A no-op replayed history ends up having exactly the same commit IDs if all commits are created at roughly the same moment in time. There are no content changes involved so if commit timestamps do not differ then commit hashes will be the same. In which case there is no fork in history for 'got histedit -l' to display, yet the test was always expecting a fork in history to be displayed. Update the test to take this issue into account. The test will now pass no matter which result is produced by the histedit operation. Problem found by Lucas who observed that this test was randomly failing. Patch also provided by Lucas.
tog: use sched_yield(2) instead of pthread_yield(3) for portability
pthread_yield(3) is an optional POSIX 2001 extension while sched_yield(2) is part of POSIX 2008. On OpenBSD they are actually equivalent, albeit not documented as such. Using sched_yield(2) helps the -portable version. Patch by Quentin Rameau