# git commit Published articles for git commit. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Libreboot 20141015 release DevFeed: [Libreboot 20141015 release]() Original publisher: [Read original article]() Author: Leah Rowe Published: 2026-09-17T04:32:50.666044Z Content type: release Language: en Sources: [News about Libreboot releases and development]() Topics: [libreboot](), [coreboot](), [Hardware](), [x86]() Tags: [article](), [bios](), [canoeboot](), [coreboot](), [documentation](), [free-software](), [git-commit](), [hardware](), [libre](), [libreboot](), [opensource](), [patches](), [release](), [uefi](), [x86]() ### AI overview The Libreboot 20141015 release supports several Lenovo ThinkPad X60-series and T60 models, Apple MacBook1,1 and MacBook2,1 systems, and specified hardware configurations. It updates coreboot, SeaBIOS, Flashrom, and GRUB, revises documentation and build dependencies, enables several device features by default, and changes how SeaBIOS is added to ROM images. ### Source excerpt Article: Libreboot 20141015 release Web link: https://libreboot.org/news/libreboot20141015.html ## From RSS to Atom DevFeed: [From RSS to Atom]() Original publisher: [Read original article]() Published: 2026-05-04T00:00:00Z Content type: opinion Language: en Sources: [Susam Pal]() Topics: [Atom Feed](), [RSS Feed](), [Lisp](), [Git](), [XML]() Tags: [2026](), [git](), [git-commit](), [lisp](), [rss](), [xml]() ### AI overview The author describes switching a personal website from RSS feeds to Atom feeds in 2026. The change was implemented in Common Lisp, took about an hour, and included replacing RSS item identifiers with UUID-based Atom entry identifiers and updating feed templates. ### Source excerpt Yesterday, I switched my website from RSS feeds to Atom feeds. In case you are wondering whether you have somehow landed on an ancient post from 2010, no, you have not. Yes, this is the year 2026, and I have finally switched from RSS feeds to Atom feeds. Yes, I am fifteen, or perhaps twenty, years too late. Contents Impulse Coding Atom Entries Temporary Workaround Does It Matter? References Impulse Coding I have always wanted to do this but could never make the time for it. Finally, it happened while I was giving my brain some rest from my ongoing algebraic graph theory studies. That's when I felt like spending a little time on my website and doing a little Lisp to change the feeds from RSS to Atom. I suppose this was impulse coding, a bit like impulse buying, except that I ended up with an Atom feed instead of a new book. I find it quite surprising that when I have plenty of time, it usually does not occur to me to do these things, but when I am too busy and really short of time, these little ideas possess me during the short breaks I take. My personal website is one of my passion projects. Common Lisp is one of my favourite programming languages. So any time spent on this passion project using my favourite programming language is a very relaxing experience for me. It serves as an ideal break between intense study sessions. It took about an hour to implement the changes needed to make the switch from RSS to Atom. In the end, I could go back to my studies reinvigorated. In case you are curious, here is the Git commit where I implemented the change from RSS to Atom: 596e1dd. As you might notice, a large portion of the change consists of replacing the key attribute in each post with the uuid attribute. The key attribute value was used as the value of the element in the RSS feeds. While an arbitrary short string could serve as the element for the items in an RSS feed, the element of the entries in an Atom feed needs to be a URI. It turns out UUID URN ## Use 'git mv' to record filename case changes in Git DevFeed: [Use 'git mv' to record filename case changes in Git]() Original publisher: [Read original article]() Author: Ole Begemann Published: 2025-12-16T17:11:22Z Content type: tutorial Language: en Sources: [Ole Begemann]() Topics: [Git](), [Filesystems](), [macOS](), [Windows]() Tags: [files](), [git](), [git-commit](), [macos](), [windows]() ### AI overview This tutorial explains that case-only filename changes may not be recorded by Git on case-insensitive, case-preserving filesystems such as default macOS APFS. It demonstrates how using git mv records the new casing correctly and prevents filename mismatches in clones and case-sensitive environments. ### Source excerpt After my previous post Tracking renamed files in Git, here's another entry in my ongoing series "I thought git mv was useless but I was wrong". This one's especially relevant to users on macOS and Windows, where the file system is case-insensitive by default. More precisely, APFS on macOS is case-insensitive but case-preserving by default. That is, A.TXT and a.txt refer to the same file (and these two cannot coexist in the same directory), but the file system records the filename exactly as you entered it. If you're on a such a file system and change the case of a filename, Git will not record the new name -- unless you use git mv to perform the renaming. Demo 1. Without git mv (bad) Note: I tested this on macOS with the default APFS (case-insensitive) file system. You'll get different results if your file system is case-sensitive. Let's create a fresh repository and commit a single file named A.txt: mkdir testrepo cd testrepo git init echo "Hello" > A.txt git add . git commit -m "Create A" [main (root-commit) 3d73aea] Create A 1 file changed, 1 insertion(+) create mode 100644 A.txt Now we rename the file from A.txt to a.txt: # Rename the file (change case) # Note: not using `git mv` mv A.txt a.txt git status nothing to commit, working tree clean That's interesting. git status says "nothing to commit" because nothing has changed from its perspective. Git is still tracking a file named A.txt, whose contents haven't changed. If we now make edits to the file a.txt (aka A.txt; both names refer to the same file), Git tracks this as a change of the existing file, which is still named A.txt in Git's datastore: echo "World" > a.txt git status Changes not staged for commit: modified: A.txt Let's commit the change: git add . git commit -m "Edit A" [main e86bcb2] Edit A 1 file changed, 1 insertion(+), 1 deletion(-) Now we're in a situation where the recorded filenames on the file system and in Git have diverged. A fresh clone of the repository will create the file with its orig ## Format Swift with a Git Commit Hook DevFeed: [Format Swift with a Git Commit Hook]() Original publisher: [Read original article]() Author: Keith Harrison Published: 2025-11-24T10:29:58Z Content type: tutorial Language: en Sources: [K. Harrison]() Topics: [Swift](), [Git](), [configuration](), [Development](), [Code]() Tags: [auto-layout](), [bash](), [configuration](), [developer](), [development](), [git](), [git-commit](), [ios](), [objective-c](), [swift](), [wwdc](), [xcode](), [xcode-16]() ### AI overview This tutorial explains how to format Swift code automatically with swift-format and a Git pre-commit hook. It covers Xcode 16's bundled formatter, .swift-format configuration files, a Bash hook that formats staged Swift files, hook installation, and bypassing the hook when needed. ### Source excerpt How do you automatically format your Swift code every time you commit it to your Git repository? Swift Format There are several Swift formatting tools. Xcode 16 shipped with swift-format included in the toolchain: $ xcrun --find swift-format /Applications/Xcode.app/Contents/Developer/Toolchains/ XcodeDefault.xctoolchain/usr/bin/swift-format To run the formatter: $ swift format MyFile.swift Note: This runs the swift-format bundled with the active Xcode development directory (beta or release). Configuring swift-format The Xcode settings let you configure various formatting options including indentation but I prefer to use an external configuration file for swift-format. By default, swift-format looks for a configuration file named .swift-format in the same directory as the files you are formatting. If there isn't one it looks in each successive parent directory. If it doesn't find a configuration file it uses a default configuration. You can dump the default configuration to get started: $ swift format dump-configuration > swift-format Modify the configuration file to meet your own code style: { "fileScopedDeclarationPrivacy" : { "accessLevel" : "private" }, "indentConditionalCompilationBlocks" : true, "indentSwitchCaseLabels" : false, "indentation" : { ... I keep my default configuration file in my base Developer directory: $ mv swift-format ~\Developer\.swift-format When needed, I can override the defaults by placing a modified configuration file in the project-specific root directory. Note: Don't forget to prefix the configuration file with a . Git Commit Hooks Git Hooks are a way to run custom scripts when different Git actions occur. A pre-commit hook runs when you commit changes to a repository. Here's the pre-commit script I'm using to run swift-format: #!/bin/bash GIT=/usr/bin/git GREP=/usr/bin/grep SWIFT=/usr/bin/swift # Staged (cached) added/copied/modified/renamed files FILES=$($GIT diff --cached --name-only --diff-filter=ACMR | $GREP '\.swift$') # Exit ear ## Using Git Pre-Commit Hooks DevFeed: [Using Git Pre-Commit Hooks]() Original publisher: [Read original article]() Author: Scott Lowe Published: 2025-10-20T15:00:00Z Content type: tutorial Language: en Sources: [Scott's Weblog]() Topics: [Git](), [Markdown](), [Bash](), [Script]() Tags: [aws](), [bash](), [cilium](), [cli](), [cloud](), [cni](), [code](), [containers](), [cri-o](), [devops](), [docker](), [git](), [git-commit](), [git-hook](), [go](), [hooks](), [iac](), [k8s](), [kubernetes](), [lint](), [linux](), [markdown](), [networking](), [oci](), [script](), [security](), [tests]() ### AI overview This tutorial explains Git pre-commit hooks and demonstrates using one to run Markdownlint on staged Markdown files before a commit. It notes that a non-zero hook exit status aborts the commit and presents a Bash implementation based on the author's site. ### Source excerpt A while ago I wrote an article about linting Markdown files with markdownlint. In that article, I presented the use case of linting the Markdown source files for this site. While manually running linting checks is fine--there are times and situations when this is appropriate and necessary--this is the sort of task that is ideally suited for a Git pre-commit hook. In this post, I'll discuss Git pre-commit hooks in the context of using them to run linting checks. Before moving on, a disclaimer: I am not an expert on Git hooks. This post shares my limited experience and provides an example based on what I use for this site. I have no doubt that my current implementation will improve over time as my knowledge and experience grow. What is a Git Hook? As this page explains, a hook is a program "you can place in a hooks directory to trigger actions at certain points in git's execution." Generally, a hook is a script of some sort. Git supports different hooks that get invoked in response to specific actions in Git; in this particular instance, I'm focusing on the pre-commit hook. This hook gets invoked by git-commit (i.e., the user running a git commit command) and allows users to perform a series of checks or tests before actually making a commit. If the pre-commit script exits with a non-zero status, then Git aborts the commit. Using a Pre-Commit Hook to Lint Markdown For my use case, I wanted to run Markdownlint to lint the Markdown files (as described in the previous article on linting Markdown) before the commit. To do that, I came up with the following script: #!/usr/bin/env bash MDLINT="/usr/local/bin/markdownlint" for file in $(git diff --cached --name-only --diff-filter=ACM | grep "\.md"); do if ! $MDLINT "$file"; then echo "Lint check failed on file '$file'." echo "Run markdownlint to identify the errors and try again." exit 1 fi done To make this script active as a pre-commit hook, you must name it pre-commit, you must place it into Git's hook directory (which defa ## Developer Certificate of Origin DevFeed: [Developer Certificate of Origin]() Original publisher: [Read original article]() Author: Stian Thorgersen Published: 2023-10-31T00:00:00Z Content type: article Language: en Sources: [Keycloak Blog]() Topics: [Open Source](), [Keycloak](), [git commit](), [Git](), [Maintainers]() Tags: [developer](), [git-commit](), [idm](), [kerberos](), [keycloak](), [ldap](), [maintainers](), [open-source](), [openid-connect](), [saml](), [sso]() ### AI overview The article explains the Developer Certificate of Origin and compares it with Contributor License Agreements. It states that Keycloak chose DCO because it is simpler for contributors and maintainers, requiring contributors to sign off on individual commits with git commit -s. ### Source excerpt For any Open Source project, it is important that any contributions contain code that can legally be contributed to the project, and that the project has the right to distribute it under its license. There are many ways to achieve this, where two popular approaches are Developer Certificate of Origin (DCO) and Contributor License Agreement (CLA). Developer Certificate of Origin (DCO) is the most lightweight approach, which requires contributors to sign-off on individual commits that are part of a contribution. This is easily done by using the --signoff (-s) option when creating a commit. For example: git commit -s -m "Description of the commit" This adds a Signed-off-by statement at the end of the commit, where the contributor certifies they are following the agreement laid out in the Developer Certificate of Origin (DCO). Contributor License Agreement (CLA), on the other hand, is a more complicated approach. As part of CLA, any contributors are required to sign an upfront agreement with the project before making any contributions. This provides a higher barrier for contributors, and also a higher cost for the Open Source Project as it has to maintain a list of approved contributors with a corresponding maintained archive of agreements. For Keycloak we decided to go with DCO as we believe it is much simpler both for contributors as well as maintainers. If you are interested in learning more about CLA vs DCO, opensource.com has an excellent article on the subject. ## Mining your CLI history for good git aliases DevFeed: [Mining your CLI history for good git aliases]() Original publisher: [Read original article]() Author: HTTP Toolkit; Tim Perry Published: 2020-11-30T13:35:00Z Content type: tutorial Language: en Sources: [HTTP Toolkit]() Topics: [Command-line interface](), [Git](), [Shell](), [Scripting, bash](), [coding]() Tags: [bash](), [cli](), [command-line](), [commands](), [git](), [git-commit](), [master]() ### AI overview This tutorial shows how to analyze shell history to identify frequently used Git commands and choose useful Git aliases. It demonstrates filtering, sorting, counting repeated commands, and grouping command prefixes to account for variable arguments. ### Source excerpt If you use the command-line all day, CLI improvements can add a huge boost to your workflow. One of the simplest ways to improve things is to make your most used commands easier & faster to type, by creating aliases. But which aliases? Which commands are most important for your usage? You can probably guess a couple, but it's hard to know for sure, and there's plenty you'll miss. Fortunately your CLI history already has all the answers, if you just know how to ask. As a software developer I'm going to focus on git aliases here, but this applies equally well to any command-line tools you use heavily. I'm also assuming a bash-compatible shell, but the same concept should translate elsewhere easily enough. The first step is to use history to do some digging and find out what commands you run most frequently. history prints every line you've run recently in your shell, in chronological order. That gives us the data we need, and with a little bash-fu we can start to get some answers. First, what're your most run git commands? history -n | grep git | sort | uniq -c | sort -k1,1nr -k2 That takes your history, filters for git commands, sorts them alphabetically, counts the repeated lines, and then sorts by the repeat count. You can add a | head -n X too, if you'd like to see just the top X results. For me, with a few weeks history on a new laptop, that looks like: 543 git status 272 git add -p 214 git tree 71 git diff 55 git commit --amend 53 git push origin master 32 git checkout -p 30 git reset 27 git stash pop 26 git stash That tells you a bunch about my git workflow already! These are all common commands I'm using frequently, and commands I should very seriously consider aliasing. It doesn't tell the whole story though. How come git commit --amend is so high up, but git commit doesn't appear at all? That's because for many commits I run git commit -m "..." to commit and pass a message inline, so each of those commands is treated as unique, and won't appear in this top l ## Conflict Resolution and Code Reviews DevFeed: [Conflict Resolution and Code Reviews]() Original publisher: [Read original article]() Author: nico@ponyfoo.com (Nicolás Bevacqua) Published: 2019-04-10T10:00:46Z Content type: tutorial Language: en Sources: [Pony Foo]() Topics: [Code review](), [Pull Request](), [Git](), [Code]() Tags: [checkout](), [code-review](), [code-reviews](), [git](), [git-commit](), [github](), [tips]() ### AI overview A tutorial on reviewing conflict resolution in large Git pull requests. It shows how to recreate the merge with conflict markers locally so reviewers can isolate and inspect the changes made to resolve conflicts, while ignoring unrelated branch changes. ### Source excerpt Have you ever tried to do a code review on a PR that merges a large release branch or feature branch back into mainline, fixing merge conflicts? It's not pretty. The diffs are often and easily very big, -- 50k+ LOC big -- have hundreds of commits, and the actual changes made by the engineer resolving the merge conflicts are virtually impossible to spot. This article covers one nifty trick I've been using lately in these cases that lets you review exactly the conflict resolution, while ignoring the mountains of changes that don't represent any conflicts (and can thus be safely ignored). Check out the PR locally If you haven't done this before, you can just add the author's remote (provided they're using a fork, otherwise you can skip this step) like so: $ git remote add nico https://github.com/nico/repo.git Then we can fetch the PR branch, let's assume it's called fix-merge-conflicts and it was merging branch-with-conflicts into master, fixing the conflicts along the way: $ git fetch nico fix-merge-conflicts $ git checkout fix-merge-conflicts Assess the situation The git log should indicate they've merged a couple branches. The commit hashes are the key bits here. $ git log -1 HEAD commit a9c9ed7gcc0a76670d86df4b732f1f219ccb48de (HEAD -> fix-merge-conflicts) Merge: aecf730802 ba9918dad5 Author: Bloodninja Date: Mon Apr 8 12:32:38 2019 +0000 Merge remote-tracking branch 'branch-with-conflicts' And now we can verify that these indeed belong to each of the branches we care about: $ git branch --contains=aecf730802 master * fix-merge-conflicts $ git branch --contains=ba9918dad5 branch-with-conflicts * fix-merge-conflicts Now for the magic git checkout -b what-were-they-thinking git reset --hard aecf730802 git merge --no-ff ba9918dad5 # this will conflict git add . git commit -m WIP At this point, what-were-they-thinking is the version of the conflict resolution where you just committed things exactly as git merge left them, conflict markers and all. ## git pre-commit hook for code beautification DevFeed: [git pre-commit hook for code beautification]() Original publisher: [Read original article]() Author: Ramon Published: 2016-01-30T20:22:19Z Content type: tutorial Language: en Sources: [Ramon Fried]() Topics: [Git](), [Linux](), [Script](), [Kernel](), [Command-line interface]() Tags: [artistic-style](), [astyle](), [code-beautification](), [coding-style](), [command-line](), [git](), [git-commit](), [git-hook](), [how-to](), [improvements](), [kernel](), [linux](), [linux-kernel](), [script](), [uncategorized](), [workflow]() ### AI overview A tutorial on using a Git pre-commit hook to automate code beautification. The hook runs astyle on files included in a commit, helping apply formatting rules such as spacing and indentation; the article also discusses Linux user-space and kernel coding styles and the checkpatch.pl script. ### Source excerpt Hi. In this post I will share a git pre-commit hook I created for aiding with code beautification. In Linux, I work in two different coding styles: User space and Kernel. The Linux kernel has a very specific coding style and every commit to kernel must adhere to that style. The Linux kernel provides a [...] ## Manage Dependencies With GODEP DevFeed: [Manage Dependencies With GODEP]() Original publisher: [Read original article]() Published: 2013-10-26T00:00:00Z Content type: tutorial Language: en Sources: [William Kennedy]() Topics: [Dependency management](), [Go Language](), [reproducible builds](), [Code](), [Git]() Tags: [ardan-labs](), [blog](), [build](), [code](), [dependencies](), [dependency](), [git](), [git-commit](), [go](), [go-programming](), [golang](), [import](), [install](), [management](), [packages](), [programming](), [reproducible-builds](), [version-control]() ### AI overview This tutorial explains how to use godep to manage third-party Go dependencies and create reproducible builds. It covers installing godep, creating a project, generating a Godeps file with dependency version information, and vendoring packages. ### Source excerpt Introduction If you are using 3rd party packages, (packages that you don't own or control), you will want a way to create a reproducible build every time you build your projects. If you use 3rd party packages directly and the package authors change things, your projects could break. Even if things don't break, code changes could create inconsistent behavior and bugs. Keith Rarick's tool godep is a great step in the right direction for managing 3rd party dependencies and creating reproducible builds. The godep tool gives you two options for managing dependencies. The first option creates a dependency file with version control information and then with some godep magic, the code is built against those versions. You can also Vendor your 3rd party packages inside your projects as well. You never need to change a single source code file and everything is accomplished in conjunction with the go tooling. Downloading Godep Download godep using go get and make sure your $GOPATH/bin directory is in your PATH. go get github.com/kr/godep export PATH=$PATH:$GOPATH/bin Create A Project Build your project using the 3rd party packages as you normally would. Since godep does not require you to change any import paths in the code, 'go get' the code you need and import those packages directly. To keep the post simple, I am going to use an existing program called News Search that uses one 3rd party dependency. export GOPATH=$HOME/example go get github.com/goinggo/newssearch View linked image: Screen Shot