img/SLyES-2012.gif

GIT for mortals

System Message: WARNING/2 (data/git-for-mortals-cheat-sheet.txt, line 21)

Bullet list ends without a blank line; unexpected unindent.

System Message: WARNING/2 (data/git-for-mortals-cheat-sheet.txt, line 22)

Bullet list ends without a blank line; unexpected unindent.

System Message: WARNING/2 (data/git-for-mortals-cheat-sheet.txt, line 31)

Bullet list ends without a blank line; unexpected unindent.

http://lists.freedesktop.org/archives/cairo/2006-February/006335.html

System Message: WARNING/2 (data/git-for-mortals-cheat-sheet.txt, line 38)

Bullet list ends without a blank line; unexpected unindent.

http://git.or.cz/gitwiki/GitTips#head-1cdd4ab777e74f12d1ffa7f0a793e46dd06e5945

  • Linus talks about Git's history:

System Message: WARNING/2 (data/git-for-mortals-cheat-sheet.txt, line 41)

Bullet list ends without a blank line; unexpected unindent.

http://git.or.cz/gitwiki/GitHistory Don't read it at the beginning. You'll understand it better later, when you have an inkling of what the index and the DAG are about.

  • SVN author on 80% of programmers: http://blog.red-bean.com/sussman/?p=79

  • Public hosting: http://repo.or.cz

  • Bad docs:

    http://www.jdl.com/papers/Embrace_The_Git_Index.html - doesn't tell me what the index is good for (explains very clearly how add / commit work the index, but doesn't give me a useful use case). (linked from http://www.jdl.com/)

    It says at the very end, "More can be learned about merging and the internal workins of the Index itself by reading the git-read-tree and git-diff-tree documentation." But those docs are very technical! They look like a description of algorithms (which I don't care about), not about useful use cases.

  • http://git.rsbx.net/Documents/Git_Data_Formats.txt

  • Get git

    git clone git://git.kernel.org/pub/scm/git/git.git cd git git checkout -b new v1.5.2 make make install

    The tutorials lie if you use 1.4.x!

  • Set up your own project.

    ~/src$ cd myproject [trim unwanted, generated files] ~/src/myproject git init ~/src/myproject git add . ~/src/myproject git commit -m "Initial import of my project" [Digression on $EDITOR variable]

  • Make your repo available to outsiders.

    • How to do this?

    • If git is available in the web server:

      ssh www.example.com cd public_html mkdir git cd git mkdir myproject.git GIT_DIR=myproject.git git-init-db touch myproject.git/git-daemon-export-ok emacs myproject.git/description chmod +x myproject.git/hooks/post-update

      System Message: ERROR/3 (data/git-for-mortals-cheat-sheet.txt, line 97)

      Unexpected indentation.

      http://www.kernel.org/pub/software/scm/git/docs/hooks.html

      If you just want to push your master branch:

      git push ssh://www.example.com/~username/public_html/git/myproject.git master

      (or substitute "master" for the branch you want to push. This will create a branch in the remote repository with the same name)

      If you want to push a local branch with a different name in the remote:

      git push ssh://www.example.com/~username/public_html/git/myproject.git localname:refs/heads/differentname

      Elsewhere:

      git clone http://www.example.com/~username/git/myproject.git

      See below, "If you want something other than the remote "master" branch" if you want to work on a branch that the remote published, but that is not their master branch.

    • If git is not available on the web server:

      git clone --bare . /tmp/myproject.git git --bare --git-dir=/tmp/myproject.git update-server-info chmod +x /tmp/myproject.git/hooks/post-update scp -r /tmp/myproject.git www.example.com:~/public_html/git/

    • Make a branch:

      git checkout -b mybranch

    • If you want something other than the remote "master" branch:

      git clone http://www.example.com/~username/git/repo-name cd repo-name git fetch git checkout --track -b mybranch origin/remote-branch-name

      With this, "git pull" will automatically fetch and merge changes from the remote branch. If you don't use --track, "git pull" will just fetch the changes into the mirror of the remote branch (origin/remote-branch-name), but not merge them into your working copy.

    • Once you are done with your changes, prepare a patch set:

      git-format-patch master -> will spit one of 00xx-blahblah.patch for every commit

    • Preparing an easily-readable patch set:

      • git-format-patch will give you sequential patches based on your commits, but this is not always ideal since you were experimenting.

      • Create a new branch, "prepare-for-upstream"

      • How to cherry-pick everything into your new branch?

        • git-format-patch in the original branch
        • Apply the patches by hand (ugh!)
        • Commit in order
        • (13:03:50) gitte: federico1: did you try git-gui? (13:04:19) gitte: federico1: I would do this: "git cherry-pick -n <commit>; git gui".

      • How to ensure that in the end the new branch has all the patches from your original branch?

        • Just a git-diff or manual diff?

    • Upstream can then do this:

      git checkout -b merge-johnnys-changes git pull git://johnny.com/git/project johnnys-branchname <check that everything is okay> git checkout master git merge merge-johnnys-changes

    • http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#the-workflow

    • http://www.freedesktop.org/wiki/Infrastructure/git/RepositoryAdmin

    • http://wiki.u32.net/index.php?title=Git/publishing

    • http://wiki.u32.net/Git

    • http://www.kernel.org/pub/software/scm/git/docs/howto/setup-git-server-over-http.txt Git over http, plenty of configuration needed in Apache.

  • Good practices: keep your work repo in your laptop; keep a public repo in another server which will also function as your backup (laptop's hard drive crashes!).

  • git add --interactive (prompts for which hunks to apply).

  • git rebase --interactive -

System Message: WARNING/2 (data/git-for-mortals-cheat-sheet.txt, line 192)

Bullet list ends without a blank line; unexpected unindent.

http://blog.madism.org/index.php/2007/09/09/138-git-awsome-ness-git-rebase-interactive

  • View all branches: gitk --all

  • Subversion:

  • cherry-pick:

    (12:56:21 PM) federico: robtaylor: how do you use cherry-pick? (12:57:05 PM) robtaylor: federico: git log <dev branch>, get patch id, git-cherry-pick -n patchid (12:57:09 PM) robtaylor: repeat (12:57:15 PM) robtaylor: git commit

  • Incorrect / incomplete / inconsistent / ambiguous docs:

    http://www.freedesktop.org/wiki/Infrastructure/git/Users - section "Checking out a repository" mentions "git checkout branchname", but that won't give you a remote branch.

    http://www.freedesktop.org/wiki/Infrastructure/git/Developers in the section "Working on branches" mentions how to edit your .git/remotes/origin (doesn't exist by default! should the user just create it?). It mentions adding a bunch of stuff to that file so that you can push/pull easily.

    http://www.freedesktop.org/wiki/Infrastructure/git/RepositoryAdmin in the section "Personal repositories" suggests "git push --force --all URL". Why do we need --force --all to get started?

  • git pull origin branchname:branchname "Pull from the origin, from their branchname, into my branchname" - otherwise it will pull from the origin's master. (see http://www.freedesktop.org/wiki/Infrastructure/git/Users)

  • Tidbits:

    "When you diff, commit, etc. code, you are doing it against your local repository. Clone, pull, and push are used to move changes between repositories." - from http://www.freedesktop.org/wiki/Infrastructure/git/Developers

    http://www.freedesktop.org/wiki/Infrastructure/git/Developers mentions "Getting the latest upstream code", and the difference between "git pull" (does fetch-and-merge, useful when you haven't made changes), and "git fetch / git rebase" (useful when you have made changes, so your commit history doesn't get a merge in the middle).

    http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws --- really nice collection of stupidities in git's UI.

  • Nice things about Git:

    • Setting up a mediawiki, patching it with funny extensions.
    • Create a git repo right there - no "import", no "re-checkout", etc.
    • Extension requires patches - patch, small-commit.
    • My own fixes - small fix, commit.