Tagged “git”

simple cms to edit static sites. Project seems relatively mature, admin UI is very basic but does the job.

git stash save has been deprecated. Instead you use git stash push, which is nothing at all like git push. kind of makes sense but come on, git.

Also good examples from stack overflow:

• git stash list
• git stash pop stash@{n} - apply stash by number, then drop it
• git stash apply stash^{/named-stash} - apply means keep the stash

One step to squash a branch into a single commit.

Instead of using rebase (confusing and weird sometimes) it makes a temporary branch with your then merges that with merge --squash.

To add custom git command, saving this as git-ez-squash (or git-whatever) in a folder somewhere in your PATH.

#!/usr/bin/env bash
set -e

DEFAULT_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD | sed 's@^refs/remotes/origin/@@')
TEMP_BRANCH="temp-$(date +%s)"
CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD)

# check for uncommitted changes
if [[ -n $(git status --porcelain) ]]; then
    echo "Error: There are uncommitted changes on the current branch."
    exit 1
fi

git fetch origin "$DEFAULT_BRANCH"
git merge --no-ff --no-edit "$DEFAULT_BRANCH"

git checkout -b "$TEMP_BRANCH"

git branch -D "$CURRENT_BRANCH"
git checkout origin/"$DEFAULT_BRANCH"
git checkout -b "$CURRENT_BRANCH"

git merge --squash "$TEMP_BRANCH"
git commit

git branch -D "$TEMP_BRANCH"

Note that during git rebase and git pull --rebase, ours and theirs may appear swapped; --ours gives the version from the branch the changes are rebased onto, while –theirs gives the version from the branch that holds your work that is being rebased.

git is so stupid sometimes

testing

Generally agree. Mainly tracking file creation/history gets a bit annoying (especially when files are moved/renamed/split up). But most of the time I don’t think it particularly matters.

Also some good tips like ingorerevs in hackernews comments.

An insanely sensible idea! Some choice quotes in the intro illustrate the problem (and a common one with git…):

Git is a version control system with robust underlying principles, and yet, novice users are terrified of it. When they make a mistake, many would rather delete and re-clone the repository than try to fix it.

Why? How is it so easy to “lose” your data in a system that’s supposed to never lose your data?

Well, it’s not that it’s too easy to lose your data — but rather, that it’s too difficult to recover it.

Sorry for rushing this a bit, but got home yet?

Wanted to remove a bunch of old/unused binary files that were bloating a repo.

Refreshingly professional. My usual favourite commits are either Developers Swearing or awful puns.

There is often a lot of talk around how important it is to squash your commits, or to rebase your work into logical commits. These are not terrible ideas. Reading through the commit history of a project with tastefully crafted atomic commits makes for a fun afternoon. But I don’t think it is as important as it is made out to be. That was a lot of two-letter words in one sentence.

In real-life code often you might want to do things like “remove this wrapper function from modules”. Or “run lint --fix and commit the result”. But at the risk of ruining the commit history we don’t do it. And the inconsistencies keep going and growing. These types of commits always exist though. From the “burn down the codebase and start again” type initial commit, “convert all tabs/spaces to spaces/tabs”.

If there is benefit in doing this (there often is), I don’t think keeping git history clean is a valid counter argument. Ideally, tools should be able to ignore these commits. Maybe a [fix-lint] commit message or something, to signal that it should be skipped from blame/log exploration. Or always ignore insignificant whitespace. I don’t know of any tools that do this currently, but it seems more useful finding a way to do this than wallowing in the gross inconsistencies of your current codebase.

And ultimately, HEAD is the only commit most people are going to see anyway. You read current code more than a complete history of your code.