Commit Briefs
respect umask when creating or changing files and directories
This behaviour is already documented in got-worktree(5) but wasn't actually implemented. ok stsp@
fix regression test failures with Git 3.30.5 / 2.38.1 or later installed
The fix for CVE-2022-39253 in Git made our regression tests fail since creating submodules from local clones is no longer allowed by default. Add an override to our invocations of "git submodule add", the same which was added to Git's regression test suite as part of their fix. This CVE doesn't otherwise affect us. We do not implement submodules. Our use of them in regression tests exists only to ensure that Got does not freak out when it sees one. Precisely because automated support for nested repositories and/or working copies (as in Git Submodules, or Subversion Externals, etc.) have been an endless source of security problems in other systems. sudden test failures pointed out by naddy@
always show commit or tree IDs in diff header, in order to help 'got patch'
The idea is that got patch can simply look for a line such as: commit - abcde1234567... to find the merge base commit ID to show in diff3 conflict markers. got log -p now displays commit IDs in its diff header, instead ofl tree or blob IDs. ok op@
use test(1) -eq and -ne to compare integers, and reduce quoting
This brings the rest of the regression test scripts in line with patch.sh.
sort and de-duplicate work tree path command line arguments
This is important in cases like 'got diff file.txt file.txt' which should only show the diff for file.txt once. suggested by kn@
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
do not update symlinks which are already up-to-date
This fixes spurious 'U' notifications for symlinks during 'got update' that occurred even when the work tree was fully up-to-date. Observed on a work tree of the FreeBSD src repo and reproduced in our test suite by adding a no-op update at the end of a test which deals with updating symlinks.