git

For me git replaced CVS, after a bad run-in with Subversion, which had managed to wedge a repository and eat my files. That was back before Subversion went to a filesystem based database, and git came along soon after. Since a sysadmin needs to support what folks use, and folks used git, here we are. There are other version control systems worth considering; some like fossil technology.

Internal details might best be learned from cloning

https://github.com/jwiegley/git-from-the-bottom-up

and the "Pro Git" book may also be worth working through to some degree.

    [core]
      editor = ex

I used to have the editor as ed, but that lacks some nifty things that ex has, like filters. Using ed or ex as your editor keeps you in practice with them, which a sysadmin may need to know how to use on a troubled system. Merges can be a bit fun.

Aliases

Aliases can get you in trouble, but on the other hand might save typing?

[alias]
  aa = add -A
  amend = "!git add -A; git commit --amend --no-edit --date=now"
  cdiff = diff --cached
  co = checkout
  di = diff
  last = log --abbrev-commit --stat -1 HEAD
  last-diff = log --cc -1 HEAD
  log-diff = log --cc
  master-diff = diff master..
  master-log = log --abbrev-commit --stat master..
  mod = ls-files -m
  mush = rebase -i --ignore-date
  pull = pull -q
  scommit = commit -S94F3B660002CF5BFE994A2C4B3596F5C4FEBC8A7
  sign = tag -u 94F3B660002CF5BFE994A2C4B3596F5C4FEBC8A7 -s
  st = status -sb

• amend - for when you forget something right after a commit (but before you have pushed anything!) and want to include something else in the previous commit.
• last* - these show details about the last commit.
• mush - sometimes I'll hack away on a branch and then want to "mush" all those commits into a single commit at the time when the rebase was done, and not when the branch was started.
• scommit, sign - PGP key to use when signing tags or commits.

The "mod" alias I do not use much, mostly because of the "m" script to show what is modified in git or CVS or if those fail what recently modified files there are in the directory.

    #!/bin/sh
    git rev-parse --git-dir 1>/dev/null 2>/dev/null && exec git status -sb
    findup -H -q CVS && exec cvs up
    pwd
    exec recent

Backups

The git repositories get pushed over to a virt which does provide for a backup, assuming the virt survives and can be gotten to should the main laptop fail. (Backups are also done with restic to other places.) A lot of this is bundled up in a "repod" (repository duplicate) script that hides the following details.

Remote Setup

Set the default branch name to avoid warnings, disable the default hooks from appearing everywhere.

    git config --global init.defaultBranch master
    git config --global init.templatedir /var/empty

Repository Setup

Repositories can either be published or placed elsewhere. I have a boolean to control that, though there's no good way to switch a repository from one location to another.

    [alias]
      publish = "config --local --type=bool ckaji.publish true"

The "repod" script detects this flag; if set, the repository is created under /var/www/htdocs/src, otherwise placed in a not so public directory. The published repositories also set a post-update hook.

    $ git publish
    $ repod init foo
    $ git push foo master

The "repod init foo" works out to something like:

    $ grep -1 foo ~/.ssh/config
    
    Host foo.example.org foo
      Hostname 192.0.2.42
    $ ssh foo
    ...
    foo$ dir=/var/www/htdocs/src/bar.git
    foo$ mkdir -p "$dir"/hooks
    foo$ git init --bare "$dir"
    foo$ echo exec git update-server-info > "$dir"/hooks/post-update
    foo$ chmod +x "$dir"/hooks/post-update
    foo$ exit
    ...
    $ git remote add foo ssh://foo/var/www/htdocs/src/bar.git
    $ git push foo master

only with a lot less typing and less room for error and the ability to "set-url" instead of "add" if the remote URL changes.

My local repositories that need to be pushed have post-commit and post-merge hook scripts that write the repository to a ~/.gupdates file; another script, "pushall" works through repositories listed there and pushes them to where they need to go, as otherwise I would likely forget to push something after commits.

Your workflow is probably different so will probably need different tools.

If folks want a repository they can clone it; I'm not much into something complicated like cgit or even a static render of the repository, but software exists for that if you want it? Haven't used the following, but they have been mentioned on an OpenBSD IRC channel, for better or worse.

a static git page generator

hyperfast web frontend for git

Branches

Don't use 'em much, but it might be nice to have a script to make them?

    #!/bin/sh
    # newbranch - make a new git branch
    exec git checkout -b "${1:-b`date +%s`}"

I typically have a "mods" branch for my forks of amfora or w3m, but elsewhere it's mostly hacking away at that one branch. Folks who do collaboration will doubtless need a better plan. `git rebase master` and then muddling through any conflicts does not come up much.

Other

gemini://mediocregopher.com/posts/git-proxy.gmi