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

[Nguyen Thai Ngoc Duy <pclouds@gmail.com>]

(Bringing up an old thread)

On Wed, Jun 8, 2011 at 3:06 AM, Jeff King <peff@peff.net> wrote:
> ...
> But another way to think about it is that commits, the index, and the
> working tree are all "locations" with content. And one common operation
> you may want to do is to move content from one spot to another, either
> whole, by file, or by diff hunks. To a new user, knowing that "add" is
> the command for moving content from thet working tree to the index does
> not help them know which command to use to do the opposite content
> movement.
> ...
> My idea is therefore to have a single command for moving content from
> one location to another. You specify a source and a destination and get
> a uniform interface for moving content.
>
> A proof-of-concept patch is below. Be aware that is meant to be
> illustrative and is not well tested. Also, it is a minimal presentation
> of the concept. Other "locations" may also be meaningful. I'll include
> some ideas below the patch.
>
> ---
>  Makefile   |    1 +
>  git-put.sh |   70 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  2 files changed, 71 insertions(+), 0 deletions(-)
>  create mode 100644 git-put.sh
>
> diff --git a/Makefile b/Makefile
> index e40ac0c..4564506 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -368,6 +368,7 @@ SCRIPT_SH += git-merge-one-file.sh
>  SCRIPT_SH += git-merge-resolve.sh
>  SCRIPT_SH += git-mergetool.sh
>  SCRIPT_SH += git-pull.sh
> +SCRIPT_SH += git-put.sh
>  SCRIPT_SH += git-quiltimport.sh
>  SCRIPT_SH += git-rebase.sh
>  SCRIPT_SH += git-repack.sh
> diff --git a/git-put.sh b/git-put.sh
> new file mode 100644
> index 0000000..f673e14
> --- /dev/null
> +++ b/git-put.sh
> @@ -0,0 +1,70 @@
> +#!/bin/sh
> +
> +SUBDIRECTORY_OK=Yes
> +OPTIONS_KEEPDASHASH=Yes
> +OPTIONS_SPEC="\
> +git put [options] <from> <to> [--] <file...>
> +
> +Move contents from one place to another, where <from> and <to> are one of:
> +  1. A commit (e.g., master, HEAD~10, v1.7.5)
> +  2. The special token INDEX to indicate git's index.
> +  3. The special token WORKTREE to indicate the working directory.
> +
> +Options:
> +--
> +p            don't move whole files; use the patch interface
> +"
> +. git-sh-setup
> +
> +patch=
> +while test $# != 0; do
> +       case "$1" in
> +       -p) patch=--patch ;;
> +       --) shift; break ;;
> +       *) usage ;;
> +       esac
> +       shift
> +done
> +test $# -lt 2 && usage
> +
> +from=$1; shift
> +to=$1; shift
> +test "$1" = "--" && shift
> +
> +type_of() {
> +       case "$1" in
> +       INDEX) echo index ;;
> +       WORKTREE) echo worktree ;;
> +       *) echo commit ;;
> +       esac
> +}
> +
> +# Checkout contents to worktree without munging the index in
> +# between.
> +worktree_checkout() {
> +       old=$GIT_INDEX_FILE
> +       test -z "$old" && old=$(git rev-parse --git-dir)/index
> +       new=$(git rev-parse --git-dir)/put-index.tmp
> +       cp "$old" "$new" &&
> +       GIT_INDEX_FILE=$new git checkout "$@"
> +       status=$?
> +       rm -f "$new"
> +       exit $status
> +}
> +
> +case "$(type_of "$from"),$(type_of "$to")" in
> +*,commit)
> +       die "You can't modify an existing commit." ;;
> +index,index)
> +       die "You can't move content from the index on top of itself." ;;
> +worktree,index)
> +       exec git add $patch -- "$@" ;;
> +commit,index)
> +       exec git reset $patch "$from" -- "$@" ;;
> +index,worktree)
> +       exec git checkout $patch -- "$@" ;;
> +worktree,worktree)
> +       die "You can't move content in the worktree on top of itself." ;;
> +commit,worktree)
> +       worktree_checkout $patch "$from" -- "$@" ;;
> +esac
>
>
> As you can see, this handles only three typoes of locations: the
> worktree, the index, and an arbitrary commit (really a tree-ish).

Last time we were stuck at the magic keywords INDEX and WORKTREE. What
if we sort of follow scp naming convention:

 - Normal paths are working tree's paths
 - Paths with a colon in it are in "remote" locations (index or a
tree). The part before colon specifies the location.

We could have:

git put <src> [<src>...] <dst>
git put <src> [<src>...] <dst> -- <pathspec>

Where <src> and <dst> could be

 - <tree-ish> <colon> [<pathspec>]
 - [0-3] <colon> [<pathspec>]
 - <pathspec> (or plain path)

In the first form, pathspec could be specified in <src>. If <dst> is
worktree, then "." would be enough (or path to repo's root to be more
strict). In the second form, no pathspec can be part of <src> nor
<dst> because they're at the end already.

With this syntax we could have:

git put 0:path/to/file.c . (or git put 0: path/to/file.c)
 -> copy file.c from index to worktree (at the same path "path/to/file.c")
git put path/to/file 0:
 -> copy file to index
git put HEAD: . -- path/
 -> checkout everything in path/ from HEAD

I'm not sure how mutiple <src> should work, but there may be a use case for it.

> Some other types I've thought of are:
> ...
>  - branches as destinations; obviously we can't change an existing
>    commit, but what about something like:
>
>      git put WORKTREE BRANCH:foo
>
>    to optionally create a new branch "refs/heads/foo" based on the
>    current HEAD, push changes into a temporary index that matches its
>    tip, and then making a new commit based on top.
>
>    This would serve a similar purpose to stashes, except that they
>    would be named and could operate as full branches. I would find it
>    useful for picking apart a mass of worktree changes into discrete
>    commits.
>
>  - allow multiple destinations, like
>
>     # equivalent to "git checkout --"
>     git put HEAD INDEX,WORKTREE

These obviously do not work with the syntax I propose.
-- 
Duy