From: Michael Nahas <mike.nahas@gmail.com>
Date: Mon, 23 Jan 2012 14:56:37 GMT
Subject: Re: [RFC/PATCH] git put: an alternative to add/reset/checkout
Message-ID: <CADo4Y9j5MwKr+rWza0ncLWuthY6x+s68CQYbY2+c8-E5pAa=Sw@mail.gmail.com>
In-Reply-To: <CACsJy8AB-6b_PMvyM7hRV3b=5o0Cn4CtosygUQOevTzVJhU=hg@mail.gmail.com>

Hi Duy,

I've contributed no code to git.  I've come up with plenty of ideas,
which seem to have gotten little traction.

Your ideas are similar to mine (and others), but the last attempt to
get them into git did not accomplish anything.  I don't know how much
work you have done on git, but before participating with git again, I
suggest you look at why the last attempt failed and we ask an
experienced person how things work.

It obviously isn't the design-first-then-find-a-willing-programmer of
the project I ran.  I don't know if it's the IETF's "running code and
a general consensus".  The only thing I've found is that people did
not want to discuss theory.  (I believe the feeling is that theory is
only worthy of DARCS.)  I also got the feeling that improving the user
interface (e.g., replacing "git checkout --" and "git reset --") was
not a priority.

So, please plan out a strategy before recruiting me to help push this
idea forward.

Mike


On Mon, Jan 23, 2012 at 9:35 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>
> On Mon, Jan 23, 2012 at 8:53 PM, Michael Nahas <mike.nahas@gmail.com> 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