Worktrees share the data stored in the .git folder. This saves storage (particularly on larger repos, and if you don’t fetch/clone only partial history), and could allow some other workflows or safeguards (backing up just one instead of multiple, centralized local state instead of spread across different workspaces). It also means it could share repo-local git settings - like remotes, local not checked-in ignores, etc. (I assume).

not found for me too

None of the URL parents have content. The root page only has a placeholder page with an image and placeholder text.

It’s both. The VS Code dotnet tooling implemented support for it too.

The file blob line link to GitHub has a ref parameter with their domain. I have to assume that’s not sponsored or cooperative but diffuse SEO? Absurd.

…/bundle-uri.c?ref=blog.gitbutler.com#L393-L418

It irritates me that URLs get polluted through this practice. Especially considering HTTP has a referrer header.

This feels way too apologetic by MS to me. Dunno if that’s mainly the reporting in this article.

When asked by BleepingComputer about this development, cybersecurity researcher Amit Assaraf continued to claim that the extension did contain malicious code. However, there was no malicious intent from the publisher, commenting that “in this case, Microsoft moved too fast.”

They “accidentally included” stuff that didn’t belong in there. They obfuscated their code. Multiple red flags were hit.

For me, moving fast in blocking spread seems warranted. Maybe it shouldn’t trigger removal on installs immediately, depending on how fast they can check.

The authors ban circumvention and outdated dependency the cause but not an issue claims were dubious at best as well.

Sure, maybe no ill intent. But that doesn’t mean security practices should not happen.

Unless you need a “stable” version of your in-development work I wouldn’t split parts of it into branches.

Use branches to draft and explore changes, and merge them when they’re accepted into the baseline draft/current state.

Don’t be afraid to merge “better than before but not final or complete or conclusive” work. You’re trying to evolve, not construct final parts to combine. They won’t ever be final.

But what was the “loop” they mention?

The linked issue comment has the info about it

Letting you know that VSCode is unable to uninstall the extension. It prompts me to uninstall, but when I confirm the window refreshes and the extension is still there, triggering the same “is problematic” prompt. This is an infinite loop. Same behavior when trying to uninstall the usual way from the extensions panel.

lol, release-notes.js - obfuscated; at first I thought it was the release notes data or content, but maybe it’s the logic for displaying it?

Outdated sanity-io dependency somehow led to compromise? I still don’t get how. It wouldn’t suddenly integrate something else. Does it source data from elsewhere during build, and that was compromised too? Does it call into the web for no reason in the first place?

Either way, it’s an issue of their integration. Claiming “it’s not an issue in our extension” while shipping compromised code is just wrong.

Obfuscating their index.js theme logic because it’s closed source may seem fine if they’re trustworthy, but with this violation and breach, that trust is gone.

https://codeberg.org/lig/todo-md/issues/4

I didn’t create one because I won’t be using the project, but suggested it here for your consideration. :)

Outside of work-in-progress or exploration branches, I don’t commit or merge TODOs. Typically, I consider them merge/land blockers. Because most of the time, they’re never resolved. And in that case, I much prefer documentation and statements; reasoning of why it is the way it is, or opportunities.

Maybe you want to scan for FIXME: too?

I’ve used it at work. But the manual management/maintenance of a commit list makes it practically infeasible. I’ve use it for bit cleanup commits, but not since. When blaming, the previous revision is just one click away anyway. The maintenance doesn’t seem worth the effort.

I guess a commit message tag and script that generates it automatically could make it viable. But I’ve not found the need to yet.

Given that it is high level, I assume you did not want to include this. I’ll mention it here in a comment either way. Text form in the commit message.

I really like using conventional commit messages and introduced it in my projects. We defined a few types, and more leniently choose optional scopes. It’s very useful for categorizing and skimming through commit lists, and for generating changelogs/release notes. `fix(account): Use correct hasing xy"

Consistent imperative form is important to me too. The commit message examples talks about “Summary of changes”, which has no verb, and so, may mislead to a different undesirable form of summarizing changes. (“Change xy” instead of “changed xy” or “[now] does xy [at runtime]” or “did z”.)

I didn’t fully read it, only skimmed, so excuse me if I missed mentions of the commit message text form. It seems very elaborate otherwise.

My browser has a default font size of 18 set. The site overrides that with a default base font size of 12px, then increases it to 13px for content text. That’s way too small for me on my screen. At least to read it comfortably. Or for people who need more accessible text/font.

They wrote they’re using . as placeholder commit messages.

I use f for such [f]ollowup/[f]ixup commits, and a for [a]dditional code/components/changesets. Both keys are trivial to enter. When cleaning it up after, f commits are typically squashed into previous ones, and a commits get a description and/or serve as a base for squashing.

I can see . working well as well, but having a more obvious character (with vertical height/substance) seems preferable.

You don’t see the point of making use of shortcuts?

It’s just them with shortcuts, they didn’t see the point of m

😏

How did it change how I think about version control? Not much? The goals are still the same. It only does many things better than previous centralized tools.

When DVCS came up and became popular, I used Git and Bzr.

At work, we used subversion. In one project, we had one SVN repository in our office and the customer had one in their office. A colleage had created a sync util. We regularly synced all history into an external hard drive, drove to the customer, and merged it there. Required a thorough and checklist process, potentially conflict resolution, and changelog generating for the big merge commit. Then drive back to the office, and merge back there.

Of course sometimes you used remote desktop to hotfix changes in their code base. Meaning you’d now have the change in two places as different commits.

Anyway, I’ve never found Git difficult. I used it, learned and understood it, and it’s consistent. I know enough “internals”/technical details to understand and use it well and without confusion.

Quite elaborate but also very interesting read on git and version control history.

I don’t get the title. Why is it “A Git story: Not so fun this time”? What is not so fun time referring to?

If working around it is an option, you could switch from https to ssh protocol.