DESCRIPTION

These are small Git extension scripts I keep in ~/bin/ and have on my path. Some could be in ~/.gitconfig section [alias].

The short and obvious commands

git br

git branch <args>, or list branches

git ci

git commit <args>

git ci^

git commit --amend -CHEAD <args>

Also works with -e flag to edit the message.

git co

git checkout <args>

git ff

git merge --ff-only <args>

git g

git gui &

git k

Basically gitk --all HEAD &

git gk [ <workdir> ]

git g; git k, optionally preceded by cd <workdir>. This is the main tool I use when starting work in a project.

git iec

Create standard "initial empty commit". This is the first thing I run after git init foo; cd foo.

git s

git status (...color...) --ignored --short --branch -u <args>

git st

git status <args>

Longer or more complex commands

git-P

git --no-pager <args>

git commit-retro

Commit, making (Author, AuthorDate) from file stat. Requires some config to deal with other users.

git ireb

git rebase -i --autosquash ...of whatever is not pushed

git log1

Details of last commit.

git logG

Textual graph of commits.

git rebase-topswap

Swap HEAD and HEAD^ using git rebase -i.

git rhH

git rhH ^

git reset --hard HEAD, git reset --hard HEAD^

Scary command! Only installs with ./install.sh -yS ...

git up

git pull --rebase <args>

For those who use the linearised history, first-push-wins model.

git ll-cpanm, git ll-init

Install CPAN (Perl5) libraries, into a local::lib directory under Git control.

Tools for scripts

git compilation-annotate

# "show me what's wrong with code written in the last 30 days"
perlcritic --quiet --nocolour --verbose "%f:%l:%c:%m\t[%s] %p\n" \
   modules t/modules | git-compilation-annotate -n 30

git enumerate-commits

List all commits in the repository, e.g.

git-enumerate-repos | git for-each-repo  git enumerate-commits > ci-dump

git enumerate-repos

Search a directory tree for bare or checkout Git repositories.

Optionally, fingerprint the commit tree to work out what the repository is without relying on the directory name.

git for-each-repo

Run a command in each of the enumerated repositories.

git gc-du

git gc(1) gated by du(1) of non-packed objects, for auto-cleanup.

git head

What's the current branch name, or HEAD commitid?

git qcommit

Commit noisily, or keep quiet if nothing to commit

git qpull

Pull noisily, or keep quiet if nothing is new

Tools for hooks

git rehash

For when SHA1 isn't strong enough.

See also https://github.com/mcast/git-stronghash .

git which-me

Which of my many email addresses am I using here?

Incomplete or forgotten

Some tools looked like a good idea, or solved part of some transient problem, or might be useful when completed.

git-permsfix
git-permsfix-shared-clone
git-proxy-squid
git-subtree-branch
git-undzil
mr-unconfigured-search

INSTALLATION

"Throw them in the ~/bin"

The current plan is to "install" them via symlinks, ln -snvf ../../../gitwk-github/scripts/bin/{git-rebase-topswap,pidfzap} ~/bin/

You must put that ~/bin on $PATH yourself.

Running the supplied script with

./install -y ~/bin

will do this for you, in the way I currently prefer.

The scary scripts

Some scripts are too destructive to leave lying around on your PATH if you don't know the name. These may be installed, as a separate set, with

./install -yS ~/bin

Details

For "installation" of multiple scripts from some source repositories, I prefer to symlink a parent directory and then symlink various scripts through that, so

,git-yacontrib -> $HOME/gitwk-ext/git-yacontrib/bin
git-k -> ,git-yacontrib/git-k
git-st -> ,git-yacontrib/git-st
 ...

so it's obvious which remaining files (presumably saved straight from editor to ~/bin) ought to be put in version control.

The set of files installed is defined by install*.txt.

MAINTENANCE

They are only maintained to the extent that I'm still using them. You're welcome to fork on Github or by other means, and I would aim to merge contributions as time allows.

PLANS & IDEAS

Vapourware.

git backup-stash

Something to generate a commit which could usefully be included in a backup, to record more about the repo state, referencing some or all of

• all stashes in the reflog

  Note that stashes recorded in the reflog are not expired, since v1.5.6.6 but they aren't going to leave the local repository by an ordinary push or fetch.

• other extant commitids from reflogs

  This would allow recovery of not-yet-garbage-collected commits, from commitid-based repository backups. Possibly neat, but unlikely to be useful?

• comment or extra file containing the reflog and head stash ref

• some of .git/config and related files?

• Untracked files. Call it a tristash (staged, unstaged, untracked)

  Use another index? Define size limits?

  Ignored files? What about files to exclude for security reasons?

• a tar of some .git/ internals

  logs/
  hooks/
  config
  info/exclude
  info/grafts
  COMMIT_EDITMSG
  GITGUI_BCK
  description
  objects/info/alternates
  
  git-svn state
  gitweb config
  
  hardlink counts & inode info for packfiles
     In combination with related matching backups could be used to
     reconstruct the hardlinked arrangement.  If you were desperate.

  Many of these are things you wouldn't want to just restore.

It will look like a huge merge (but isn't).

Related possibly useful things,

• operations to reverse these back into reflog & stash, or extract any one to become the current stash

• something that makes this tree clearly not part of the project.

  Empty, except for a shell script to help with the restoration?

Naming

git stashbranch
git stash-branch
git backup-stashes
git _backup-stashes # we may assume it is called from cron, so avoid eating namespace?

git do-sync

(Have already implemented part of this as a tool inside my reminders textfile repo.)

commit (staged, changed, autosaved) files
at both ends
then (pull --rebase; push; remote ff) or similar

Configurable for rebase vs. merge, to allow for more than a pair of repos.

git-wstash

"with a git stash, do"

#! /bin/sh

set -e
set -x

git stash save "with stash: $@"
"$@"
git stash pop

# This would seem to need some extra safeguards,
#
#   if nothing to stash, just do command; else we pop an older stash!

Something to install Git hooks and chains of hooks

Hook chaining seems (to my searches of 2016-05) to have standardised on http://stackoverflow.com/a/8734391|.git/hooks/hook-chain as a lightweight mechanism to run multiple Git hooks in a repository, often copied from https://gist.github.com/abner/cdddf155c919ff37bc9a .

On installing hooks easily (but not completely automatically for security reasons), projects still seem to roll their own. http://stackoverflow.com/questions/3462955/putting-git-hooks-into-repository

Git::Hooks exists as a heavier and more Perl-centric mechanism. That doesn't appeal to me just now - I see @ARGV, stdio, $? as a higher standard than any one language.

https://github.com/SC5/githooks is going in this direction, but still a placeholder (like this here) so far.

What would be useful?

Starting https://github.com/mcast/git-hookchains from https://gist.github.com/mcast/77eb93ecda8aa4e6d410e8b6ea58a6a7 based on https://gist.github.com/abner/cdddf155c919ff37bc9a.

• Install the hooks into a clone or bare repo.

  From that project or another repository; copying the hooks as they might be audited now, or trusting pulls from the unknown future, or supplying a mechanism to check for updates and notify; recording the source branch and commitid where appropriate.

• Install similarly chosen configuration items to .git/config

  This carries equivalent security risk to installing hooks. Let's keep them together for the potential convenience and shared headspace.

• Standard naming for sub-hooks.

  The naming scheme .git/hooks/pre-commit-001-check-my-style is clear and functional so I would use that.

• Matching configuration naming for sub-hooks.

  Naming to allow subhooks to be given to the hook-chain by something like git config hook-config.pre-commit-001-check-my-style laconic can supply data to that script.

• git-config virtual sub-hooks?

  Where the subhook is implemented as a git-foo subcommand, there is no need to make a symlink to a shell script which calls that command.

  git config subhook.pre-push-001-pushban "git _pushban --verbose"

  can be equivalent to

  echo -e "#!/bin/sh\nexec git _pushban --verbose" > .git/hooks/pre-push-001-pushban
  chmod a+x .git/hooks/pre-push-001-pushban

  if the hook-chain script will honour that.

SEE ALSO

https://metacpan.org/module/App::IsGitSynced

https://github.com/aspiers/git-config

Github tools

https://github.com/github/hub App::GitHubPullRequest

(via http://www.dagolden.com/index.php/2065/how-ive-started-managing-github-pulls/)

AUTHOR

I have written them in the course of my work for http://www.sanger.ac.uk/ and for personal use.

The project "mcast/git-yacontrib" is released under GPLv2 or later, per local policy.

(I realise this is far to vague to form a reliable declaration of "release under GPLv2" except where explicit but marking for release takes time, and it's probably better to make the thing visible and wait for someone to ask for clarification.)