Commit Briefs
regress: consistently use ed -s
didn't know about -s when writing those tests; saves some output redirection. ok jamsek
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@
histedit: make sure mesg is only used after pick or edit
It doesn't really make sense to use mesg after a fold or drop, or after another mesg. it currently "works" as intended, but the behaviour is confusing and not useful, better abort the operation as it's probably not what the user intended. Suggested by and ok stsp@
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.
add test for merge result when lines are inserted at the top of a file
Based on a patch by Omar Polo
fix histedit_no_op test which was failing randomly
A no-op replayed history ends up having exactly the same commit IDs if all commits are created at roughly the same moment in time. There are no content changes involved so if commit timestamps do not differ then commit hashes will be the same. In which case there is no fork in history for 'got histedit -l' to display, yet the test was always expecting a fork in history to be displayed. Update the test to take this issue into account. The test will now pass no matter which result is produced by the histedit operation. Problem found by Lucas who observed that this test was randomly failing. Patch also provided by Lucas.
ensure that old commits remain referenced after rebase and histedit
Create automatic "backup" references which ensure that objects from the pre-rebase or pre-histedit state remain in the repository. A new -l option for 'got rebase' and 'got histedit' lists old commits. This makes it easier to recover from botched rebase or histedit operations. Removal of such objects currently requires got ref -d and git-gc. This will be made more convenient in the future. testing and ok jrick
implicitly mark all files in work tree as up-to-date after rebase/histedit
This should always be correct, since rebase and histedit start out with a clean and single-base-commit worktree, and end up committing all changes across the entire work tree when they are successful. tested by jrick and myself
make 'got histedit' collapse folded add+delete operations into a no-op
If a merged commit wants to delete a locally added file, and this locally added file matches the content which was deleted in the commit being merged, we can go ahead with the deletion because there is no risk of data loss. fixes the histedit problem reported by jrick on freenode
add an xfail test for a histedit issue where a deleted file remains
If a previous commit introduces a new file, and it is folded into a commit that deletes the same file, the file still exists after the histedit. reported by jrick on freenode
add a -q option to tests for quiet output and use it for 'make regress'
Previous default output remains when test cases are run individually. ok tracey