Hi Phillip, On Wed, Feb 20, 2019 at 3:00 AM Phillip Wood <phillip.wood@xxxxxxxxxxxx> wrote: > On 22/01/2019 20:39, Junio C Hamano wrote: > > Elijah Newren <newren@xxxxxxxxx> writes: > > > >> Also, I have a fuzzy memory of discussing a very similar case with > >> some rebase-oriented option and its on-disk representation, where the > >> concern was more about users upgrading git versions during an > >> incomplete rebase rather than power users looking at internal file > >> contents. And I think either Phillip or Junio made some statement > >> about considering these internal details and that they felt the worry > >> about upgrade mid-rebase was overly worrying. But I can't find the > >> emails right now, and it's been so long (at least half a year) that I > >> might be imagining things. > > > > I do recall saying that mid-rebase upgrade is probably not worth > > getting worried about. > > > > In light of yesterday's bug report [1] about those other changes I'm > more concerned about this change. We were worrying about whether or not > to worry about a mid-rebase upgrade but it seems people can have two > different versions of git installed - one bundled with something like > tig and another they use on the command line. If they start a rebase > with a version containing this patch and try to continue it with a > version that does not then the older version will fail with a complaint > about a missing quiet file. The other way round they'll potentially get > the wrong quiet setting which isn't such a problem. It's probably a bit > late in the release cycle now to change this? But we could flag it up in > the release notes and bear it in mind when making changes in the future. Thanks for the heads up; I'll try to keep it in mind for the future.
