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.
-
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
