Re: git-diff on touched files: bug or feature?

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 3, 2007, 07:59 UTC
Message-ID: <7vr6mlnj4g.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20070803070407.GA17287@coredump.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 10 quoted lines

> On Thu, Aug 02, 2007 at 12:56:19PM -0700, Junio C Hamano wrote:
>
>> Personally, I almost never run "git status".  The command is
>> there primarily because other systems had a command called
>> "status", and migrant wondered why we didn't.  We do not need
>> it, and we do not have to use it.
>
> So what is the recommended command to summarize which files have been
> modified, which files have been marked for commit, and which remain
> untracked?

Ok, you got me. If I need such a summary, git-status would obviously be the choice. Although I do admit that I added the interactive commit to support people who want to keep 30 hunks across 10 different files in the working tree, and make a commit using only 3 of them, I do not make partial commits myself, so distinction between staged and unstaged are not something I am usually interested in. If your workflow care about that distinction, and that is a very valid and natural workflow in git, you would find git-status and git-diff --cached more useful than they are to me. I should not used words such as optimum. It is just "different".

When you think about it, in such a workflow whose work tree that does not match commits created from it, it is not very useful to know the "touched but ended up unmodified", because (1) the worktree changes are full of not-yet-ready changes (to the immediate commit you are going to create) anyway, and (2) the "touched but not modified" files may further be modified and become modified before their changes hit a (later) commit. The side effect that "git-status" loses that information suddenly becomes a useful feature for such a workflow.

On the other hand, if your workflow is "work on one thing at a time, and never make partial commits", then your diff tends to be small and more focused to begin with, and you can afford to care about "touched but ended up unmodified". Interestingly, it happens to be a useful correlation that "git status", which clears such information, is less useful command for such a workflow.