void foo() {
    std::vector v = {0, 1, 2, 4};
    const auto& ref = v[1];
    add_missing_values(v);
    std::cout << ref << "\n";
}

void add_missing_values(std::vector<int>& v) {
    // ...
    v.push_back(3);
}

Neither foo(), nor add_missing_values() looks suspicious. Nonetheless, if v.push_back(3) requires v to grow, then ref becomes an invalid reference and std::cout << ref becomes UB (use after free). In Rust this would not compiles.

It is order of magnitudes easier to have lifetime errors in C++ than in Rust (use after free, double free, data races, use before initialisation, …)

Is it possible to do in Rust?

Yes

Is possible to do in Rust, by mistake, and not easily caught by a review?

Definitively not.

DRY and YAGNI are awesome iif you also practice YNIRN (You Need It Right Now)! Otherwise you just get boilerplate of spaghetti

You got me in the first 3 quarters, not gonna lie!

There are cases where instead of origin/master..HEAD you may want to use @{upstream}..HEAD instead to compare with the upstream of your current branch. It’s unfortunately quite unknown.

The fact that rustc has bugs (which is what cve-rs exploit) doesn’t invalidate that rust the language is memory safe.

git worktree could become your new friend then :)

The quote (and the associated discussion) is such an important part of Rust and why I love this language so much. Anything that can be automated should at one point be automated reliably, and the sooner the better.

It was when I read the git parable.

I wasn’t clear enough. But in a contry where the sun rise at 20:00, the weekday looks like:

• day 1: Monday morning to Tuesday evening
• day 2: Tuesday morning to Wednesday evening
• day 3: Wednesday morning to Thurday,
• …

And phares like "let’s meet on Tuesday“ without hour indication could either mean end of day 1 or start of day 2. Likewise "let’s meet the 20th” (assuming the 20th is a Tuesday) could either mean end of day 1 or beggining of day 2.

–

And alternative be to have

• day 1 == Monday == “end of the 19th” to “the start of the 20th”
• day 2 == Tuesday == “end of the 20th” to “the start of the 21st”
• day 3 == Monday == “end of the 21st” to “the start of the 22nd”
• …

Which solve the issue of "let’s meet on Tuesday”, but not “let’s meet the 20th”.

The issue is that the notion of “tomorrow” becomes quite hard to express. If it’s 20:00 when the sun rose, when does tomorrow starts? In 5 hours ?

That’s only a summary of the introduction! The full story is much more interesting

I am always doubtful when people say that accessing information inside git is hard. I totally agree that defaults in git can be improved (and they are, git restore and git switch are a much better alternative to git checkout that I no longer use). So let’s review the section “A Few Reasons Why SQLite Does Not Use Git”:

“Git does not provide good situational awareness”

git log --graph --oneline --author-date-order --since=1week

Make it an alias if you use it often. Alias is what helps you create your own good default (until everyone uses the same alias and in that case it should be part of the base set of commands).

“Git makes it difficult to find successors (descendants) of a check-in”

git log --graph --oneline --all --ancestry-path ${commit}~..

Likewise you could consider making it an alias if you use it often. Aliases can also be used as a post-it to help you remember what are the command that you find useful but you only use once in a blue moon!

The mental model for Git is needlessly complex

I may agree about that one. For reference, this is what the article says:

A user of Git needs to keep all of the following in mind: The working directory The “index” or staging area The local head The local copy of the remote head The actual remote head

If git fetch was run automatically every so often, as well as git push (of course in a personal branch), then this model could be simplified as

• the working directory
• the “index” or staging area (I actually think that being able to have more than one for drafting multiples commit at once, like a fix and a feature at the same time would be better than only having a single index)
• your working copy of the shared branch
• the shared branch

And integrating your changes (merging/rebasing) should probably be exclusively done using a PR-like mechanism.

Git does not track historical branch names

I’m skeptical about the usefulness of this. But since git was my first real vcs (10 years ago), it may just be that I have not used a workflow that took advantaged of persistant branches. I assume that git annotate could be a solution here.

Git requires more administrative support

most developers use a third-party service such as GitHub or GitLab, and thus introduce additional dependencies.

That’s absolutely true but I’m not sure it’s a real issue. Given how many strategies there are for CI/CD (and none is the definitive winner yet) I do think that being able to select the right option for you/your team/your org is probably a good idea.

Git provides a poor user experience

https://xkcd.com/1597/

I highly disagree about that xkcd comics. Git is compatible will all workflows so you have to use a subset of all the commands. Of course you will have more commands that you never use if a software is usable for all the workflow that you don’t use. But you need about 15 commands to do stuff, 30 to be fluent, and some more to be able to help anyone. Compared to any other complex software that I use I really don’t think that it’s an unreasonably high count. That being said I totally agree that git from 10+ years ago was more complex and we should correctly teach what is needed to junior. HTML/css/js is a nightmare of complexity but it doesn’t stop 15 years old kid with no mentoring to build cool stuff because you don’t need to know everything to be able to do most of the things you may think of, just a good minimal set of tools. And people should definitively take the time to learn git, and stop using outdated guide. Anything that don’t use git switch, git restore and git rebase --interactive and presents you have to inspect the history in length (git log --graph or any graphical interface that show the history in a graph, git show, and more generally than you can filter the history in any way you want, being by author, date, folder, file type, …) is definitively not a good guide.

To sum-up, I think that from this presentation fossil seems more opinionated than git which means that it will be simpler as long as your workflow exactly matches the expected workflow whereas using git requires to curate its list of commands to select only the one useful for yours.

Moving to git is nice but I don’t understand why they don’t self-host a gitlab instance.

Couldn’t this be solved by having push_back being an inline function (or at least the check on capacity being inlined and the rest of the non-trivial part being in a sub non-inline function)?