> I understand why people like staging and commit without -a, seeing how
quoted text
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html