it's always wild to me hearing what pressure people use.
on my road bike with 28c and inner tubes, 60 psi is what i use on _good_ road surface. maybe the roads are just shit here, but even 55 psi feel rough. i usually run on around 50 psi, 40 in winter.
there was a time i lost my track pump and i just pump the tyres using a mini pump without a guage. later i discovered i was running on something as low as 30 psi.
i have never had a pinch flat. i don't think i'm particularly light. full load when doing groceries is probably 85 kg. is it just that my pressure juage is woefully inaccurate?
navigation properties are not loaded automatically, because they can be expensive. you need to use `.Include(foo => foo.Bars)` to tell EF to retrieve them.
EF tries to be smart and will fix up the property in memory if the referenced entities are returned in separate queries. but if those queries don't return all records in `Foo.Bar`, `Foo.Bar` will only be partially populated.
this can be confusing and is one of the reasons i almost never use navigation properties when working with EF.
Published history in Mercurial is sacred [1]. Modern Mercurial fully embraces history editing, and provides (IMO) better tools than git to facilitate (safe, collaborative) history editing.
[1] You can still change published history if you try hard enough with a lot of co-ordination.
If Mercurial doesn't support cleaning up of commits, then the commit history of Mercurial itself [2] wouldn't look so clean.
I drew a different conclusion from similar experience. I avoid navigation properties and other advanced mapping features, so an entity maps flatly to one table.
The LINQ queries will be more verbose as you'll need to write the join and group clauses explicitly, but I find it much easier to predict the performance of queries since the generated SQL will look almost exactly the same as the LINQ syntax. It's also less likely to accidentally pull in half the database with `.Include()` this way.
You can use `hg commit --interactive` to use the the commit itself as the staging area. And I'd argue that's a better model because:
- It limits the amount of time changes are stored in an intermediate state, making it much less likely to interfere with other operations, like pulling and switching branches.
- You can use the same commands (and mental model) to manage the "staging area" and other commits.
- The history of staging and unstaging becomes actual history and can be recovered and shared.
No reflog, but there is the obslog, which stores obsolescence history of individual revisions. Better yet, the obslog is distributed during pull / push. Because Mercurial knows precisely which commit is replaced by which commit, it can automatically resolve a lot of conflicts that result from history editing.
Have a branch-a that depends on branch-b that depends on branch-c that upstream just rebased and squashed some of its commits? More often than not `hg pull && hg evolve` is all you need to do to synchronise everything. This makes stacked PRs much easier to manage.
I agree having production updated frequently is ideal, but sometimes we don't get to choose when things are deployed when working with external clients. I'm glad Terraform doesn't dictate the workflow, so that we can fix one thing at a time.
I'll consider this a variation on moving state elsewhere. Now you have to keep the deleted resource forever. Or keep track of which environments the version with the removal directive is deployed to, or risk having orphaned resources in different environments.
If Terraform is stateless, how does it know what it needs to / can delete?
You'll either have to:
- Move the state management elsewhere, and invoke different commands depends on what and how resources are changed. This will make automation difficult, and doesn't solve the problem.
- Make Terraform assume that everything it sees is under its management, deleting everything not defined in the current configuration. This will make Terraform hard to adopt in an environment with existing infrastructure.
By default, Mercurial doesn't allow editing of public history pushed to or pulled from a remote repository. There are no such restrictions for local revisions, which are considered draft. And if you configure the remote as a draft repository, you can keep some remote revisions as draft before publishing them.
The history editing capability of Mercurial is arguably more advanced than git, especially in a collaborative setting, because of Changeset Evolution [1], and the Evolve extention [2]. The former keeps track of metahistory of commits. The former keeps track of the metahistory of commits, and synchronises it between repositories. The latter provides a set of expressive command line tool to edit history. With them, collaborative history editing and stacked PR is a pleasant experience.
We have have been on self-hosted Heptapod [1] for about a year without much complaint. Heptapod is a fork of GitLab with Mercurial support. For open source projects, there is a free hosted version [2].
if you do this often and want some automation, `git absorb` [1] may be worth a look. it will try to find lines that can be unambiguously attributed to a diff based on when the line and its surrounding lines are last modified, and then generate fix-up commits or amend existing ones.
Changeset Evolution [1], which allows me to amend and rebase shared commits without co-workers hating me, even when they are building on top of the mutated commits.
combined with a large set of tools to tweak commits (i mostly use absorb, amend, split, fold, uncommit, pick), it is very nice to work with if you value a clean history.
there is also the very powerful revset DSL for finding revisions and/or files.
There is one (though incomplete)! And it's called Mercurial. Since 5.4 released earlier this year, Mercurial is slowly gaining [1] the ability to operate on local Git repositories with its bundled git extension [2].
Yes, unreachable commits in Git are GC'd eventually, but you can disable it.
In Mercurial, hidden changesets are kept locally indefinitely, but they are not exchanged; only their obsolescence makers are. So you always know the meta-history of a changeset, but not necessarily their original content.