Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13 Sep 2023, at 16:25, Volker Hilsheimer via Development wrote: On 13 Sep 2023, at 13:23, Ahmad Samir wrote: On 13/9/23 11:06, Ivan Solovev via Development wrote: I would therefore propose to remove the file from qt5.git: +1 from my side. I believe I simply do not have the clang-format tool installed on my system, because it usually breaks the formatting of the patches, not improves them. One way to address these problems, especially for new devs or drive-by contributions, is stating clearly in the wiki page: "use clang-format, it should get you at least half way there, but you still should/must also override it to match the style of surrounding code, as much as possible, in the file(s) you're editing, that's kinder to reviewers". The problem is that we have a pre-commit (I believe) git-hook, which checks the formatting and nags if it does not match to what we have in the _clang-format file. This basically forces the new or drive-by contributors to submit the patch with an incorrect formatting, which then leads to a bunch of review comments about code-style. I think that it's better to give no hints, rather than misleading hints. [...] I think the best way to find out is indeed removing the file, then one of two things will happen: - we'll get less formatting issues in reviews (especially from new contributors) - or we'll still get formatting issues, just different ones than what clang-format currently does So 6-12 months, and we'll have a definite answer. :) Regards, Ahmad Samir I find the input from clang-format’s sometimes helpful, sometimes annoying. And the source of the annoyance is not that clang-format points out things that I could have formatted differently, but that our pre-commit hook returns with a non-zero exit code if clang-format produces a diff, thus blocking the commit. Based on that, I’d propose to change the pre-commit hook: https://codereview.qt-project.org/c/qt/qtrepotools/+/503746 and leave the _clang_format file in place as a tool, not as a straight-jacket. Volker I’ve now submitted the change, thanks for the reviews. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13 Sep 2023, at 16:25, Volker Hilsheimer via Development wrote: I find the input from clang-format’s sometimes helpful, sometimes annoying. And the source of the annoyance is not that clang-format points out things that I could have formatted differently, but that our pre-commit hook returns with a non-zero exit code if clang-format produces a diff, thus blocking the commit. +1 - the only objection to clang-format I find hard to rebut is this behavior, in particular in cases where said style violation is in pre-existing code that isn't part of the change in question. FWIW each single module (and sub-directory of modules) can sport their own clang-format config. The top-level one (i.e. qt5.git/_clang-format) then works as a fall-back for those that don't have one, in a qt5.git checkout. So if a proliferation of clang-format files occur, I'd still vote in favor of keeping the one in qt5.git either way, such that contributors in modules that don't want to keep track of possible style changes locally can still shift some whitespace around programmatically if they so please. Volker //! Paul -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13 Sep 2023, at 13:23, Ahmad Samir wrote: On 13/9/23 11:06, Ivan Solovev via Development wrote: I would therefore propose to remove the file from qt5.git: +1 from my side. I believe I simply do not have the clang-format tool installed on my system, because it usually breaks the formatting of the patches, not improves them. One way to address these problems, especially for new devs or drive-by contributions, is stating clearly in the wiki page: "use clang-format, it should get you at least half way there, but you still should/must also override it to match the style of surrounding code, as much as possible, in the file(s) you're editing, that's kinder to reviewers". The problem is that we have a pre-commit (I believe) git-hook, which checks the formatting and nags if it does not match to what we have in the _clang-format file. This basically forces the new or drive-by contributors to submit the patch with an incorrect formatting, which then leads to a bunch of review comments about code-style. I think that it's better to give no hints, rather than misleading hints. [...] I think the best way to find out is indeed removing the file, then one of two things will happen: - we'll get less formatting issues in reviews (especially from new contributors) - or we'll still get formatting issues, just different ones than what clang-format currently does So 6-12 months, and we'll have a definite answer. :) Regards, Ahmad Samir I find the input from clang-format’s sometimes helpful, sometimes annoying. And the source of the annoyance is not that clang-format points out things that I could have formatted differently, but that our pre-commit hook returns with a non-zero exit code if clang-format produces a diff, thus blocking the commit. Based on that, I’d propose to change the pre-commit hook: https://codereview.qt-project.org/c/qt/qtrepotools/+/503746 and leave the _clang_format file in place as a tool, not as a straight-jacket. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 11:06, Ivan Solovev via Development wrote: I would therefore propose to remove the file from qt5.git: +1 from my side. I believe I simply do not have the clang-format tool installed on my system, because it usually breaks the formatting of the patches, not improves them. One way to address these problems, especially for new devs or drive-by contributions, is stating clearly in the wiki page: "use clang-format, it should get you at least half way there, but you still should/must also override it to match the style of surrounding code, as much as possible, in the file(s) you're editing, that's kinder to reviewers". The problem is that we have a pre-commit (I believe) git-hook, which checks the formatting and nags if it does not match to what we have in the _clang-format file. This basically forces the new or drive-by contributors to submit the patch with an incorrect formatting, which then leads to a bunch of review comments about code-style. I think that it's better to give no hints, rather than misleading hints. [...] I think the best way to find out is indeed removing the file, then one of two things will happen: - we'll get less formatting issues in reviews (especially from new contributors) - or we'll still get formatting issues, just different ones than what clang-format currently does So 6-12 months, and we'll have a definite answer. :) Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 09:13, Paul Wicking wrote: On 12 Sep 2023, at 22:33, Ahmad Samir wrote: _clang-format isn't picked up by clang-format by default, you'd have to rename it to .clang-format. clang-format reads either of them [0]. It's unnecessary to rename the configuration file. [0] - https://clang.llvm.org/docs/ClangFormat.html#standalone-tool I didn't know that, thanks for the clarification (from other projects, it's always .clang-format, never prefixed with _). //! Paul Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
> I would therefore propose to remove the file from qt5.git: +1 from my side. I believe I simply do not have the clang-format tool installed on my system, because it usually breaks the formatting of the patches, not improves them. > One way to address these problems, especially for new devs or drive-by > contributions, is stating clearly in the wiki page: > "use clang-format, it should get you at least half way there, but you still > should/must also override it to match the style of surrounding code, as much > as > possible, in the file(s) you're editing, that's kinder to reviewers". The problem is that we have a pre-commit (I believe) git-hook, which checks the formatting and nags if it does not match to what we have in the _clang-format file. This basically forces the new or drive-by contributors to submit the patch with an incorrect formatting, which then leads to a bunch of review comments about code-style. I think that it's better to give no hints, rather than misleading hints. Best regards, Ivan -- Ivan Solovev Senior Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 12489 Berlin, Germany ivan.solo...@qt.io www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From: Development on behalf of Ulf Hermann via Development Sent: Wednesday, September 13, 2023 8:54 AM To: development@qt-project.org Subject: Re: [Development] Proposal: (re)move qt5.git/_clang-format > There _is_ consensus. It's in the wiki. And in older modules not > infected by the _clang-format file. Discussions arise because > of .clang-format, not despite it. Afaict, there never was a discussion > about how faithful the _clang-format represents the Qt style before it > was added. If there was _any_ attempt at the above-mentioned litmus > test, the template<> issue and others would have been detected immediately. Unfortunately the consensus is weak on the most jarring problem, and that happens to be one that the automatic formatters I know are utter rubbish at: Where do you break the line and how much white space do you indent in various situations? For example: * long lists of arguments list to a function (call or declaration) * nested template parameters, possibly with defaults * template arguments * lists of partially specialized template parameters * initializer lists (possibly nested) * ternary operators with outsized "hands" * constructor-initializers * lambdas, potentially nested * nested boolean or arithmetic expressions with or without parentheses * and then combine all of those I find myself constantly re-indenting things based on some unwritten rules I make up myself. I would be fine with an automatic indentation that produces somewhat readable code, but what I get is frequently an indentation to column 205 or similar for no obvious reason. Yes, it often helps to use additional temporaries so that your lines are not as large to begin with. However, that also increases the cognitive load when reading it as you then have to carefully determine if the introduction of the temporary changes semantics. For example, is the temporary moved or copied? Does the extracted template construction allow things the inline one was not meant to allow? etc. All the other stuff you may format for is trivial in comparison because it only involves adding or removing few characters here or there. With some practice it takes up rather little time, even when done manually. The indentation, however, requires shifting around large bodies of white space, which is quite annoying in the editors I know. best regards, Ulf -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
There _is_ consensus. It's in the wiki. And in older modules not infected by the _clang-format file. Discussions arise because of .clang-format, not despite it. Afaict, there never was a discussion about how faithful the _clang-format represents the Qt style before it was added. If there was _any_ attempt at the above-mentioned litmus test, the template<> issue and others would have been detected immediately. Unfortunately the consensus is weak on the most jarring problem, and that happens to be one that the automatic formatters I know are utter rubbish at: Where do you break the line and how much white space do you indent in various situations? For example: * long lists of arguments list to a function (call or declaration) * nested template parameters, possibly with defaults * template arguments * lists of partially specialized template parameters * initializer lists (possibly nested) * ternary operators with outsized "hands" * constructor-initializers * lambdas, potentially nested * nested boolean or arithmetic expressions with or without parentheses * and then combine all of those I find myself constantly re-indenting things based on some unwritten rules I make up myself. I would be fine with an automatic indentation that produces somewhat readable code, but what I get is frequently an indentation to column 205 or similar for no obvious reason. Yes, it often helps to use additional temporaries so that your lines are not as large to begin with. However, that also increases the cognitive load when reading it as you then have to carefully determine if the introduction of the temporary changes semantics. For example, is the temporary moved or copied? Does the extracted template construction allow things the inline one was not meant to allow? etc. All the other stuff you may format for is trivial in comparison because it only involves adding or removing few characters here or there. With some practice it takes up rather little time, even when done manually. The indentation, however, requires shifting around large bodies of white space, which is quite annoying in the editors I know. best regards, Ulf -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 12 Sep 2023, at 22:33, Ahmad Samir wrote: _clang-format isn't picked up by clang-format by default, you'd have to rename it to .clang-format. clang-format reads either of them [0]. It's unnecessary to rename the configuration file. [0] - https://clang.llvm.org/docs/ClangFormat.html#standalone-tool //! Paul -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 01:46, Marc Mutz via Development wrote: [I didn't get André's Email...] On 12.09.23 23:40, Ahmad Samir wrote: On 13/9/23 00:11, apoenitz wrote: On Tue, Sep 12, 2023 at 11:33:17PM +0300, Ahmad Samir wrote: A config file that is 80-90% correct is better than nothing. I disagree. The result of such a thing is that people submit patches matching the config 100%, deviating from the wanted style by 10-20%. Numbers are arbitrary here, but the effect is that in practice even long-term contributors start to submit "wrong" auto-formatted patches causing needless review roundtrips. The alternative is patches with arbitrary formatting; that's not better. Sorry, no. If you submit a patch, you should just use whatever style you find in the file. If there's a mix, use whatever is adjacent to where you're coding. It's that simple. That shouldn't be too much to ask, and I, for one, am fine going into the Gerrit editor and fixing things for the submitter if that's the only thing holding me back from a +2. It's when people insist on rewriting lines because that's how QtCreator or git-clang-format format it, that the discussions start. > And a clang-format file doesn't actually help here, because we have already introduced inconsistencies in qtbase and whatever we select in .clang-format will be wrong 50% of the time. Assuming, of course, that you can get it configured to be close enough to the prevailing style, which I have not seen proof of. If anyone thinks it's possible, there's a simple litmus test: apply your config to all of qt(base) and look at the diff: Is it just fixing some outliers, or is it rewriting the world? Without testing, I am sure it's the latter. :) On top of that repeatedly discussion are started about adjusting the style to the tool, because "the tool can't be adjusted". True, but style arguments arise on their own too, tool or no tool. It only arises because the tool cannot represent what we traditionally call the Qt style. If there are disagreements on what that means, it's easy to draw upon a majority vote of Qt 4 code to break the tie, disregarding clang-format-infected files. I should also point out that the discussions a few years ago were nitpicking about Qt coding style violations, and the expected response from the submitter was to fix them. These days, everything is called into question because clang-format does it differently, ie. wrongly. And I'm kinda getting tired commenting on all these clang-format idiosyncrasies. If the tool was truly configurable, e.g. with an example [...] (Are most of those idiosyncrasies about 'template <>' in qtbase reviews? if so, then that's because qtbase doesn't have its own .clang-format with that style, because that's actually something the tool can do). I _know_ there is no perfect solution, I've spent some time trying to tweak the clang-format config in Qt and other projects/repos, there is no way to get a dumb formatting tool to do exactly what you want in all cases, partly because it can't read minds, and partly because it can't know things like "breaking this line of code here is really stoopid". One way to address these problems, especially for new devs or drive-by contributions, is stating clearly in the wiki page: "use clang-format, it should get you at least half way there, but you still should/must also override it to match the style of surrounding code, as much as possible, in the file(s) you're editing, that's kinder to reviewers". Technically, that's what I personally do, it's the same as having bash scripts, even if I can get it to do 50% of what I want, just not having to repeat myself to run some chain of commands 10 times a day is good enough. file from which it would pick formatting, we wouldn't have this discussion, either. But what I read between the lines is that Google is happy that it can reproduce their style, and contributions to extend it are not welcome. One way to stop the recurring discussions would be to reach a majority consensus about a clang-format config file, format the whole code base of each module in one go, then apply the formatting for each new commit, less discussions. Is that ideal? no, because reaching a consensus about coding style is not easy. There _is_ consensus. It's in the wiki. And in older modules not infected by the _clang-format file. Discussions arise because of .clang-format, not despite it. Afaict, there never was a discussion about how faithful the _clang-format represents the Qt style before it was added. If there was _any_ attempt at the above-mentioned litmus test, the template<> issue and others would have been detected immediately. I could format it manually, probably two steps, or let the tool do it That assumes the tool can be configured to reproduce the style. Until proven, you have to do the work 50% of the time, anyway. Tool won't help. It can/is configured to reproduce the style, but only as much as a tool can; it still
Re: [Development] Proposal: (re)move qt5.git/_clang-format
[I didn't get André's Email...] On 12.09.23 23:40, Ahmad Samir wrote: > On 13/9/23 00:11, apoenitz wrote: >> On Tue, Sep 12, 2023 at 11:33:17PM +0300, Ahmad Samir wrote: >>> A config file that is 80-90% correct is better than nothing. >> >> I disagree. >> >> The result of such a thing is that people submit patches matching the >> config >> 100%, deviating from the wanted style by 10-20%. Numbers are arbitrary >> here, but the effect is that in practice even long-term contributors >> start >> to submit "wrong" auto-formatted patches causing needless review >> roundtrips. >> > > The alternative is patches with arbitrary formatting; that's not better. Sorry, no. If you submit a patch, you should just use whatever style you find in the file. If there's a mix, use whatever is adjacent to where you're coding. It's that simple. That shouldn't be too much to ask, and I, for one, am fine going into the Gerrit editor and fixing things for the submitter if that's the only thing holding me back from a +2. It's when people insist on rewriting lines because that's how QtCreator or git-clang-format format it, that the discussions start. And a clang-format file doesn't actually help here, because we have already introduced inconsistencies in qtbase and whatever we select in .clang-format will be wrong 50% of the time. Assuming, of course, that you can get it configured to be close enough to the prevailing style, which I have not seen proof of. If anyone thinks it's possible, there's a simple litmus test: apply your config to all of qt(base) and look at the diff: Is it just fixing some outliers, or is it rewriting the world? >> On top of that repeatedly discussion are started about adjusting the >> style to >> the tool, because "the tool can't be adjusted". > > True, but style arguments arise on their own too, tool or no tool. It only arises because the tool cannot represent what we traditionally call the Qt style. If there are disagreements on what that means, it's easy to draw upon a majority vote of Qt 4 code to break the tie, disregarding clang-format-infected files. I should also point out that the discussions a few years ago were nitpicking about Qt coding style violations, and the expected response from the submitter was to fix them. These days, everything is called into question because clang-format does it differently, ie. wrongly. And I'm kinda getting tired commenting on all these clang-format idiosyncrasies. If the tool was truly configurable, e.g. with an example file from which it would pick formatting, we wouldn't have this discussion, either. But what I read between the lines is that Google is happy that it can reproduce their style, and contributions to extend it are not welcome. > One way to stop the recurring discussions would be to reach a majority > consensus about a clang-format config file, format the whole code base > of each module in one go, then apply the formatting for each new commit, > less discussions. Is that ideal? no, because reaching a consensus about > coding style is not easy. There _is_ consensus. It's in the wiki. And in older modules not infected by the _clang-format file. Discussions arise because of .clang-format, not despite it. Afaict, there never was a discussion about how faithful the _clang-format represents the Qt style before it was added. If there was _any_ attempt at the above-mentioned litmus test, the template<> issue and others would have been detected immediately. > I could format it manually, probably two steps, or let the tool do it That assumes the tool can be configured to reproduce the style. Until proven, you have to do the work 50% of the time, anyway. Tool won't help. Believe me, I wouldn't like anything better than a clang-format config that shuts these discussions up. But not at the cost of rewriting 50% of our code, a large percentage of which still dates back unchanged to the beginning of the public history. Thanks, Marc -- Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 00:11, apoenitz wrote:
On Tue, Sep 12, 2023 at 11:33:17PM +0300, Ahmad Samir wrote:
A config file that is 80-90% correct is better than nothing.
I disagree.
The result of such a thing is that people submit patches matching the config
100%, deviating from the wanted style by 10-20%. Numbers are arbitrary
here, but the effect is that in practice even long-term contributors start
to submit "wrong" auto-formatted patches causing needless review roundtrips.
The alternative is patches with arbitrary formatting; that's not better.
On top of that repeatedly discussion are started about adjusting the style to
the tool, because "the tool can't be adjusted".
True, but style arguments arise on their own too, tool or no tool.
One way to stop the recurring discussions would be to reach a majority consensus
about a clang-format config file, format the whole code base of each module in one
go, then apply the formatting for each new commit, less discussions. Is that
ideal? no, because reaching a consensus about coding style is not easy.
For example I have copied that file to qtbase/.clang-format and changed that
`template <>` part, it's still useful for me to have the file there as I
could select some text and format only that part in e.g. KDE's Kate. I can
override the changes to conform to qtbase's coding style, but I don't have to
do it all manually.
It's not /that/ hard to follow the /one/ code style that's uses in one's main
project. I have some sympathy for cases where people submit occasional patches
in a side project with some odd style rules, but for the day-time project
typing code in its preferred style should become second nature - independent
of any possible quirks and oddities there.
Examples:
- typos (no space):
if (foo && bar){
//
}
- lengthy lines of code:
static QMetaObject::Connection connect(const QObject *sender,
PointerToMemberFunction signal, const QObject *receiver, PointerToMemberFunction
method, Qt::ConnectionType type = Qt::AutoConnection);
I could format it manually, probably two steps, or let the tool do it
- debating about where to break the line:
bool inSenderThread = currentThreadId ==
QObjectPrivate::get(sender)->threadData.loadRelaxed()->threadId.loadRelaxed();
after the assign =, or after == or ...etc; or just let a tool do it, I can
disagree and override it if it looks too bad.
Andre'
D
PS:
Drive-by suggestion: each module should also have a .git-blame-ignore-revs
file (name should be unified in all Qt repos), to put commit hashes that
git-blame should ignore. (See 'git blame --ignore-revs-file').
Why?
Useful when using git-blame, e.g.:
- the commit that moved inline keyword to fix MinGW warnings in qstring.h, seeing
any line from that commit in git blame isn't useful/informative
- Formatting a repo with clang-format, that commit isn't useful in git blame
context
Regards,
Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 12/9/23 20:29, Marc Mutz via Development wrote: Hi, TL;DR: - remove _clang-format in qt5.git - add it instead to submodules which conform to it The clang-format philosophy is that you pick a config and stick to it. If your personal preferences are different, you use a different configuration locally and re-format on check-in and check-out. This means that the source code in the VCS must always conform to the clang-format configuration in effect in that branch. It also means that when and if you make changes to the clang-format configuration, you need to re-run the tool over the whole code base and apply the changed configuration, otherwise the clang-format workflow doesn't work (produces unrelated white-space changes). We have for quite some time had a _clang-format config file in qt5.git. After many attempts by many people, it has become clear that a) it has completely wrong settings (e.g. template<> vs. template <>), This particular issue with template<> has been "fixed" recently thanks to Mårten https://codereview.qt-project.org/c/qt/qt5/+/433720. leading to a complete formatting mess in modules that predate the addition of the file and more discussions around formatting than before, because there appear to be two true styles, and b) we can't seem to hammer clang-format into reproducing what we traditionally understand as the Qt style. In addition, the position in qt5.git means that if you edit files in submodules of qt5.git, the config is in effect, if you just checkout qtbase, it is not. _clang-format isn't picked up by clang-format by default, you'd have to rename it to .clang-format. I would therefore propose to remove the file from qt5.git: https://codereview.qt-project.org/c/qt/qt5/+/503430 I propose leaving that _clang-format file as the default clang-format config file, but each repo should have a .clang-format committed in git where the module maintainers/powers-to-be can put the code style that they want in their module. Some repos in Qt already do that. One of them has the max line length set to way more than 100, with a comment (paraphrased): "most lines in this repo are long, we have to live with with, move on" which is perfectly fine, the tool will pick up the config file and act accordingly. You can even have a .clang-format per dir in each module. So, remove it if you want, but a precursor to that is copying it to each Qt module, new _and_ old. It's OK for each module to change its own copy to fit its own style, but there should be a .clang-format, because it's much easier to let it format a diff, e.g. `git clang-format`, and override the few places that the tool got "wrong". This is more important for new devs who aren't familiar with the current coding style (yes, there is a good wiki page about the Qt coding style, but no it's not enough, there so much code and too many quirks to cover in one wiki page). Modules that don't have a .clang-format in git are implying "use the default config file". With a .clang-format committed to git, you get it any which way you checkout a Qt repo, `init-reporistory` or `git clone`. A config file that is 80-90% correct is better than nothing. For example I have copied that file to qtbase/.clang-format and changed that `template <>` part, it's still useful for me to have the file there as I could select some text and format only that part in e.g. KDE's Kate. I can override the changes to conform to qtbase's coding style, but I don't have to do it all manually. Drive-by suggestion: each module should also have a .git-blame-ignore-revs file (name should be unified in all Qt repos), to put commit hashes that git-blame should ignore. (See 'git blame --ignore-revs-file'). Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
Marc Mutz (12 September 2023 19:29) wrote: > TL;DR: > - remove _clang-format in qt5.git > - add it instead to submodules which conform to it [snip] > WDYT? Well - given that (after init-repository has set up the symlinks "for" me), my first reaction to any message from clang-format is usually to rename the symlink to .git/hooks/clang-uglify-pre-commit (because its suggestions are usually bad and it's very stubborn) - I'm all for it. I'd love to see a working autoformat as part of the tool-chain, but a broken one is worse than none. Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
