Consider force pushing to wiki

[jcbhmr]

Right now the flow looks like this

1. init new repo in subfolder
2. add remote .wiki.git
3. fetch all
4. add all
5. commit all
6. push

i propose instead something like this

1. init new repo in subfolder
2. add all
3. commit all
4. force push to .wiki.git

this would inadvertently fix the issue of no-change meaning a failure (since commit would fail). it would also treat the wiki more as a "deploy dest" similar to github pages instead of a "history preserving scrapbook of wiki docs". and it just seems like a more semantically correct and idiomatic way to do it since we are treating github wiki as a deploy dest.

Anyway, do you want to add that step to write the rev? This should help when a PR is merged, which will cause a run in main that contains no changes from the run made by the PR.

[spenserblack]

Going back to the idea of having a "strategy" input, I think this is a great candidate for an optional strategy. It's definitely something that I would consider using.

However, a few things:

• Destroying git history (force-push, rebase, etc.) can be very scary to beginners. Some users may feel uncomfortable if this is the default. Plenty of stackoverflow answers are very insistent that force-pushes are evil and should never be done.
• If, for whatever reason, the user decides they want to revert some changes in the wiki, force-push could make that difficult to impossible.

[jcbhmr]

• Destroying git history (force-push, rebase, etc.) can be very scary to beginners. Some users may feel uncomfortable if this is the default. Plenty of stackoverflow answers are very insistent that force-pushes are evil and should never be done.

they never need to know 😉

If, for whatever reason, the user decides they want to revert some changes in the wiki, force-push could make that difficult to impossible.

just like github pages, wouldn't they do that in the main source tree not the wiki git repo itself? isn't that literally the whole point of this bullet: "⤴️ Lets you open PRs for wiki docs" lmao 😜

[jcbhmr]

a note about the "force push is bad" thing: gh-pages branch actions are almost always force push actions

ex: https://github.com/peaceiris/actions-gh-pages/blob/0d67ec5c39cdb4146b7385e40f506ecce78b53de/src/git-utils.ts#L220

[spenserblack]

Note that the default option is to not force-push 🙂

Like I said, I'd personally use this action with a force-push (probably), but I think it's reasonable for default behavior to not destroy history.

they never need to know 😉

If they ever look, they might be surprised 😆

I think not force-pushing is the least surprising behavior, and also is less likely to cause an issue with any unpredictable edge-cases regarding usage of wiki commit history.

[jcbhmr]

so i think this warrants at least an option. in the future revisiting the default force:true vs force:false might be good.

next on the docket is a v1 rfc for what options and stuff should be a part of this action 😃

for now though the action that i think is agreed on from here:

Going back to the idea of having a "strategy" input, I think this is a great candidate for an optional strategy. It's definitely something that I would consider using

is to make an option to force push

[spenserblack]

Yeah, that sounds good to me 👍