For us to be able to help you, I think you need to give us some more details about the organization of your work. If each chapter is a separate text file, then you don’t really need to do any branching at all (assuming people will only make changes on their own files and not touch others’ work). If it is a single text file, branching (or anything else, to be honest) will not help much.

I assume chapters will have their separate files. As long as you can control who touches which file, everybody can work on the same branch (also referred to as “trunk based”). But if you fear that people may interfere with each other’s work (willingly or by accident), then it makes sense to create a branch per chapter to keep contributors at a distance from each other. But working on a single repository requires some sort of an agreement on the workflow.

Not sure but that sounds like you have a problem with your Git installation (or a dependency of Git). Maybe a reinstallation can solve that.

I understand the “why would I pay for this” reaction. I think crowdsourcing is a better approach for these kinds of content. Once you reach certain level of financial commitment from the crowd, you can give away the PDF and sell the print copy.

git branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space

Yeah, once you realize that everything falls into place.

I believe you can replace start with the command that is suitable for your system (e.g., xdg-open for linux).

Here is the link to the original website (an NGO that monitors blocked websites in Turkey): https://ifade.org.tr/engelliweb/distrowatch-erisime-engelledi/

And here is the Google translation of the text on that page:

The IP address of the DistroWatch platform, which provides news, reviews, rankings and general information about Linux distributions, was blocked by the National Cyber ​​Incident Response Center (USOM) on the grounds of “IP hosting/spreading malware”.

What checkout actually does. Here is a past comment with links to the courses (they are pay-walled, unfortunately)

I don’t think I read that one. I created a separate link-post for that one. Thanks.

Mine happened when I watched Paolo Perrota’s Git courses on Pluralsight. That’s when it clicked for me.

The URL seems to have a typo. Correct URL is https://github.com/presslabs/gitfs

I don’t follow it very closely, but as far as I know, they are the only one implementing the open protocol they designed (which doesn’t interoperate with ActivityPub). However, there seems to be some efforts for creating a bridge: https://www.docs.bsky.app/blog/feature-bridgyfed

As you said, there are some recognizable faces and that may impact the adoption. But not being compatible with ActivityPub is a real bummer.

That’s explained at the end (Revisions). Fowler is probably looking for a general term that can be used to describe this specific way of debugging. Since he is aware of git bisect (and I’m sure he knows about hg bisect) there must be a reason he is not preferring “bisect debugging,” for example.

Edit: The term diff has a clear link with version control. bisect is not that obvious. It may be ambiguous/vague in debugging context. I would still call it “bisect debugging.”

Beginning in Git 2.43, Git will realize when it’s about to perform a double-revert, and instead produce the much more pleasing message

Doesn’t happen very often, but I’m glad we have a better solution to this now.

This sounds more like a Github question.

Reading the manual? That’s cheating!

Apart from the historical value, the most important part of this article now is the “Note of reflection” added 10 years after it’s inception:

If your team is doing continuous delivery of software, I would suggest to adopt a much simpler workflow (like GitHub flow) instead of trying to shoehorn git-flow into your team.

I don’t think this work flow is relevant any more even for teams that don’t do CD, to be honest. It was a messy work flow to begin with and I haven’t seen it applied successfully in practice.

I don’t think Git has built-in support for that, but there seems to be some syntax/language aware diff tools that can be configured as the difftool.

I see. Good luck with your search. Would be great if you could update the thread once you settle on a solution.

Not sure I understand the use case and why something like VS Code’s Git UI (or some other GUI) cannot solve the problem. Why does it need to be web-based, for example?

I believe there is already a browser add on for this. Cannot remember the name right now.

Edit: I think this should be in Lemmy core.