fix(repair): include EXDATE in missing VALUE=DATE repair step

[pmeier]

Fixes nextcloud/calendar#4783.

[codecov-commenter]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (efc91ef) 91.01% compared to head (141f64d) 91.01%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #592   +/-   ##
=======================================
  Coverage   91.01%   91.01%           
=======================================
  Files          57       57           
  Lines        2782     2782           
  Branches      507      507           
=======================================
  Hits         2532     2532           
  Misses        250      250           

Impacted Files	Coverage Δ
...calendar/icalendarAddMissingValueDateRepairStep.js	100.00% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[tcitworld]

Do you mind rewording your commit as a Conventional Commit?

Prefixing with the current title with fix(repair): will do it. Thank you very much!

[pmeier]

Prefixing with the current title

I fixed the title of the PR. Or do you mean each commit message?

As a side node, it would be really nice to have a small contribution guidelines in the README. The conventional commit and the commit sign-off things is stuff that I have never seen before.

[ChristophWurst]

Squash the two commits into one and change the commit message to the conventional commit format please

We mention the requirement in https://github.com/nextcloud/calendar-js#releases briefly but I agree that it should be noted more prominently.

[pmeier]

Squash the two commits into one and change the commit message to the conventional commit format please

Done.

Out of curiosity: if you require this, why not go with squash commits in the first place? Feels quite weird to force push the branch all the time. With a squash commit, the maintainer gets to dictate the commit message and thus circumvents this problem.

[ChristophWurst]

Out of curiosity: if you require this, why not go with squash commits in the first place? Feels quite weird to force push the branch all the time. With a squash commit, the maintainer gets to dictate the commit message and thus circumvents this problem.

Worth a consideration indeed.

The biggest issue I see with github's squash merge is that it saves it as default for all future PRs. I don't want that. I only want to squash merge occasionally. Background: I want to be able to reference a PRs commits later for tracking, e.g. in backports https://github.com/nextcloud/calendar-js#releases. Squashed commits get a new sha1.

[pmeier]

Fair enough.

I want to be able to reference a PRs commits later for tracking, e.g. in backports

A possibility could also be to just reference the PR rather than the commit. Of course this only works if you just use GH and not some other tool that requires commits. PR number is fixed during squash commits and available upfront.

[ChristophWurst]

We don't always backport the full PR: nextcloud/documentation#10380 (comment)