From: Marko Macek <marko.macek@gmx.net>
Date: Fri, 05 Oct 2007 18:16:08 GMT
Subject: Re: Question about "git commit -a"
Message-ID: <47067F68.2080709@gmx.net>
In-Reply-To: <1191599763.7117.18.camel@hinata.boston.redhat.com>


> I understand why people like staging and commit without -a, seeing how
> it's faster and all, but I have a serious problem with this practice
> that I haven't seen brought up on the list.  How do you know what you
> commit actually works or even compiles?  The reason that I almost
> exclusively use -a with commit is that I want to know that what I just
> compiled and tested is what I will be committing.  I don't want to just
> commit half the files in my working copy, I want to make sure that the
> exact state of my project that I just compiled and tested is what gets
> into version controlled history.
> 
> git commit -a isn't sloppy to me - eye balling some subset of your
> working copy and committing that under the assumption that you don't
> make mistakes and don't need to compile what you commit... that is
> sloppy.

Agreed. For this reason git-commit without -a, staging, index, ... is
not really interesting to me.

In CVS and subversion (which has nicer working-copy command line interface IMHO),
I simply make a copy of the working copy, revert the non-commitable parts, build,
commit the minor changes, and then update the first copy. For larger projects,
where this can be slow, I use diff/revert/patch.

Small checkins are nice for git-bisect, but if they don't build...

Mark