#git

93 bookmarks tagged with #git · RSS Feed · ← All Tags

Don't couple your Go code to GitHub | Iain Cambridge

https://iain.rocks/blog/dont-couple-your-go-code-to-github
The main problem with using your git hosting location is that your code is now coupled to a hosting provider. That is, if you move your git hosting to GitLab then you have to change your code! Otherwise, you’ll be fetching the old verison. This can result in you being unable to change git hosting provider because the amount of overhead in switching. So you literally end up with your code coupled to GitHub. Which sounds completely nuts, but it’s something that is pretty much defacto in the Go community.

GitHub is sinking – David Bushell – Web Dev (UK)

https://dbushell.com/2026/04/29/github-is-sinking/
GitHub is racing towards the mythical zero nines of uptime. Users are starting to notice that GitHub is now a Microsoft product. Eww! Official uptime paints a concerning chart. The missing status page tell a far worse story. Whatever the truth, it’s impossible to miss the delightful experience that is Microsoft GitHub if you use it semi-regularly.

Radicle: the sovereign forge

https://radicle.xyz/
Radicle is an open source, peer-to-peer code collaboration stack built on Git. Unlike centralized code hosting platforms, there is no single entity controlling the network. Repositories are replicated across peers in a decentralized manner, and users are in full control of their data and workflow.

git-pages/git-pages: Scalable static site server for Git forges (like GitHub Pages) - Codeberg.org

https://codeberg.org/git-pages/git-pages
git-pages is a static site server for use with Git forges (i.e. a GitHub Pages replacement). It is written with efficiency in mind, scaling horizontally to any number of deployed sites and concurrent requests and serving sites up to hundreds of megabytes in size, while being equally suitable for single-user deployments.

Grebedoc — static site hosting for git forges

https://grebedoc.dev/
In short: a service that publishes the pages branch in your Git repository as a website on your domain; think GitHub Pages if it was open source and community operated. More specifically, it is a public deployment of git-pages and Caddy configured to work especially with Codeberg but also with other Git forges. It is operated by Catherine 'whitequark' and teammates, and currently deployed using Rage4 anycast infrastructure routing to VPSes in six regions (Europe, North America East, North America West, South America, East Asia, Australia), with site contents stored on Tigris and backed up to Wasabi.

cdzombak/newt at dzombak.com

https://github.com/cdzombak/newt?ref=dzombak.com
Manage Git worktrees with ease. newt is a simple wrapper around Git worktrees that automatically organizes them in a .newt/ directory, provides merge status tracking, and handles deletion.

Simple automated deployments using git push

https://garrido.io/notes/simple-automated-deployments-git-push/
Using git push remains one of my favorite ways of deploying software. It’s simple, effective, and you can stretch it significantly until you need more complex workflows. I’m not referring to using git push to trigger a Github action which builds and deploys software. I’m talking about using git push web main to deploy your main branch to a server that you’ve named web.

My self-hosted Forgejo runner setup | I do what I can

https://mteixeira.wordpress.com/2025/02/03/my-self-hosted-forgejo-runner-setup/
In this (very long post) I will be demonstrating how I have setup my self-hosted Forgejo runners at home using Docker Compose, Docker-in-Docker and a bonus LXC. To demonstrate with a practical example, I will be building an Ansible Execution environment, to be used in my home lab automation. There will be two versions of it: a single node, and a dual node build. Both will result in the images for two platforms/architectures (AMD64 and ARM64).

meks.quest

https://meks.quest/blogs/the-theatre-of-pull-requests-and-code-review
A key part of having a reviewable PR is writing commits that tell a story. Present your changes incrementally and logically so reviewers can follow your thought process. Generic commit messages such as "add dependency," "implement file upload feature," and "address PR feedback" don’t tell much of a story and leave reviewers guessing. Why was the dependency added? What were the specific steps in creating the file uploader feature? What feedback is being addressed?

Working with stacked branches in Git is easier with --update-refs

https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/
In this post I described the new --update-refs feature for rebasing in Git 2.38. I introduced the concept of stacked branches and stacked PRs, and why I like them for feature development. Unfortunately, keeping stacked branches up to date can be quite arduous, requiring a lot of tricky rebasing. with --update-refs the commands are significantly simplified, as I showed in various scenarios. You can even enable --update-refs by default, so that all your rebases use it!

Contributing to Atom

https://atom.io/docs/latest/contributing#git-commit-messages
Use the present tense ("Add feature" not "Added feature") Use the imperative mood ("Move cursor to..." not "Moves cursor to...") Limit the first line to 72 characters or less Reference issues and pull requests liberally Consider starting the commit message

Note to Self - Git

http://git-scm.com/blog/2010/08/25/notes.html
Wouldn't it be nice if you could add data to a commit without changing its SHA? If only there existed an external mechanism to attach data to a commit without modifying the commit message itself. Happy day! It turns out there exists just such a feature in newer versions of Git! As we can see from the Git 1.6.6 release notes where this new functionality was first introduced:

libgit2

http://libgit2.github.com/
libgit2 is a portable, pure C implementation of the Git core methods provided as a re-entrant linkable library with a solid API, allowing you to write native speed custom Git applications in any language which supports C bindings.

libgit2

http://libgit2.github.com
libgit2 is a portable, pure C implementation of the Git core methods provided as a re-entrant linkable library with a solid API, allowing you to write native speed custom Git applications in any language which supports C bindings.

GitHub Pages

http://pages.github.com
GitHub Pages are hosted for free and easily published through our site, the GitHub for Mac app, or from the command line. Manage your site’s content from GitHub using the tools and workflow that you’re familiar with. Learn about publishing with GitHub Pages here.

Never Use Source Control GUIs! « late.am

http://late.am/post/2011/09/27/never-use-source-control-guis
In 5 years, something like 90% of the source control mishaps I’ve seen can be attributed to GUIs hiding complexity of what they’re doing. Git can be a beast to learn, for sure; but at least once you develop an intuition, you can be reasonably safe in performing even advanced operations at the command line tool, in a way I’ve never felt (or felt from co-workers) about GUI tools.

#reviewth.is @github

http://reviewth.is/
GitHub gives us almost everything we need to do code reviews. Commit, file and line level comments, comment notifications, plus everything else that makes the GitHub experience great. The only thing missing is an easy way to initiate a review. If I want my code to be reviewed, I’ve got to go to GitHub, get the URL (and any other info), then compose an email to everyone I want to review it.

#reviewth.is @github

http://reviewth.is
GitHub gives us almost everything we need to do code reviews. Commit, file and line level comments, comment notifications, plus everything else that makes the GitHub experience great. The only thing missing is an easy way to initiate a review. If I want my code to be reviewed, I’ve got to go to GitHub, get the URL (and any other info), then compose an email to everyone I want to review it.

Moving from SVN to Git in 1,000 easy steps! « Code as Craft

http://codeascraft.etsy.com/2011/12/02/moving-from-svn-to-git-in-1000-easy-steps
Overall we can say the Git migration was a success. It turned out to be an immense task with a maze of dependencies, but in the end we’re on a current version control system that should last for years to come. It opens up many new workflow possibilites and solves some of our existing problems, not to mention it’s blazing fast. If you’re more interested in the technical instead of the social migration of SVN to Git, I wrote a blog post a few years ago on my personal blog that you may be interested in, and there’s also a couple of pointers over on github on how to make the conversion.

Open Source (Almost) Everything

http://tom.preston-werner.com/2011/11/22/open-source-everything.html
Should we open source Grit or keep it proprietary? Keeping it private would provide a higher hurdle for competing Ruby-based Git hosting sites, giving us an advantage. Open sourcing it would mean thousands of people worldwide could use it to build interesting Git tools, creating an even more vibrant Git ecosystem. After a small amount of debate we decided to open source Grit. I don't recall the specifics of the conversation but that decision nearly four years ago has led to what I think is one of our most important core values: open source (almost) everything.

Persistent Trees in git, Clojure and CouchDB « EclipseSource Blog

http://eclipsesource.com/blogs/2009/12/13/persistent-trees-in-git-clojure-and-couchdb-data-structure-convergence
"This is a tale of three images. I found these images while investigating the internals of several different applications. There are some really neat software projects emerging at the moment, and as a developer I always find it interesting to take a look at the implementation details, because there is often a lot to be learned. It’s not always something you might need right now, but maybe a few years down the line you may be confronted with a similar problem. Plus – in my opinion – knowing a bit about the internals of a program helps reasoning about its behaviour."

Pro Git - Smart HTTP Transport

http://progit.org/2010/03/04/smart-http.html
"I think HTTP based Git will be a huge part of the future of Git, so if you’re running your own Git server, you should really check it out. If you’re not, GitHub and I’m sure other hosts will soon be supporting it - upgrade your Git client to 1.7ish soon so you can take advantage of it when it happens."

geewax.org | Agile git Workflow

http://geewax.org/2009/11/21/agile-git-workflow.html
"Agile" is kind of a dirty word in some circles, but this describe some actually agile ways to deal with revision control using git. "When we started using git to manage our source code at work, we actually jumped in a little bit too fast. It seems like there is a lot of writing about how you can do lots of really neat things with git, but no real guide about one particular way of using git for your project. This post is going to describe how we use git day to day on a reasonably large “agile-style” project."

cloudhead.io

http://cloudhead.io/toto
"toto is a git-powered, minimalist blog engine for the hackers of Oz. The engine weighs around ~230 sloc at its worst. There is no toto client, at least for now; everything goes through git."

Patchwork - Web-based patch tracking system

http://ozlabs.org/~jk/projects/patchwork
"Patchwork is a web-based patch tracking system designed to facilitate the contribution and management of contributions to an open-source project. Patches that have been sent to a mailing list are 'caught' by the system, and appear on a web page. Any comments posted that reference the patch are appended to the patch page too. "

nvie.com » Blog Archive » A successful Git branching model

http://nvie.com/archives/323
"In this post I present the development model that I’ve introduced for all of my projects (both at work and private) about a year ago, and which has turned out to be very successful. I’ve been meaning to write about it for a while now, but I’ve never really found the time to do so thoroughly, until now. I won’t talk about any of the projects’ details, merely about the branching strategy and release management."

Google Open Source Blog: Export a Git Project to Google Code

http://google-opensource.blogspot.com/2008/05/export-git-project-to-google-code.html
"Git and Subversion can work together in many ways. Previously, we showed how Git users can work with a project primarily managed by Subversion. In this post, we describe one way to handle the converse: Google Code acts as a stable read-only Subversion mirror of a Git project. In this model, patches are first applied to the central Git repository and exported to Google Code later."

A web-focused Git workflow

http://joemaller.com/2008/11/25/a-web-focused-git-workflow
"The key idea in this system is that the web site exists on the server as a pair of repositories; a bare repository alongside a conventional repository containing the live site. Two simple Git hooks link the pair, automatically pushing and pulling changes between them. "