Is there any standard around PR merge strategy for CSH repos? e.g. squash + merge vs merge commits?

IME the former has become much more popular over the years, but the latter is still used in larger projects like Kubernetes.

We don't have a standard, mainly due to the nature of how PRs work in CSH (see another comment I left). I think we should probably write what we see though, which is squash + merge for smaller PRs and merge for larger PRs. We also tend to rebase from develop -> main (although this will soon be a force push with @BigSpaceships' bot).

force push is scary but i dont have any context there

If you used AI tools in preparing your PR, you must disclose this in the description of your PR.

Why is this important, and where is the line?

e.g. if I have copilot auto-complete a couple of lines or brackets, and nothing else, do I need to disclose that I used copilot?

IMO, the line should be if you had any Gen AI tools enabled, and it provided any content in a chat or wrote to the files, then it was a contribution.

that makes sense

co-signing commits using an AI tool, or using the assisted-by, co-developed or similar commit trailer is not allowed.

This feels like it would be irrelevant in a world where we always use squash + merge?

And also, why isnt this allowed? Its just metadata, yea?

If we use squash+merge, this is true. However, we do different commits depending on the nature of the commit. We don't perfectly follow the one-feature or one-fix per PR, there's often major features plus a bunch of little fixes in a PR. While that is not good practice for a company, given the nature of CSH being a bunch of nerds doing things for fun in their free time, waiting for fixes to be merged while trying to work on a feature is inefficient and can lead people to drop the project. For larger PRs like that, it's easier to merge without squashing so we can revert single commits if needed.

sure, thats fine, just might be worth being explicit that merge strategy is at the digression of the PR author (or whomever), since merge strategy has implications for commit quality on a given branch.

I think there should be a general preference for smaller, stacked PRs, independent of AI usage. But thats just my $0.02.

I agree and this should definitely be expanded upon. Part of this was written with the mindset of there being huge monolithic PRs with a ton of features and bug fixes all in one.

Definitely. Can evolve over time as well.

What about claude.md files?

IMO, LLM steering, guidance, and context files should be treated like IDE files and left out of the repository since they're tools specific to the developer, and should probably be explicitly stated to be removed.