
Slightly More Advanced Git techniques - fogus
http://cmurphycode.posterous.com/git-201-slightly-more-advanced
======
samstokes

        $ git bisect start
        $ git bisect good <sha>
        $ git bisect bad master
        git will do all the hard work for you. You just have to run your tests at each point that git prompts you, and tell it whether it passed or not:
        $ git bisect bad (or good)
    

Props to the author for describing 'git bisect', which is a big time saver;
but I'm always surprised that articles like this don't go on to mention the
even more amazing 'git bisect run', which _automates_ the "run your tests at
each point and tell it whether it passed" part:

    
    
        $ git bisect start
        $ git bisect good <sha>
        $ git bisect bad master
        $ git bisect run rspec spec/path/to/failing_spec.rb
        ... wait a bit ...
        5243cafebabe is the last bad commit
    

You can give it any shell command, and it'll automatically bisect, run the
command, mark the current commit as good or bad depending on the shell return
code of the command, then bisect again, etc.

It's right there in the man page, but for some reason seems to be little known
(or at least talked about).

~~~
muhuk
I suppose automating this is not too difficult. Something like:

    
    
        $ git bisect start --good <sha> --run rspec spec/path/to/failing_spec.rb
        ... wait longer ...
        5243cafebabe is the last bad commit

------
davvid
I love git grep:

    
    
        $ git grep foo
    

It's often faster than running regular grep and does nice things like not
inspecting ignored files.

I also find myself using git shortlog when preparing releases. e.g.:

    
    
        $ git shortlog v1.6.2..
    

...and it shows me a nice summary of changes since the "v1.6.2" tag.

"git diff --color-words" and "git difftool" are pretty awesome too.

I wouldn't consider these advanced but they are lesser-known.

------
rwmj
Latest awesome git feature I found:
[http://www.kernel.org/pub/software/scm/git/docs/git-
notes.ht...](http://www.kernel.org/pub/software/scm/git/docs/git-notes.html)

I'm using git notes to annotate my commits with metadata about what bugs they
fix, how stable they've proven to be in practice, and the dependencies between
commits: [https://rwmj.wordpress.com/2011/03/28/half-baked-ideas-
class...](https://rwmj.wordpress.com/2011/03/28/half-baked-ideas-classify-git-
commits-and-rule-based-branch-building/)

~~~
drothlis
Last time I looked into 'git notes' it wouldn't preserve the notes attached to
a commit when you amend / rebase / cherry-pick the commit. It seems that git
now supports this! From the git-notes manpage:

    
    
      notes.rewrite.<command>
        When rewriting commits with <command> (currently amend or rebase),
        if this variable is false, git will not copy notes from the original
        to the rewritten commit. Defaults to true.

------
eapen
The "Filter-Branch" tip was the most helpful tip for me, since I've been there
and deleted my whole repo as quickly as possible not knowing other solutions
existed.

<http://help.github.com/removing-sensitive-data/>

