Commits
- Commit:
a615e0e7796ea1103a6e0d4b5dbb613459788666- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
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
- Commit:
a347e6bb7cfe1f6a9df6234f6949003191418466- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
test behaviour of histedit -f with an empty log message
- Commit:
239f5c5ae4c041d2ea8dddae394ce357b016b7a1- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
add a basic test case for histedit -f
- Commit:
29c68398c5b5c7fc7ff5534ed3921b6faa9912a9- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
check final repository state in test_histedit_fold_add_delete
- Commit:
0a22ca1a5a1261bb7e230db211a205b68e1c3044- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
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
- Commit:
ecfff807e1145877b3360f07915ef8e3af0e2751- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
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
- Commit:
f6cae3ed1ef0c22150181eeebb8f9e97db99dc5a- From:
- Christian Weisgerber <naddy@mips.inka.de>
- Date:
switch function declarations from Korn shell to Bourne/POSIX shell syntax
ok stsp
- Commit:
7fb414ae4d46ebdaeff458477ba801f9ad5853c4- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
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
- Commit:
e31abbf21f99a7312bdfd392f33ace285feadfe5- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
add -c option to 'got ref' which now expects just one argument after options
- Commit:
5b87815ed2f346f81374261ce2d633feae711886- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
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.
- Commit:
de05890fef951240ac68a3ea9a577a6f82be6194- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
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.
- Commit:
0def28b1b50dd3f59a6207d93034b2b1f77e602e- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix 'last commit cannot be folded' check with reordered commits
- Commit:
f032f1f7ee503b7aa2577cf836c485f96620e772- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
fix and test interaction of rebase/histedit -c and 'got stage'
- Commit:
c7d20a3f8da31a213c3830e6ca9de6d3b0c728bb- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
forbid editing the history of branches outside of "refs/heads"
- Commit:
b2c50a0a51e3a8e22fb1e9867cbf6bc7356acbd3- From:
- Stefan Sperling <stsp@stsp.name>
- Date:
add another histedit test for path prefix behaviour