Commits


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


in got.1, clarify that rebasing of branches with zero local changes is normal


attempt to more clearly explain what 'got rebase' is used for


disallow 'got rebase' while a histedit operation is in progress


document that 'got integrate' cannot be used during a histedit operation


document histedit's -F option


explain more clearly how a histedit script will be edited


document more clearly what needs to be done to start a histedit operation


switch 'got tag' commit argument to a -c option for consistency


let 'got branch' switch and update the work tree ok tracey


edit man page wording for histedit -m feature


add 'got histedit -m' option which makes it easy to edit log messages only ok tracey


show how to log subdirectories in got.1 EXAMPLES ok naddy


document semantics of got log and tog log path arguments