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. Best Wishes Phillip [1] https://public-inbox.org/git/d7acf780-522d-84e6-68b8-d8d35a305588@xxxxxxxxxxxx/T/#maa521f788bd61f9b65d52c14430a88bf077e6752
