Fenced code blocks 835

[elkirby]

No description provided.

[jmichalicek]

Looks good to me. Let's give it a full test and get it merged if all seems to work as expected.

[joeygrover]

Hey @elkirby, you should avoid force pushing unless absolutely necessary. You seem to be force pushing the same commits so I don't know why you'd need to do that.

[elkirby]

Hey @elkirby, you should avoid force pushing unless absolutely necessary. You seem to be force pushing the same commits so I don't know why you'd need to do that.

Thank you for the guidance, @joeygrover. The reason I was doing so prior was because it was a feature branch and I was using interactive rebases to keep the commit history clean, and since the commit SHAs change afterwards, a force push is necessary in order to do so. I would never force push to a main or otherwise shared branch. This documentation from Gitlab explains why force pushes are necessary when squashing or fixing up commit histories.

That being said, I am more than happy to adhere to your team's suggested git flow strategy. I only explain myself with the intention of reassuring the Livio team that I would not be intentionally reckless or otherwise cavalier with my git practices, and would not perform any commands that I did not fully understand.

[joeygrover]

Ah yea wasn't looking at the hashes, just the messages. So we avoid using rebase, we always add commits or merge for a number of reasons. During a code review if you need to make changes via an additional commit from that review it is difficult to find exactly what changed if every time you push it is a force push and especially if it is rebased. Commit history "clean up" can be done via squash merge from the PR if it is out of control, but most of the time it is fine. IMO true commit history is better than visually clean. So, if possible, for Livio owned repos we would prefer that you add commits and use merge instead of rebase, and therefore avoid the necessary force push scenario you are referencing.