When an operation is interrupted add a trailing message to status output which displays the operation and branches involved. This information will be useful when diagnosing problem reports and it helps new users with contextualizing multi-operation work tree state. ok op@

This matches the existing use of "got -r path cmd" and "git_commit path args".

ok stsp@

For user-facing messages it is better to avoid technical jargon like this and instead spell out what the fast-forward situation implies: that one branch is already based on another. ok jamsek

ok op, james

Split part of got_worktree_merge_prepare into a new function, got_worktree_merge_write_refs, since that part doesn't make sense in the fast-forward case. ok stsp@

Diff from James Cook, thanks!

Otherwise, 'got merge -c' can silently revert already committed changes. Also fix GOT_ERR_MERGE_COMMIT_OUT_OF_DATE by giving it a value distinct from GOT_ERR_MERGE_STAGED_PATHS. Patch by James Cook

-c option wasn't passed. Patch by James Cook.

Requested by James Cook

Otherwise we leave unversioned files behind in the work tree which may interfere with new attempts to rebase or merge the changes again. Problem found by + ok naddy@

cmd_merge is the only subcommand that may create commits that doesn't parse the git config files, thusly failing for users without GOT_AUTHOR defined. Problem reported by James Cook who also provided an initial test case, thanks! ok jamsek

This behaviour is already documented in got-worktree(5) but wasn't actually implemented. ok stsp@

This brings the rest of the regression test scripts in line with patch.sh.

Don't use '==' for equality matching in sh, as this won't work across all shells. ok @naddy

ok jrick

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@

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

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.