YJL

If you used to (and still) use Subversion, you may not be able to get rid of your muscle memory when you need to check the status of a Git repository. For me, one out of two times, I would type:

git st

It is hardwired in me and Mercurial (Hg) has st as a shortcut, so it gets harder to remember to type the full command when I am using Git.

Git has alias configuration to customize the environment, check out man git-config. You can create a global (meaning for all repositories) alias for status command by typing:

git config --global --add alias.st status

It adds a new entry to global Git configuration file ~/.gitconfig:

[alias]
   st = status

You can manually edit the file if you want. Instead, you can create local alias command which only be used by single repository and configuration is stored in that repository only. But for status command alias, global availability suits better.

ci is a good one to be added for commit command, the second common command for me to get error message from Git, but that's history, too.

If you have used GitHub, you must have already been familiar with gh-pages branch.

I don't like have different code base from the pages branch, so in my projects, master == gh-pages, and many of projects are doing the same. If you have documents like library reference which is generated by source, then you probably will use different base.

For a very long time, I had to do with these commands as follow in order to update that branch:

git checkout gh-pages
git pull . gh-pages
git push
git checkout master

It was just plain silly of me. I did google for it, but not RTFM, I didn't get any useful results, probably used wrong keywords. I finally found the correct answer with correct search keywords, here is the answer:

git push origin master:gh-pages

Here is from manpage git-push:

<refspec>...
    The format of a <refspec> parameter is an optional plus +, followed by the source ref <src>, followed by a colon :,
    followed by the destination ref <dst>. It is used to specify with what <src> object the <dst> ref in the remote
    repository is to be updated.
    [...]
    The <dst> tells which ref on the remote side is updated with this push. Arbitrary expressions cannot be used here, an
    actual ref must be named. If :<dst> is omitted, the same ref as <src> will be updated.

Well, it's all in the manual and I was actually using a shorthand by omitting the <dst>. It's good to know.

So what if you try to omit <src> part? (I am glad I already know about this. Hehe, I am bad!)

git push origin :remote-branch

I created a project on github for mirroring my project on Google Code. I am new to git, so maybe there is a better way to do this.

First clone the Subversion repository and push to the Git:

git svn clone https://foo.googlecode.com/svn/ git-foo
cd git-foo
git remote add git-foo [email protected]:username/foo.git
git push git-foo master

After committing in the Subversion repository, run

cd /path/to/git-foo
git svn fetch
git svn rebase
git push git-foo master

When SXXT happens, it's time to change your password.

How so? Yesterday, I happily committed my code, which is for backing up layout templates for blogs on Blogger.com. After committing done, I saw my Google password when switched back to editor. Anyone who is in normal mental state would loudly yell with "SXXT!" or "FXXK!". I did. I forgot to empty the strings, which have my gmail and password before committed. Actually, I thought I did, because I got prompted for my email and password, therefore I believed that I had emptied two strings. Obviously, I didn't.

The Subversion repository is at Google Code hosting. I deleted the project (sort of making project private) and requested a reset to my repository. Meanwhile, I used svnsync to retrieve all revisions to my computer. After resetted, I tried to sync back without the idiot revision, but I can't get the job done. Later, I manually re-committed the rest of revisions.

From this incident, I have learnt:

• Never allow to put password or other sensitive contents in source, must use a configuration file with secured permission in home directory or similar way if needed
  
• Always check status and diff before committing
• Always grep the diff before committing
• If SXXT still happens, do not reset if there is only one password involved. Changing the password, instead, would be much easier; and removing the SXXT and committing again

Even you can perfectly "rollback", you still can not assure that no one has checked out your SXXT as their juicy fruit or no bots has crawled your SXXT and indexed it.

When SXXT happens, you can appreciate it for reminding you of changing password and the opportunity to have new blog post to share your SXXT mood.