Re: Consistent terminology: cached/staged/index

Felipe Contreras venit, vidit, dixit 14.02.2011 15:17:

On Mon, Feb 14, 2011 at 3:43 PM, Michael J Gruber
[off-list ref] wrote:

quoted

Nguyen Thai Ngoc Duy venit, vidit, dixit 14.02.2011 14:14:

quoted

On Mon, Feb 14, 2011 at 5:42 PM, Michael J Gruber
[off-list ref] wrote:

quoted

Full disclaimer: I have an alias "staged" for "diff --cached" myself...

Be careful with your fingers. There's a command named "git stage".

I know. Can we remove it as part of 1.8.0? It's our only builtin alias.

I have proposed before to extend 'git stage', so you can do 'git stage
diff', or if you alias 'git stage' to 'git s', just 'git s diff'. This
would not conflict with the old behavior of 'git stage $file'.

case "$1" in
add)
        shift
        git add $@
        ;;
rm)
        shift
        git rm --cached $@
        ;;
diff)
        shift
        git diff --cached $@
        ;;
import)
        shift
        git ls-files --modified --others --exclude-standard -z $@ | \
        git update-index --add --remove -z --stdin
        ;;
ls)
        shift
        git ls-files --stage $@
        ;;
*)
        git add $@
        ;;
esac

Cheers.

In principle I like this a lot: a set of commands operating on/with the
stage/index/cache consistently. It think it's similar in (good) spirit
to our earlier attempts at INDEX and WORKTREE pseudo-revs, trying to
give that somewhat nebulous (for noobs) index a more concrete
"appearance", not hidden away in options (--index, --cached) and
defaults (diff against index by default).

In our case, however, I think the design principle deviates from our
common form:

git foo bar

usually means "do foo" to "bar", as most of our common commands are
verbs (being applied to the object "bar"). When it comes to subcommands
we do have inconsistencies already (double-dashed vs. undashed, e.g.),
but I'd prefer fewer ;)

Michael