Re: 2 questions/nits about commit and config

From: Junio C Hamano <junkio@cox.net>
Date: Feb 4, 2006, 22:13 UTC
Message-ID: <7voe1mvkls.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060204212337.GA8612@blinkenlights.visv.net>

Michael Fischer <michael@visv.net> writes:

> 1) git commit -m"this is a commit message"  doesn't work. 
>    It has to have a space between -m and the first '"'.

Well that is a minor inconvenience and would be trivial to accomodate, but please do not send patches in yet. I do not know if you have been following the list discussion, but it seems very likely that we will update the way git-commit command works slightly in other semantic aspects and I do not want to worry about trivialities. Duly noted and I'll try to remember that command line parsing issue when we do a rewrite.

> 2) I can descend into subdirectories in my project, and 
>    git diff, git status both work fine, but git commit
>    gets annoyed..

This is more or less deliberate, and I personally do not have a strong reason to change it (except perhaps making the error message a bit more helpful) even when we do a rewrite.

Unlike CVS that does version control per file basis, commit in git is really about the whole tree state, so even if we changed 'git commit' to work from subdirectories that would commit everything, which would probably be more confusing. That is, until somebody comes up with a good semantics and rationale why allowing that semantics is a good change and the code to do so.

An example of such semantic change would be: if I am in subdirecotry foo/, commit changes to files in that subdirectory and subdirectory alone. But that is actively _encouraging_ partial commits (commits that records a state that never existed in your working tree as a whole) so I personally am not so enthused to buy such a _feature_.