rjk at terraraq.uk
Sun Sep 19 13:00:36 UTC 2021
On 19/09/2021 13:02, Perry E. Metzger wrote:
> Delurking for a moment...
> On 9/19/21 06:26, Richard Kettlewell wrote:
>> (My personal preference would be to completely ban the tab character
>> from source code, enforced with build time tests, since the meaning of
>> the tab character depends on local configuration and it is,
>> empirically, unrealistic to assume that everyone will share the same
> Git offers the ability to check constraints like this on check-in.
That's a good point, although I don't know if you can enable those on
GitHub in the same way as a local repo.
https://github.com/InterNetNews/inn/blob/main/ci/test would be the place
for it if not.
> I agree with the notion of banning tabs characters from from source
> code. This doesn't of course mean that one doesn't still use the tab key
> while typing in one's editor, just that one configures it to indent with
> spaces. See, for example:
> for a thorough discussion of the options in the choice space.
> If, however, such a thing is going to be done, it would mean a lot of
> whitespace changes to review. Luckily, many modern versions of diff
> (including that in git) can be configured to ignore whitespace changes
> when diffing, to make review of such modifications easier. That said,
> the bigger issue is that large changes like this often break development
> branches quite badly, though again, the ability to do
> whitespace-indifferent diffs can help somewhat.
Also good points.
In my view the way to make any change would be to use an agreed script
(or one-liner). That addresses both issues as follows:
1) Review can be done by the reviewer reviewing the script and then
running it independently to verify that it produces the same result,
rather than by attempting to review a giant diff.
2) Long-lived branches, or short-lived branches that happen to overlap
the change, can be repaired by running the script, effectively carrying
out the same change in the branch.
More information about the inn-workers