On Sun, Oct 5, 2014 at 12:47 PM, Renato Golin <renato.golin at linaro.org> wrote:> On 5 October 2014 19:45, Chandler Carruth <chandlerc at google.com> wrote: > > This is not completely accurate. Both LLD and LLDB were given specific > > exemptions from the coding standards, but Clang wasn't and I wouldn't > expect > > a new subproject to *necessarily* get such an exemption. It might, it > might > > not. > > Why exemptions are made is beyond the point, once it's made, there are > mainly two ways to move to a common point: one big clang-format in the > tree, or a slow moving change on new functions or small refactorings > when moving things around. My point is that the former breaks the > history of the project, while the latter is hard to do without making > it a little worse during the move, which can cause even more pain.Can't the history be re-written? Would something like the following work? 1) Format the initial commit and commit it to a new repository with matching header information (date/time, author, etc) 2) For each formatted commit F, find the corresponding unformatted commit U. Determine the set of all files modified between U and U+1, and reformat all of these files, placing them in the working copy of the new repository. Commit this patch to the new repository using the commit information from U+1. 3) Delete the old repository and rename the new repository to the old repository. Note that variable names are outside the scope of this. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141007/b950975b/attachment.html>
On 7 October 2014 08:28, Zachary Turner <zturner at google.com> wrote:> 2) For each formatted commit F, find the corresponding unformatted commit U. > Determine the set of all files modified between U and U+1, and reformat all > of these files, placing them in the working copy of the new repository. > Commit this patch to the new repository using the commit information from > U+1.You mean, for *every* commit in lld until now? That's not just re-writing the history of the files, but of the project itself! There is no guarantee that what worked in the past works with the history re-written, what was tested then won't be tested now, people that had patches against previous releases won't apply at all. Even if lld had no connections whatsoever to anything else in the external world, I'd still be against it.> Note that variable names are outside the scope of this.Unfortunately, that's one of the biggest changes proposed... cheers, --renato
Not sure I understand. How would reformatting the code change the semantics? Why would something that used to work no logner work with a re-written history? On Tue, Oct 7, 2014 at 12:47 AM, Renato Golin <renato.golin at linaro.org> wrote:> On 7 October 2014 08:28, Zachary Turner <zturner at google.com> wrote: > > 2) For each formatted commit F, find the corresponding unformatted > commit U. > > Determine the set of all files modified between U and U+1, and reformat > all > > of these files, placing them in the working copy of the new repository. > > Commit this patch to the new repository using the commit information from > > U+1. > > You mean, for *every* commit in lld until now? That's not just > re-writing the history of the files, but of the project itself! There > is no guarantee that what worked in the past works with the history > re-written, what was tested then won't be tested now, people that had > patches against previous releases won't apply at all. > > Even if lld had no connections whatsoever to anything else in the > external world, I'd still be against it. > > > > Note that variable names are outside the scope of this. > > Unfortunately, that's one of the biggest changes proposed... > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141007/ee7b56d0/attachment.html>