aayjaychan

There is no "one-time" over the network. Invalidating the refresh token immediately when the server recieves it is asking for trouble.

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.

[2] https://foss.heptapod.net/mercurial/mercurial-devel/-/commit...

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.

csproj is fine these days. sln on the other hand...

that would be `hg prune` in modern Mercurial.

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.

[1] https://www.mercurial-scm.org/wiki/ChangesetEvolution [2]: https://www.mercurial-scm.org/doc/evolution/

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].

[1] https://heptapod.net/ [2]: https://foss.heptapod.net/

Other hosting options can be found on Mercurial's Wiki page on hosting [3].

[3] https://www.mercurial-scm.org/wiki/MercurialHosting

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.

[1] https://github.com/tummychow/git-absorb

in some accents they rhyme because of the cot-caught merger.

https://en.wikipedia.org/wiki/Cot%E2%80%93caught_merger

Does GitLab count as a GitHub-like experience? There is a fork of GitLab called Heptapod that supports Mercurial.

https://heptapod.net/

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.

[1] https://www.mercurial-scm.org/wiki/ChangesetEvolution

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].

[1] https://www.mercurial-scm.org/repo/hg/log?rev=keyword%28%27g... [2]: https://www.mercurial-scm.org/wiki/GitExtension

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.

Git does hide the old commits as well. What git doesn't do is track which commits are replaced by which. So sharing mutable history and seeing how a commit evolved over time requires more heuristic than necessary.

It works pretty well for the most part, since vim verbs and nouns are kind of like acronyms. 'w' goes to next Word. 'b' goes Back a word, 'i' enables Insert mode, 'd' Deletes something. So as long as you know where the keys are, it's fine.

What doesn't work is the default hjkl navigation. On Colemak these keys are on a rotated L shape around the right index finger, where j (down) is above k (up)...

I remapped them based on their position. h: up, k: down, j: left, l: right. Still not as convenient as hjkl on qwerty, but at least it make sense.

When I'm on Ergodox, I map arrow keys to the bottom row like those on Kinesis Advantage. Since they are close enough I use them instead of hjkl.

To me as a daily Mercurial user, the biggest thing it brings is, in Git parlance, a distributed reflog. It makes sharing of mutable history much easier and safer.

Mercurial has the concept of changeset evolution [1] that tracks the meta-history of changesets (commits): who re-wrote which commits at when using what command. Stored as obsolescence markers in the obstore, this meta-history is synchronised with remote repositories on pull and push.

[1] https://www.mercurial-scm.org/wiki/ChangesetEvolution

Combined with a nice history rewriting UI provided by the evolve extension [2], this allows some advanced collaborative workflows that are pretty awkward in Git.

[2] https://www.mercurial-scm.org/doc/evolution/

Suppose you developed feature x on branch [3] feature-x, and submitted it for review. At the same time, you started developing feature y that depends on feature-x on branch feature-y. When feature-x is integrated to master via a rebase, you can run `hg pull` and `hg evolve`, and Mercurial will automatically rebase feature-y on top of master. This also works when commits are edited, squashed, split, reordered, or dropped. This gives reviewers more freedom to decide what to accept, without having to worry disturbing contributors' work.

[3]: Using Git parlance to simplify things. Branches meaning something else in Mercurial.

Now you've also pushed feature-y. This time the reviewer wants you to change something. You changed the commits, and pushed feature-y again. Even without force push, the server will not reject the push, because it knows from the obsolescence marker that the new commits are not really new but are re-written old commits. Again, this even works when commits are rebased, squashed, split, reordered, or dropped.

While there is no commitment yet, now that Mercurial is gaining the ability to operate on Git repositories, there are discussions on how to store obslog in Git's store, so maybe that's something that Git will eventually have.

Another thing I like very much is that every commit in Mercurial is a standalone ref. This makes a patch-based workflow a lot simpler as you don't need the ceremony of creating and cleaning up branches. You also don't run into detached heads.