Re: Run pgindent now?
От | Robert Haas |
---|---|
Тема | Re: Run pgindent now? |
Дата | |
Msg-id | CA+TgmobZvxDjCqRDJVrFxGwVSuC6abnMy6F2rthBgRidYLQnTg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Run pgindent now? (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Run pgindent now?
|
Список | pgsql-hackers |
On Tue, May 26, 2015 at 2:55 PM, Robert Haas <robertmhaas@gmail.com> wrote: > This is kind of why I think that reindenting the back branches is > unlikely to be productive: it only helps if you can get pgindent to do > the same thing on all branches, and I bet that's going to be tough. ...but having said that and thought about this a bit more, we could actually test that rather than guessing. Suppose somebody goes and writes a script which diffs the version of each file on master with the version of the same file, if it exists, on each stable branch. And then they indent each back-branch on a private branch and do the same thing again. And then they produce a report of every file where the number of lines that differ went up rather than down. Then, we could look at the files where things got worse and try to fix whatever the issue is. Of course, it would be nice to be even more fine-grained and try to figure out whether there are files where, although the file overall ended up with fewer differences, some individual places in the file diverged. Maybe somebody with sufficient git-fu could figure out how to do that. But even without that, it seems to me that with some work, we could probably measure how good an outcome we're actually going to get here. What I really don't want to do is apply the pgindent diff somewhat blindly, without really knowing how many cases we're improving and how many cases we're making worse. The number of times we've run pgindent and then realized later that it messed a bunch of stuff up is actually pretty high, and I find doing that to the back-branches particularly unexciting. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: