On Fri, Aug 26, 2016 at 8:27 PM, Steve Fink <sf...@mozilla.com> wrote:
> On 08/26/2016 08:16 PM, Gregory Szorc wrote: > >> >> On Aug 26, 2016, at 19:54, Kan-Ru Chen <kc...@mozilla.com> wrote: >>> >>> Hello, >>> >>> In Bug 1297276 I landed a patch to rename mozilla/unused.h to >>> mozilla/Unused.h to make it more consistent with our other MFBT headers. >>> Normally rename a header shouldn't cause too much trouble, however this >>> rename is only changing the case so you might experience some problems >>> on case insensitive filesystem. >>> >>> As pointed out by Tim in >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1297276#c19 if you use >>> |git pull -f| to update local copy of gecko and git refuse to, you can >>> rm mfbt/unused.* first to make git happy. >>> >> Case only renames cause a lot of havoc. Somewhere there is an open bug to >> implement a server side hook to reject them. >> >> What I'm trying to say is thank you for reminding me to implement the >> hook. And congratulations on likely being the last person to perform a case >> only rename on the repo. >> > > For the record, is there a better way to accomplish this? In this > particular case, it seems like we really do want the rename. Would it work > better to do two commits, one from mozilla/unused.h -> > mozilla/LucyTheDancingFerret.h, then another doing > mozilla/LucyTheDancingFerret.h -> mozilla/Unused.h? No. Because if you perform an update/checkout across the rename, you may encounter problems. This can happen when bisecting, for example. Now, this isn't as bad as a case folding collision where you have both unused.h and Unused.h: some filesystems just flat out refuse that. At least with a rename your VCS has the opportunity to delete the old file before creating the different cased one. But even then, build systems and other tools can be confused because some filesystems are case insensitive but case preserving and tools may make inappropriate decisions about whether "unused.h" and "Unused.h" are the same file. There's a lot that can go wrong. So the whole scenario is best avoided. The bug tracking the server hook is 797962 btw. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
