[plt-dev] git wackiness

From: Eli Barzilay (eli at barzilay.org)
Date: Wed Apr 21 00:09:05 EDT 2010

On Apr 20, Eli Barzilay wrote:
> On Apr 20, Jay McCarthy wrote:
> > 
> > I thought "git add" meant "reminder this file to include in the next
> > commit". However, that's wrong:
> > [...]
> 
> Executive summary:
> 
>   `svn commit'          ~  `git commit .'
> 
>   `svn commit path...'  ~  `git commit path...'

Three more things, and no executive summary (=> so please read):

1. Save the following in a file called "git-ci" that is somewhere in
   your path; remember to "chmod +x git-ci".  You will then be able to
   use `git ci' in a way that looks to me like it's doing almost
   exactly what `svn ci' does.

-------------------------------------------------------------------------------
#!/bin/sh
seen_path=no; for p; do if [ -e "$p" ]; then seen_path=yes; fi; done
if [ $seen_path = yes ]; then git commit "$@"; else git commit . "$@"; fi
-------------------------------------------------------------------------------

2. When you commit without a `-m "message"', the editor that will be
   opened for you to edit the commit message will have the list of
   files that are going to be committed, and the list of modified
   files that are not going to be committed.  It even mentions that
   you should use `git add' to add those things.  So at least at the
   getting-used-to-it stage, it might be a good idea to avoid `-m'
   commits.

3. After you commit (especially if you used `-m'), check out the
   changes that you just committed.  If there's stuff that you didn't
   intend to include there -- there's no need to do more commits to
   fix it.  Instead, you can run

     get reset HEAD^

   This will *undo* your last commit from your repository, but leave
   the modified files in your working tree -- so you're essentially
   back to the point before committing, and you can now re-run `git
   commit' differently.

   Note that undoing commits is a form of history rewriting -- you
   should not do that if you pushed your commit to the server.  (You
   could try to do it, but next time you push, the server will barf at
   you and will not let you push.)  So together with "commit often",
   another good habit to acquire is to *not* push often.
   Specifically, blindly pushing right after you commit is not a good
   idea, since mistakes are permanentized (and resolutions are in the
   same form of "oops" commits that svn suffers from).

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!


Posted on the dev mailing list.