Re: [RFC/PATCH] git put: an alternative to add/reset/checkout

On Mon, Jan 23, 2012 at 8:53 PM, Michael Nahas [off-list ref] wrote:

"git put" is "git cp".  It copies from one filesystem (or a snapshot
of a filesystem) to another filesystem.

Exactly.

Without multiple working directories, a modifiable "stash", or a
(useful) name for the filesystem referred to as
"index"/"cache"/"staging area", there is only one filesystem that the
command can write to: the (singular) working directory.

No there are two writable "filesystems": working directory and
"index/cache/staging area"

So, "git put <src filesystem> -- <path>" is fine.  It will copy from
the path in the src filesystem to the path in the current working
directory.  I don't think the command "put" is a great name for that.
Since we already have some strange double-usage commands like "git
checkout --" and "git reset --", perhaps this should be "git
cherry-pick --".

The "-- <path>" thing may save you a few keystrokes when you want to
copy from more than one path(spec). The two below commands are
equivalent

git put HEAD:a/ HEAD/b/ HEAD/c/ .
git put HEAD: . -- a/ b/ c/

But of course if you just need to copy from one pathspec to another
place, "--" syntax is redundant.

<rant>
But for my money, "git cp" is clearer and I'd love to get rid of the
user-confusing double-usage commands.  I'd replace "git checkout --"
with "git cp NEXT WTREE -- <path>" and replace "git reset --" with
"git cp HEAD NEXT --" where NEXT is the filesystem represented by the
"index"/"cache"/"staging area" and WTREE is an alias for the working
directory.
</rant>

I thought of "cp" (naturally, I was driven by "scp" syntax as I said)
and maybe if we think this through, we may be able to enhance cp to
support "remote locations" (and --patch option). So "put" vs "cp" is
not important to me now. What I'd like to hear is whether the syntax
makes sense.

My "hidden" plan if this works out would be to deprecate (or
discourage) everything in git-checkout except branch switching. I
don't have anything against git-reset. It's a kind of dangerous
command from the start (while git-checkout is more user friendly) and
can stay that way. The new "git <cp, put or whatever name>" should
fill 90% the needs for git-reset.
-- 
Duy