The H2 Wiki


A Git survival guide

Roughly orthogonal git commands

(or -N) I don’t use git add because it adds the file to the staging area. I don’t want to bother with the staging area (see below for more details).

and it is useful to use --word-diff or --ignore-whitespace.

or to be really specific about it

git rebase -i --onto <target> <from> <to>

The latter will interactively rebase the collection of patches <from>..<to> onto <target> (<from> is exclusive, <to> inclusive). It’s always a reasonable idea to rebase interactively so at least you can see the list of commits that will be rebased. It might turn out you got some of the arguments wrong and then you can bail out early.

If you only want to see the topology of the tree instead of every commit then add --simplify-by-decoration. (You might like to read Ian Miell’s “git log – The Good Parts”.)

Things I don’t do

and if I want to bring my branch up to date with the remote then I do

git rebase <remote>/<branch>

Advanced stuff

All the things your branch has ever been

Are you scared that you’ve lost commits because of a rebase gone wrong or some other git mystery? Try this command with the name of your branch in the place of <branch>.

BRANCH=<branch>; git log --graph --pretty=format:"%C(yellow)%h%Creset %cr: %s%d (Authored %ar)"   `git reflog $BRANCH | cut '-d ' -f1`

(Yes, it’s long, and you should put it all on one line). You will be presented with a tree that contains everything that has even been on the given branch. You can then reset your branch to one of its earlier versions and perhaps cherry-pick into it commits from other versions.

Explicit git

What a rebase/merge is

TODO: explain how conflicts mean you have to merge the semantic content of both patches

Darcs translation