Re-fix rebase -i with SHA-1 collisions
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v3 Latest3 patches 0 repliesNew
- v23 patches 9 repliesSuperseded
- v13 patches 7 repliesSuperseded
Changes in v3 from the cover letter
* Clarified in the first commit message that the change from a positive return value to a negative return value (to indicate failure, in both cases) both was intentional, and does not require any change in the corresponding function's only caller.
Patches in v3 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/3 | parse_insn_line(): improve error message when parsing failedsequencer.c | +4 | 0 replies | |
| 2/3 | rebase -i: re-fix short SHA-1 collisionsequencer.c t/ | +23 | 0 replies | |
| 3/3 | rebase -i: also avoid SHA-1 collisions with missingCommitsCheckrebase-interactive.c t/ | +7 | 0 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v3 yet.
Cover letter [PATCH v3 0/3] Re-fix rebase -i with SHA-1 collisions
Triggered by one of brian's SHA-256 patch series, I looked at the reason why the SHA-1 collision test case passed when it shouldn't. Turns out that the regression test was not quite thorough enough, and the interactive rebase did regress recently.
While in the area, I realized that the same bug exists in the code backing the rebase.missingCommitsCheck feature: the backed-up todo list uses shortened commit IDs that may very well become ambiguous during the rebase. For good measure, this patch series fixes that, too.
Finally, I saw that git rebase --edit-todo reported the line in an awkward, maybe even incorrect, way when there was an ambiguous commit ID, and I also fixed that.
To make sure that the code can be easily adapted to SHA-256 after these patches, I actually already made those adjustments on top and offered them up at https://github.com/bk2204/git/pull/1.
Changes since v2:
* Clarified in the first commit message that the change from a positive return value to a negative return value (to indicate failure, in both cases) both was intentional, and does not require any change in the corresponding function's only caller.
Changes since v1:
* Turned the error condition when parsing the todo list with just-expanded commit IDs failed into a BUG().
Johannes Schindelin (3):
parse_insn_line(): improve error message when parsing failed rebase -i: re-fix short SHA-1 collision
rebase -i: also avoid SHA-1 collisions with missingCommitsCheck
rebase-interactive.c | 8 +++++--- sequencer.c | 18 ++++++++++++++---- t/t3404-rebase-interactive.sh | 17 +++++++++++++++-- 3 files changed, 34 insertions(+), 9 deletions(-)
base-commit: d0654dc308b0ba76dd8ed7bbb33c8d8f7aacd783
Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-529%2Fdscho%2Fre-fix-rebase-i-with-sha-collisions-v3
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-529/dscho/re-fix-rebase-i-with-sha-collisions-v3
Pull-Request: https://github.com/gitgitgadget/git/pull/529
Range-diff vs v2:
1: 2ae2e435b0 ! 1: 6f5c7b0325 parse_insn_line(): improve error message when parsing failed
@@ -7,6 +7,11 @@
That makes it rather hard for users to understand what is going wrong, so let's fix that.
+ While at it, return a negative value from parse_insn_line() in case of
+ an error, as per our convention. This function's only caller,
+ todo_list_parse_insn_buffer(), cares only whether that return value is
+ non-zero or not, i.e. does not need to be changed.
+
diff --git a/sequencer.c b/sequencer.c
2: 102fa568dc = 2: 595ba81e09 rebase -i: re-fix short SHA-1 collision 3: 486e9413a6 = 3: b7b063408f rebase -i: also avoid SHA-1 collisions with missingCommitsCheck
Signature · 1 line
gitgitgadget