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.

[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.

[Managor]

That's exactly the reason why we prefer an untidy commit history in a PR. It's easier to follow when everything is in chronological order.

[SethFalco]

I'd avoid stating subjective things like your merge vs. rebase preference like a fact.

I personally prefer rebases for example, and when people amend their commits instead of add new ones to fix issues introduced by the commits in their branch.

Or in other words, I prefer when people keep their feature-branches as clean as we'd like to keep main.

Especially as I believe squash-and-merge is a workaround for messy feature-branches, but not an excuse to have messy feature-branches.

Forges already provide a way to only review the changes between force-pushes, though in the case of a rebase with the base-branch it will show those changes from main too.

I've contributed to other projects that enforce no force-pushes too I know you aren't the only maintainer of tldr-pages who doesn't like them, though!

I'm just suggesting to to avoid saying "we"! You should say "I". (Or perhaps cite our guidelines if this is documented somewhere.)

There's nothing wrong with talking about the views of maintainers as a collective, but only on things we've collectively agreed on. But then you can refer to that agreement, especially as the PR was opened by a fellow maintainer, so they clearly would've missed the memo then.

Edit:

Turns out this is documented in the contribution guidelines! So most of what I've said is actually redundant, I apologize for that. But a link would be appreciated next time!

Do not force push. We would prefer to preserve commit history so that the order of events is preserved. All pull requests will be squashed so a messy pull request will not matter.

- https://github.com/tldr-pages/tldr/blob/main/CONTRIBUTING.md#accepting-suggestions-within-a-pull-request

[waldyrious]

Thanks for chiming in, @SethFalco. I appreciate that the guideline is documented, but I should point out that the PR that originated it (#18647) did not have any meaningful discussion, and while it was approved by several established maintainers with a good grasp of the project's history and ethos, it also lacked the input of some of the people who have had a significant hand in the gradual construction of the project's direction, vision and culture over the year, like yourself, @sbrl, @kbdharun (and, if you allow the immodesty, former maintainers like myself). The fact that you were unaware of it is pretty telling, IMHO.

In particular, I am troubled by the unqualified statement that "a messy pull request will not matter". I won't pursue a change to that wording for the time being, since I cannot afford to give such a discussion the care it requires, but I wanted to leave my stance on record in case that does get discussed in the future. Update: happy to see that a discussion has actually been started already, in #19387. Let's continue the discussion there! 😃

Off-topic aside: @Managor, just in case you had missed it, I should point out that I asked for a clarification about your request above. No rush, of course — just making sure it didn't slip your radar :)

[karthik-script]

LGTM