Re: [PATCH 0/3] Re-fix rebase -i with SHA-1 collisions
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Jan 17, 2020, 09:51 UTC
- Message-ID
- <nycvar.QRO.7.76.6.2001171050000.46@tvgsbejvaqbjf.bet>
- In-Reply-To
- <20200116235411.GZ6570@camp.crustytoothpaste.net>
Hi brian,
On Thu, 16 Jan 2020, brian m. carlson wrote:
Show 24 quoted lines
> 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