Hi brian, On Thu, 16 Jan 2020, brian m. carlson wrote: > On 2020-01-16 at 21:18:23, Johannes Schindelin via GitGitGadget wrote: > > 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. > > This series looks great to me, and thanks for fixing this. > > As mentioned in the PR, I'm happy for you to drop the SHA-256 patch into > this series if you like, or I can carry it in a future series. Either > way is fine with me. Excellent. Given that the re-fix to avoid short commit ID collisions has little to do with supporting SHA-256, I would like to keep the patch series separate, then. The question whether to move the SHA-256 support patch into your series is more a question to Junio, i.e. which patch series will be merged down faster. Junio, what is your preference here? Ciao, Dscho
