You can have the best of both worlds -- "commit early, commit often", and "nice clean commit histories" -- with git, and it is easier than most people think.
- So you start work on a new branch, and reach a checkpoint. Create a new commit with "git commit".
- Continue working, and when you reach the next checkpoint, create another commit. But this time, use "git commit --amend". Contrary to what the flag says, this doesn't modify the previous commit, instead it modifies your commit history and replaces the last commit with a new one[1]. So instead of having two new commits in your branch's history, you only have one.
- Repeat the process until you have something worth pushing to the remote.
- Once you've pushed to remote, remember to not make any further modifications to your git history[2] i.e. going forward, create a new commit and only then run "git commit --amend".
Now, there's an obvious question here: if "git commit --amend" keeps replacing the last commit with a new one, what happens when you mess things up and want to revert to NOT the last checkpoint, but some checkpoint before that?
The trick here that git has up its sleeve is called "git reflog". You see, while "git commit --amend" replaces the last commit in your branch's history with a new one, the older commit is not actually gone, its still there. And you can see all of them with "git reflog". Basically "git reflog" returns every commit at which the local HEAD (i.e. the commit checked out in your working directory) has been. So none of the commits that you replaced with --amend are actually lost, and you can find them all in the reflog.
Restoring to an older checkpoint becomes as easy as running "git reset --hard <previous-commit-id>", or if you want to play safe, "git checkout -b <new-branch-name> <previous-commit-id>".
Hope this helps!
Notes:
1. By design, a commit, or in fact most objects in git cannot be modified. They are immutable.
2. Basically you can play with git history as long as it is private to you and not shared with others. But the moment you push it to a remote you share with others it's no longer private and you must not modify that history anymore. Read Linus's note on keeping a clean git history: https://www.mail-archive.com/[email protected]...
I like --amend a lot too. Usually a new feature requires a few steps. I commit every step and make a list in git commit body. It's basically almost same as rebasing at the end, but amending seems more logical to me.
> This would benefit from a "select all/none" option for the regions.
Yeah, that would help. I'll add this.
> Also, adding spot pricing would be SUPER helpful!
Unfortunately spot pricing is not available in the bulk pricing API, which is what I am using here. But there does seem to be a separate API to get the spot pricing history - I will try to use it.
Growing up in the pre-Internet era Reader’s Digest was such a good resource due to stories like these. Was always excited to see a new magazine arrive every month.
I wonder if it’s any good now. Haven’t looked at it in years.
If you are on a Mac or Windows, this approach only works for utilities that can run on Linux. If you need to run a native Mac program for example, docker won't be able to run that.
Perhaps Nix might help here, but I've never used it, so can't say for sure.
Does 1.1.1.1 send ECS info to Cloudflare’s own nameservers? More generally, does 1.1.1.1 in any way treat Cloudflare’s own nameservers in a special way and send it information that it doesn’t send to others?
If the answer to these questions is no, then Cloudflare’s reasons for blocking ECS (ie privacy) carry weight. Otherwise no.
Here’s what I wrote on this (along with a small library to handle this problem): https://lisper.in/javascript-date