Commits


fix option processing for 'got merge' Don't make -C imply -c (a break statement was missing). Detect -an and -cn conflicts. Simplify by removing unneeded check for conflicting -aC (since -C requires -c, we can rely on the -ac conflict being detected). Update the man page to say -cC is allowed.


add -M option: tell got merge not to fast-forward ok stsp@


reword user-facing error message which mentions "fast-forward" 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


prevent 'got merge' from creating commits on branches outside of "refs/heads/" ok op, james


Implement fast-forward merges. 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@


make 'got tree /' succeed in a work tree Previously, this command would trigger an error: got: /: bad path


dropping unnecessary strlen()s ok jamsek, stsp


avoid strlen in for(;;) ok jamsek, stsp


got, tog: correctly skip HEAD in build_refs_str() s[strlen(s)] == '\0' is banally always true, the intent was to not skip refs that starts with "HEAD". style nit / ok stsp@


make 'got status' error out as intended when invoked in a repository


make 'got merge -c' fail even if new changes only affect unrelated paths 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


make "got merge" refuse to run if a merge is in progress and the -a or -c option wasn't passed. Patch by James Cook.


simplify ancestry checks in checkout, update, rebase, and merge No behaviour change as the end result of the rewritten checks should be the same as before. We are just doing less work where possible. Patch by James Cook


make 'got patch' display statistics about files with conflicts and rejects ok op@


got: flush stdout before printing the error in main() Since standard error is unbuffered, it could happen that the error string is printed immediately while the output from the subcommand is stuck in a buffer and written later. So flush() standard output before printing the error message. Problem reported by naddy@, ok stsp@