Re: git default behavior seems odd from a Unix command line point of view

From: Junio C Hamano <gitster@pobox.com>
Date: May 12, 2009, 16:12 UTC
Message-ID: <7vd4ae8fls.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4e963a650905120818m70b75892gb4e052187910b9a5@mail.gmail.com>

Andrew Schein <andrew@andrewschein.com> writes:

> ais@ace:bio$ git status
> # On branch master
> nothing to commit (working directory clean)
> ais@ace:bio[1]$ git commit -a

This is merely a historical accident that you cannot change. "git status" was originally a dual-purpose implementation detail of "git commit" command to:

 (1) report if there is anything you can commit with its exit code; and

 (2) if there is something to be committed, show what will and what won't
     be committed.

For the purpose of (1), the calling command "commit" was told by the user to make a commit, so the situation where there is nothing to commit was signalled as an error. The code conceptually looked like:

	(git-commit.sh)

	do the preparation
	if git-status
        then
        	# message "there is nothing to commit" already given
		revert the preparation
                exit 1
	fi
        really make a commit

These days, "git commit" has been rewritten and the logic to see if there is anything to commit is built-in, but people still use "git status" primarily for purpose (2), the listing of what's committed and what's left.

Oh, and your example is wrong. If you are going to commit with -a, and if you want to see if such a "git commit" has actually something to commit, then you should be giving -a to status as well, like:

	git status -a && git commit -a

Also, unless you ask explicitly, "git commit" will not make an empty commit, so you can always omit the "git status -a &&" part and have "git commit" itself do the checking.