Commit Briefs
prevent commits from being listed more than once in a histedit script
While merging a commit multiple times during a histedit operation could potentially make sense in some corner case, a commit appearing more than once in the script is more likely to happen accidentally. If desired, the same effect can still be achieved by running multiple histedit operations, or by using 'got cherrypick' while the histedit operation is paused for arbitrary editing.
be helpful when users try to check out work trees without a known branch
Provide a useful error message in such cases and explicitly document intentional restrictions in the got(1) man page. Prompted by a question from Adam Steen via bsd.network https://bsd.network/@adams/103768951483318235
show merged commit ID + logmsg upon merge conflict during rebase and histedit
This makes it more apparent which commit contained the conflicting change. The new output looks like this: C sys/dev/pci/if_iwm.c 8a98d848a1a5 -> merge conflict: properly modify station queues got: conflicts must be resolved before rebasing can continue
make tmp dir location a compile-time setting and change gotweb's tmp dir
We are not sure whether a gotweb package can own /var/www/tmp on OpenBSD. Moving gotweb's tmp dir to /var/www/got/tmp sidesteps that issue.