On Wed, 2021-02-10 at 11:47:12 +0000, Phil Morrell wrote: > As a user of -satb, I'd like to point out that the flags are not all > equal. Two of them support a (more objective?) desire that "addition to > a list in line-based VCS should have no deletions". That is -at, whereas > -s is a subjective prettifier and -b could remove information, hence -k.
To me, all the flags in -ast are objectively superior to their counterparts. In the case of -s even more so, in addition to what has been mentioned of avoiding reindenting on field renames which does not necessarily mean the official field name gets changed (which is indeed very unusual), but the field being renamed in debian/control, say from Recommends to Suggests; it is also superior because: 1) it avoids VCS noise, by not putting the first value on the first line as the field itself, Depends: foo, bar, instead of: Depends: foo, bar, 2) it allows trivial copy&paste or syncs, between say build-dependencies and run-time dependencies. Say you have this: Source: foo Build-Depends: some-dep-dev, other-dep-dev, Package: foo-dev Depends: some-dep-dev, other-dep-dev, which means you have to copy, possibly remove the field, then reindent, which is rather annoying. I agree that -b is something else entirely, and in many cases I prefer ordering depending on relationship, layers or importance of the packages involved. > To make that work as a default, there would need to be something like an > --short-preferred-unless-existing-indent to prevent constant > reformatting. I disagree with jonas on the importance of -s because I'm > not convinced that field names change, especially not often. See above. But, I'd actually say it's perhaps as important or more than -t! :) Thanks, Guillem