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@xxxxxxxxx> wrote: > > On Mon, Jan 23, 2012 at 8:53 PM, Michael Nahas <mike.nahas@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html