FreeBSD's ed(1) does not accept "0i"; use the equivalent "1i" instead

regress: provide a sed wrapper In order to portably handle the difference in how 'sed -i' works between *BSD and Linux, provide a wrapper to invoke the underying system sed(1) based on which OSTYPE is in use.

regress: use gdate/gln if on *BSD To minimise the amount of churn between the difference in date(1) and ln(n) semantics, use gdate and gln from coreutils.

add test for merge result when lines are inserted at the top of a file Based on a patch by Omar Polo

ignore unversioned files while aborting rebase, histedit, merge or operations ok jrick

add histedit -e option which runs the 'edit' script command for every commit ok jrick

regress: fix test failures using date(1) This patch fixes test failures related the date(1) utility. In the long term we could add a wrapper function to detect valid options for date(1) and use the variant which works on the current OS. For now, this makes some tests pass and shows us where the problems are. OK thomas.adam

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.

fix test data directory name used by test_histedit_fold_add_delete

use the POSIX-compliant "date -u" command to return UTC time; ok stsp

add missing "return 1" to failure handling in the regress scripts ok stsp@

new -X option for removing backups created by got rebase and got histedit ok semarie

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

use POSIX [s1 = s2] syntax instead of [s1 == s2]; patch by Ryo ONODERA

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

test behaviour of histedit -f with an empty log message

add a basic test case for histedit -f

check final repository state in test_histedit_fold_add_delete

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

switch function declarations from Korn shell to Bourne/POSIX shell syntax ok stsp

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

add -c option to 'got ref' which now expects just one argument after options

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.

fix histedit 'rebase commit ID mismatch' error when splitting a commit Commit IDs on histedit's temporary branch can change arbitrarily because the user may create new commits on this branch while editing past commits. So there is no point in trying to verify these IDs like we do during rebase. Add a test case which demonstrates the problem.