Don’t Push Final and WIP Commits to the Same Forge

(learn about this date format)

When I was young, I would often not save files until I was completely done with them. When I took a break from what I was working on, I would just leave Notepad, Code::Blocks or whatever I was using open on my computer. Instead of shutting down my computer, I would put it into sleep mode at night in order to avoid closing applications that had unsaved work. This strategy almost certainly caused me to loose work. I can’t remember a specific time when I lost work, but I’m almost sure that it happened.

My dad would always remind me to “save early, save often”, and eventually, I got into to the habit of saving early and saving often. Saving early and saving often is great, but it does have a problem. There’s a chance that you’ll overwrite a good revision with a bad revision. In order to overcome that problem, I’ve developed a new strategy: commit early, commit often. I’ll put “[WIP]” in the subject line of any work-in-progress commits, and I’ll include a to-do list at the bottom of the commit message. I’ll use git commit --amend and git rebase in order to remove items from the to-do list as they get completed. Once there are no more items on the to-do list, I remove the “[WIP]” from the commit’s subject line.

Committing early and committing often is great, but it does have a problem. It’s not resilient to hardware failures. If your hard drive dies and you don’t have a recent enough backup, then you’ve lost work. If you’re using a desktop and you lose power, then you won’t be able to continue working until you have power again. In order to overcome that problem, I’ve developed a new strategy: push early, push often. I’ll make a topic branch and put a bunch of [WIP] commits in it. After I finish amending or rebasing a commit, I’ll run git push --force. Once all of the WIP commits are done, I’ll either merge the branch or turn it into a pull request. Pushing early and pushing often ensures that I have an off-site backup of anything that I’m working on.

Pushing early and pushing often is great, but it does have a problem. It creates a lot of unnecessary noise. For example, consider this pull request that I’ve been working on. Here’s what part of that PR’s conversation tab looks like:

  1. Jayman2000 commented

    From a user standpoint, I find this version harder to follow. In the current README version, a developer looking for build instructions has to 1) Find the build header 2) Find their OS 3) Copy and run the commands.

    In your version: 1) Find the "building" header 2) Expand the subheader corresponding to the prerequisites of their OS 3) Read the next step, and skip it because it is not for their OS 4) Copy commands one by one, skipping the ones not for them.

    I don't know if my explanation is clear but I feel like it's adding friction to the simple "copy 3 commands and done".

    OK. I’ll submit a new version that splits everything back into separate headings after we wrap up the Visual Studio discussion.

  2. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  3. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  4. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  5. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  6. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  7. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  8. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  9. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  10. Jayman2000 force-pushed the revamp-build-instructions branch from 366ffab to 7ec9210

  11. Jayman2000 commented

    OK. I’ll submit a new version that splits everything back into separate headings after we wrap up the Visual Studio discussion.

    I just force pushed a new version that splits everything back into separate headings.

  12. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  13. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  14. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  15. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  16. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  17. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  18. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  19. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  20. Jayman2000 added a commit to Jayman2000/Descent3-pr that referenced this pull request
  21. Jayman2000 force-pushed the revamp-build-instructions branch from 7ec9210 to 7b4d80a

  22. Lgt2x commented

    tag me when you're ready for review :)

The commit message for one of the commits that I was amending contained a link to a comment in that pull request thread. As a result, every time I force pushed that commit, a new item would be added to that PR’s timeline. Items were added to the timeline even when I wasn’t pushing to that PR’s branch (I was pushing to a separate provisional PR branch until after all of the WIP commits were finished). GitHub will also do this if you link to an issue, so these messages have appeared in issues that I’ve never commented on.

I’ve know about this problem for a while, but I didn’t have a solution for it until now. My solution is to push WIP and final commits to different software forges. For example, if I’m working on a GitHub pull request, then I’ll push WIP commits to Codeberg and push final commits to GitHub. If I’m working on a Codeberg pull request, then I’ll push WIP commits to Pagure and push final commits to Codeberg. Hopefully, this will prevent me from unintentionally spamming issues and pull requests. As an added bonus, it also makes the projects that I work on more decentralized and makes my backups more redundant.