csplit: clarify how the regex option works

[waldyrious]

Checklist

• The page(s) are in the correct platform directories: common, linux, osx, windows, sunos, android, etc.
• The page description(s) have links to documentation or a homepage.
• The page(s) follow the content guidelines.
• The page(s) follow the style guide.
• The PR contains at most 5 new pages.
• The PR is authored by me, or has been human-reviewed if it was created with AI or machine translation software.
• The PR title conforms to the recommended templates.
• Version of the command being documented (if known):

Reference issue: #

[sbrl]

looks good to me! wording improvement is good, yesyes 🌟

[Managor]

Please don't force push

[waldyrious]

Please don't force push

Are we not supposed to rebase the branch when it gets outdated? What if there are conflicts?

[Managor]

The github UI will warn in the case of conflicts. They are a non-issue.
We would like to preserve commit history so that it's clear what changes were made after what comments

[waldyrious]

Right, that's a good point. It's a pity that we still have to rely on untidy commit histories to avoid breaking the code review experience, which should be the responsibility of the forge, i.e. GitHub. Hopefully novel approaches like GitButler's patch-based code review system and stable change IDs (like those used by jj) will catch on, so that we can have our cake and eat it too (i.e. have clean commit histories but also be able to follow the evolution of a patchset during review).

For the time being, I'll refrain from force-pushing except to resolve conflicts.

[Managor]

Every PR gets squshed before merge. An untidy commit history is a non-issue.

[Managor]

This is still sort of ambiguous. Are you starting it before or after line 10.

[waldyrious]

I'm not sure how I can make this clearer. If the second file starts at line 10, doesn't that necessarily mean that the split is before it, i.e. between lines 9 and 10?

Can you walk me through your thought process for an interpretation that would place the split after line 10, i.e. where line 10 would be part of the first split file? 🤔

[waldyrious]

Every PR gets squshed before merge. An untidy commit history is a non-issue.

In minor changes like this, I certainly agree. But I wouldn't hold that as a general rule, since more complex changes definitely benefit from modular commits, even if they result in a squashed commit in the main branch — people would then be able, at any point in the future, to follow the link in the commit to the PR and use the clean commit history to better understand the changes.

Anyway, sorry for spawning an off-topic discussion here. As I mentioned above, I'll make sure to avoid unnecessary force-pushes in the future.