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.

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.

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.

each function has its own independent metal toggle switch

one steering wheel to steer left, and one to steer to the right

they want to push a lot of buttons on those controls

LOL

Even with a lot of buttons available, good videogame controls are simple and narrow. Natural combinations add depth without overcomplicating things.

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.

I think the fundamental difference is that Git is a CLI tool. But that’s not how or where people use and want to use it. So obviously various interfaces are being created. It’s not alternative CLI that are created. It’s UIs and GUI interfaces. For a lack of a [more-than-barebone] official one.

Shells remain CLI. Distros are also technically/technologically driven.

Maybe the better analogy is that with vim and nano, we see many text editors and IDEs with GUIs.

There is no other CLI tool like Git. But

Shell or Bash has various alternative shells.

Vim has numerous plugins and alternatives/extensions.

Linux distributions are wide and varied, forking out.

I’m glad I was able to establish a very mindful and structured approach to Git history in my team and project.

deleted by creator