<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 4 Jul 2015, at 17:06, Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu">schnetter@cct.lsu.edu</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Sat, Jul 4, 2015 at 10:30 AM, Ian Hinder <span dir="ltr"><<a href="mailto:ian.hinder@aei.mpg.de" target="_blank">ian.hinder@aei.mpg.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><div>On 3 Jul 2015, at 23:33, Erik Schnetter <<a href="mailto:schnetter@cct.lsu.edu" target="_blank">schnetter@cct.lsu.edu</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr">I've come to like to use a tool to automatically indent and format source code. This has several advantages -- the code has automatically a consistent style, indentation errors become obvious, and one doesn't have to spend time formatting the code manually while coding.<div><br></div><div>clang-format is the best such tool of which I'm aware. It's vastly better than e.g. GNU indent.</div><div><br></div><div>I propose to re-format Carpet's source code via clang-format.</div><div><br></div><div>Usually, changing the source code format is disruptive, since patches or local modifications won't apply cleanly any more. However, with clang-format, I don't think that this is an issue -- one can use clang-format on the modified code (e.g. a branch), which should eliminate gratuitous changes.</div></div></blockquote><blockquote type="cite"><div dir="ltr"><div><br></div><div>Please comment.</div></div></blockquote><div><br></div></span><div>Suppose that I have a local branch with a number of commits (I do). If I want to cherry-pick something from the new reformatted master, I could add a new commit to my branch which reformats everything, and cherry-picking would hopefully then be possible. To rebase my branch off of the reformatted master, I would probably have to rebase it off the commit in master before the reformat, then apply the reformatting myself, then rebase again of the new master. So apart from the amount of git-gymnastics needed to do this, it seems OK. More serious would be the utter impossibility of diffing formaline tarballs across the change and identifying the real differences.</div><div><br></div><div>I hope it doesn't need to be said, but any commits which introduce reformatting should be clearly labeled as such, and should not introduce any other changes, as these will be lost during a rebase in which formatting commits are skipped and formatting run again.</div><div><br></div><div>With the above considerations, is it worth doing this?</div></div></div></blockquote><div><br></div><div>Yes, it definitively is. Not having to worry about indentation and formatting while coding frees the mind; it is a transformative experience.</div></div></div></div></blockquote><div><br></div><div>I just press TAB in emacs to make sure the indentation is correct; it's not something I ever really think about. After reading Roland's email, I'm more and more concerned that a large-scale reformatting of an existing codebase with several branches owned by different people is going to cause a fair amount of pain. For a new project, I would definitely use such a system, and when new code is added to an existing project, but I'm not sure it's worth the trouble it will cause for Carpet.</div></div><br><div apple-content-edited="true">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>-- </div><div>Ian Hinder</div><div><a href="http://members.aei.mpg.de/ianhin">http://members.aei.mpg.de/ianhin</a></div></div></div></div></div>
</div>
<br></body></html>