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

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

[Jeff King]

This is an idea I've had for a while, but I was inspired to push it
forward a bit by Mike's command-line thread.

One problem I have seen people complain about is how "reset" and
"checkout" are somewhat overloaded to pull content into and out of the
index (since they also do things like moving HEAD or switching
branches). Those commands took the approach of saying "reset is about
changing the HEAD and possibly the index; therefore "reset -- file"
should be about pulling things from a commit into the index". And that
is certainly one way to think about it.

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.

So the "reset -- <file>" command is easily discoverable if you come at
it one way (I already know what reset does, but I want to reset just
some specific file), but not another way (I know how to move content one
way, but not the other way).

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). Some
other types I've thought of are:

  - stashes; you can already use stashes a source with "stash@{0}". They
    could also be a destination, chaining to "git stash".

  - 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

  - blobs as locations. We could allow something like:

      git put v1.7.5:Makefile WORKTREE:Makefile

    which would be equivalent to

      git put v1.7.5 WORKTREE -- Makefile

    but sometimes matches the user's mental model better. It also allows
    pulling blobs from index stages, like:

      # Resolve in favor of "ours"
      git put :2:Makefile INDEX,WORKTREE

  - subtrees as locations. This allows a form of renaming between old
    versions.

      git put gitgui-0.10.0: WORKTREE:git-gui


I hope it's obvious from what I wrote above and from the implementation,
but this would not be _replacing_ other commands, but would just be
another way of looking at them. By having more than one way to do the
same thing, it helps people discover the way that fits their mental
model most appropriately.  Of course, it may also just introduce insane
confusion.

Let the flaming begin.

-Peff

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

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> As you can see, this handles only three typoes of locations: the

Is that a recursive typo, or a typo of type?

> worktree, the index, and an arbitrary commit (really a tree-ish).

> Some other types I've thought of are:
>
>   - stashes; you can already use stashes a source with "stash@{0}". They
>     could also be a destination, chaining to "git stash".

No opinion on this.

>   - 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.

Should "git put WORKTREE HEAD" be equivalent to "git commit -A" then?

>   - allow multiple destinations, like
>
>      # equivalent to "git checkout --"
>      git put HEAD INDEX,WORKTREE

This is close to going overboard, but OK.

>   - blobs as locations. We could allow something like:
>
>       git put v1.7.5:Makefile WORKTREE:Makefile
>
>     which would be equivalent to
>
>       git put v1.7.5 WORKTREE -- Makefile
>
>     but sometimes matches the user's mental model better. It also allows
>     pulling blobs from index stages, like:
>
>       # Resolve in favor of "ours"
>       git put :2:Makefile INDEX,WORKTREE

More importantly, it would allow people to do things like...

	git put v1.7.5:Makefile WORKTREE:oMakefile
        magicdiff oMakefile Makefile

>   - subtrees as locations. This allows a form of renaming between old
>     versions.
>
>       git put gitgui-0.10.0: WORKTREE:git-gui

This is a natural extension of the above "we could rename" theme, right?

> ...  Of course, it may also just introduce insane
> confusion.

The only worry about confusion is if people incorrectly think these magic
tokens are not mere syntax sugars available only in "put", especially,
they look so similar to "HEAD" which is _not_ syntax sugar and can be used
elsewhere. Other than that, I think this is a nice approach.

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

[Jeff King]

On Tue, Jun 07, 2011 at 02:04:55PM -0700, Junio C Hamano wrote:

> > As you can see, this handles only three typoes of locations: the
> Is that a recursive typo, or a typo of type?

It's art; the viewer is free to interpret based on their own
experiences.

> > Some other types I've thought of are:
> >
> >   - stashes; you can already use stashes a source with "stash@{0}". They
> >     could also be a destination, chaining to "git stash".
> 
> No opinion on this.

My initial prototype was going to have stash as a fourth location. But I
backed out a little because it was complex, and the more I think about
it, I'm not sure it's really appropriate. You can already pull _from_ a
stash by naming its commit. And putting into a stash is a bit different
than a put, because it handles both the index and the worktree, and
removes the changes from them afterwards.

So I think a better match is the idea of "git put" to a new commit on a
named branch that I showed elsewhere. And then you can "git put" off of
it later.

> >   - 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.
> 
> Should "git put WORKTREE HEAD" be equivalent to "git commit -A" then?

I'm tempted to say yes, with two reservations:

  1. Making a new commit (or even a new branch) somehow seems more
     heavyweight to me than just picking changes. So I'm reluctant to do
     it for just "git put $from HEAD"; maybe there should be a special
     token that says "yeah, make a new commit". Like:

       git put WORKTREE COMMIT:HEAD

     to commit on top of HEAD, or even

       git put WORKTREE AMEND:HEAD

     to amend HEAD (this would be useful when building up a commit
     piece by piece using "git put").

     But that is getting very magical. I have a vague feeling you could
     actually reimplement a lot of the user-facing portions of git in
     terms of these "put" operations. For example, forget the index as a
     whole and have "NEXT", "BASE", "OURS", and "THEIRS" representing
     trees of the various stages.

     I'm not sure if that's just insane, though. That _isn't_ how the
     index actually works (e.g., resolved paths would have only a NEXT
     entry, so the other trees would actually be partial trees). So
     we're making an abstraction over it, and when that abstraction
     leaks, I fear things will get very confusing for the user.

  2. There is a slight incompatibility between the "git put" mental
     model and what really happens. I already ran into it once with "git
     put HEAD WORKTREE", and it appears here again. The issue is that
     you generally _don't_ put items straight from a commit to the
     worktree and vice versa. They go through the index.

     So I took care with "git put HEAD WORKTREE" that the index was not
     touched. That makes the command very obvious and keeps the sources
     and destinations as orthogonal as possible. But is it really what
     the user wants? In the case of "checkout", I'm not sure. In the
     case of "commit -A", you probably _do_ want to update the index if
     the commit is HEAD, and _don't_ if it is another branch.

     But now we're getting magical again. So the question becomes:
     should git put just be a pure _wrapper_ around these other
     commands to aid in discoverability, and do sensible things for each
     combination, or should it be a purely orthogonal "pick content from
     source to destination" command?

> >   - allow multiple destinations, like
> >
> >      # equivalent to "git checkout --"
> >      git put HEAD INDEX,WORKTREE
> 
> This is close to going overboard, but OK.

Yeah, I'm still kind of brainstorming, but I think you might be right.
But see above for why "git put" should possibly just be doing it for
you automatically.

> >   - subtrees as locations. This allows a form of renaming between old
> >     versions.
> >
> >       git put gitgui-0.10.0: WORKTREE:git-gui
> 
> This is a natural extension of the above "we could rename" theme, right?

Yeah, I think so.

> The only worry about confusion is if people incorrectly think these magic
> tokens are not mere syntax sugars available only in "put", especially,
> they look so similar to "HEAD" which is _not_ syntax sugar and can be used
> elsewhere. Other than that, I think this is a nice approach.

I think it might be worth using the same tokens in "diff", but yeah,
they definitely should not go elsewhere.

I find the all-caps ugly, and it is part of what confuses them with
HEAD. At the same time, we are using the same namespace that ref lookup
uses. So calling it "worktree" might be too ambiguous. I tried to avoid
using "--worktree" because I wanted to make it clear that these were
ordered arguments, not options.

There's also one other complication with the whole idea, which is that
there are two separate things you might want to move: content itself, or
_changes_ in content.

That is, think about the way stashes work. We don't apply the difference
between the stashed content and our working tree. We look at the
difference between the stashed content and its parent, and then apply
those changes to the working tree.

When I do "checkout -p $commit $file", I am often not interested in
seeing all of the differences between where I am now and where $commit
is, but rather in seeing the differences introduced by $commit, and
pulling them selectively into my current version of $file. Sort of a
"cherry-pick -p".

Should "put" support that kind of usage? What would it look like?

  git put commit:v1.7.5 WORKTREE Makefile

? Or even:

  git put v1.7.4..v1.7.5 WORKTREE Makefile

I dunno. Maybe this whole thing is too crazy. I'll think on it some
more, and maybe some other people will comment.

-Peff

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

[Michael Nahas]

Junio wrote:
>The only worry about confusion is if people incorrectly think these magic
>tokens are not mere syntax sugars available only in "put", especially,
>they look so similar to "HEAD" which is _not_ syntax sugar and can be used
>elsewhere. Other than that, I think this is a nice approach.

I don't think they are syntactic sugar.

The working tree is a tree.  HEAD is a tree.  HEAD is also a commit
and a file in .git/, so it is more than a tree, but it's a tree.  NEXT
is a tree.   There may be different code to read (or write) each of
them, but they are all trees.  So I don't see these labels as
syntactic sugar -- making a commonly used piece of code easier to use
(like ++) -- but as presenting a common interface to a concept that
may have different implementations.

I think this "git put" command let's people think in terms of trees.
Commits are read-only trees.  NEXT and WTREE are tree that can be
written to.  It's up for debate if stashes are read-only or writeable.

To me "git put" is just the UNIX "cp" command, just that files or
directories can be prefixed by tree names.  In fact, I'd make sure the
"-r" option was used when copying whole trees or subtrees. :)

git put -r HEAD WTREE
git put HEAD:foo.txt WTREE:foo.txt

I would keep it like "cp" and drop the support for copying to multiple
trees (like HEAD and INDEX) in a single command.  I would have a good
form for copying multiple files from one tree to another.  E.g., "git
put HEAD:{foo.txt,bar.txt} WTREE" or "git put HEAD WTREE foo.txt
bar.txt" or "git put HEAD:*.txt WTREE" even.

I do not think "COMMIT" or "AMEND" should be part of the command.

"git put" could replace "git add", "git checkout -- <file>", and "git
reset -- <file>".  It would not replace the other common file
manipulators: "git rm" and "git mv".

Damn, I'm tempted to say screw "git put" and call it "git cp".  Then
change "git rm" and "git mv" to support writeable trees and you've got
yourself a very easy to learn interface!


Jeff wrote:
> The issue is that
> you generally _don't_ put items straight from a commit to the
> worktree and vice versa. They go through the index.

Going through the index is only the right move if you're going backwards.

HEAD is the most recent commit.  NEXT should be what you already know
will go in the next commit.  WTREE is stuff that may go into NEXT or
into another future commit or may never go in at all.   So, HEAD and
all previous commits are the past; NEXT is the near future; and WTREE
is the far future.

If you are reverting a mistake, you are copying from HEAD or some
other ancestor to NEXT and WTREE.  Especially if you're copying from
HEAD, you want to include the target NEXT, since you know that that
code will almost assuredly work and be part of the next commit.  In
fact, the opposite of "git add" (the awkward "git checkout -- <file>")
is to copy a file from HEAD to NEXT --- essentially pushing off the
change from NEXT to some future commit.

In every other case, you want new stuff to go into WTREE and skip the
NEXT.  The way I view merge is that the new files are copied from
another branch into WTREE.  All resolved changes are then moved into
NEXT.  If there are no unresolved changed, a new commit is made.
While this may not be the actual sequence of events that Git performs,
it's how I see the operation - new changes are introduced at WTREE,
correct changes are moved into NEXT, and the commit operation makes
them permanent.





On Tue, Jun 7, 2011 at 5:45 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Jun 07, 2011 at 02:04:55PM -0700, Junio C Hamano wrote:
>
>> > As you can see, this handles only three typoes of locations: the
>> Is that a recursive typo, or a typo of type?
>
> It's art; the viewer is free to interpret based on their own
> experiences.
>
>> > Some other types I've thought of are:
>> >
>> >   - stashes; you can already use stashes a source with "stash@{0}". They
>> >     could also be a destination, chaining to "git stash".
>>
>> No opinion on this.
>
> My initial prototype was going to have stash as a fourth location. But I
> backed out a little because it was complex, and the more I think about
> it, I'm not sure it's really appropriate. You can already pull _from_ a
> stash by naming its commit. And putting into a stash is a bit different
> than a put, because it handles both the index and the worktree, and
> removes the changes from them afterwards.
>
> So I think a better match is the idea of "git put" to a new commit on a
> named branch that I showed elsewhere. And then you can "git put" off of
> it later.
>
>> >   - 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.
>>
>> Should "git put WORKTREE HEAD" be equivalent to "git commit -A" then?
>
> I'm tempted to say yes, with two reservations:
>
>  1. Making a new commit (or even a new branch) somehow seems more
>     heavyweight to me than just picking changes. So I'm reluctant to do
>     it for just "git put $from HEAD"; maybe there should be a special
>     token that says "yeah, make a new commit". Like:
>
>       git put WORKTREE COMMIT:HEAD
>
>     to commit on top of HEAD, or even
>
>       git put WORKTREE AMEND:HEAD
>
>     to amend HEAD (this would be useful when building up a commit
>     piece by piece using "git put").
>
>     But that is getting very magical. I have a vague feeling you could
>     actually reimplement a lot of the user-facing portions of git in
>     terms of these "put" operations. For example, forget the index as a
>     whole and have "NEXT", "BASE", "OURS", and "THEIRS" representing
>     trees of the various stages.
>
>     I'm not sure if that's just insane, though. That _isn't_ how the
>     index actually works (e.g., resolved paths would have only a NEXT
>     entry, so the other trees would actually be partial trees). So
>     we're making an abstraction over it, and when that abstraction
>     leaks, I fear things will get very confusing for the user.
>
>  2. There is a slight incompatibility between the "git put" mental
>     model and what really happens. I already ran into it once with "git
>     put HEAD WORKTREE", and it appears here again. The issue is that
>     you generally _don't_ put items straight from a commit to the
>     worktree and vice versa. They go through the index.
>
>     So I took care with "git put HEAD WORKTREE" that the index was not
>     touched. That makes the command very obvious and keeps the sources
>     and destinations as orthogonal as possible. But is it really what
>     the user wants? In the case of "checkout", I'm not sure. In the
>     case of "commit -A", you probably _do_ want to update the index if
>     the commit is HEAD, and _don't_ if it is another branch.
>
>     But now we're getting magical again. So the question becomes:
>     should git put just be a pure _wrapper_ around these other
>     commands to aid in discoverability, and do sensible things for each
>     combination, or should it be a purely orthogonal "pick content from
>     source to destination" command?
>
>> >   - allow multiple destinations, like
>> >
>> >      # equivalent to "git checkout --"
>> >      git put HEAD INDEX,WORKTREE
>>
>> This is close to going overboard, but OK.
>
> Yeah, I'm still kind of brainstorming, but I think you might be right.
> But see above for why "git put" should possibly just be doing it for
> you automatically.
>
>> >   - subtrees as locations. This allows a form of renaming between old
>> >     versions.
>> >
>> >       git put gitgui-0.10.0: WORKTREE:git-gui
>>
>> This is a natural extension of the above "we could rename" theme, right?
>
> Yeah, I think so.
>
>> The only worry about confusion is if people incorrectly think these magic
>> tokens are not mere syntax sugars available only in "put", especially,
>> they look so similar to "HEAD" which is _not_ syntax sugar and can be used
>> elsewhere. Other than that, I think this is a nice approach.
>
> I think it might be worth using the same tokens in "diff", but yeah,
> they definitely should not go elsewhere.
>
> I find the all-caps ugly, and it is part of what confuses them with
> HEAD. At the same time, we are using the same namespace that ref lookup
> uses. So calling it "worktree" might be too ambiguous. I tried to avoid
> using "--worktree" because I wanted to make it clear that these were
> ordered arguments, not options.
>
> There's also one other complication with the whole idea, which is that
> there are two separate things you might want to move: content itself, or
> _changes_ in content.
>
> That is, think about the way stashes work. We don't apply the difference
> between the stashed content and our working tree. We look at the
> difference between the stashed content and its parent, and then apply
> those changes to the working tree.
>
> When I do "checkout -p $commit $file", I am often not interested in
> seeing all of the differences between where I am now and where $commit
> is, but rather in seeing the differences introduced by $commit, and
> pulling them selectively into my current version of $file. Sort of a
> "cherry-pick -p".
>
> Should "put" support that kind of usage? What would it look like?
>
>  git put commit:v1.7.5 WORKTREE Makefile
>
> ? Or even:
>
>  git put v1.7.4..v1.7.5 WORKTREE Makefile
>
> I dunno. Maybe this whole thing is too crazy. I'll think on it some
> more, and maybe some other people will comment.
>
> -Peff
>

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

[Jakub Narebski]

Jeff King <peff@peff.net> writes:

> I find the all-caps ugly, and it is part of what confuses them with
> HEAD. At the same time, we are using the same namespace that ref lookup
> uses. So calling it "worktree" might be too ambiguous. I tried to avoid
> using "--worktree" because I wanted to make it clear that these were
> ordered arguments, not options.

Perhaps we can use some character that is forbidden in ref names,
doesn't make trouble when doing allowed operations on said refs, won't
confuse user, and is not trouble with shell... ehhh...

* @{wtree} would confuse users that it has something to do with reflog
* [tree]   would be trouble with some shells
* ~tree~   looks a bit strange, might be trouble with username expansion  
* :tree:   might be mistaken for 'tree:' in index

-- 
Jakub Narebski
Poland
ShadeHawk on #git

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

[Matthieu Moy]

Jakub Narebski <jnareb@gmail.com> writes:

> Jeff King <peff@peff.net> writes:
>
>> I find the all-caps ugly, and it is part of what confuses them with
>> HEAD. At the same time, we are using the same namespace that ref lookup
>> uses. So calling it "worktree" might be too ambiguous. I tried to avoid
>> using "--worktree" because I wanted to make it clear that these were
>> ordered arguments, not options.
>
> Perhaps we can use some character that is forbidden in ref names,
> doesn't make trouble when doing allowed operations on said refs, won't
> confuse user, and is not trouble with shell... ehhh...
>
> * @{wtree} would confuse users that it has something to do with reflog

Well, we already have @{upstream} ...

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Jeff King]

On Wed, Jun 08, 2011 at 07:28:35PM +0200, Matthieu Moy wrote:

> > Jeff King <peff@peff.net> writes:
> >
> >> I find the all-caps ugly, and it is part of what confuses them with
> >> HEAD. At the same time, we are using the same namespace that ref lookup
> >> uses. So calling it "worktree" might be too ambiguous. I tried to avoid
> >> using "--worktree" because I wanted to make it clear that these were
> >> ordered arguments, not options.
> >
> > Perhaps we can use some character that is forbidden in ref names,
> > doesn't make trouble when doing allowed operations on said refs, won't
> > confuse user, and is not trouble with shell... ehhh...
> >
> > * @{wtree} would confuse users that it has something to do with reflog
> 
> Well, we already have @{upstream} ...

Yes, but like all of the @{} things, it's a modifier for the left-hand
side. So "master@{upstream}" is meaningful, and "@{upstream}" is the
same as "HEAD@{upstream}".

What does "master@{wtree}" mean?

-Peff

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

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> On Wed, Jun 08, 2011 at 07:28:35PM +0200, Matthieu Moy wrote:
>
>> > Jeff King <peff@peff.net> writes:
>> >
>> > * @{wtree} would confuse users that it has something to do with reflog
>> 
>> Well, we already have @{upstream} ...
>
> Yes, but like all of the @{} things, it's a modifier for the left-hand
> side. So "master@{upstream}" is meaningful, and "@{upstream}" is the
> same as "HEAD@{upstream}".
>
> What does "master@{wtree}" mean?

Nothing, but then we already have @{-1} ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Jakub Narebski]

Matthieu Moy wrote:
> Jeff King <peff@peff.net> writes:
> > On Wed, Jun 08, 2011 at 07:28:35PM +0200, Matthieu Moy wrote:
> >> > Jeff King <peff@peff.net> writes:
> >> >
> >> > * @{wtree} would confuse users that it has something to do with reflog
> >> 
> >> Well, we already have @{upstream} ...
> >
> > Yes, but like all of the @{} things, it's a modifier for the left-hand
> > side. So "master@{upstream}" is meaningful, and "@{upstream}" is the
> > same as "HEAD@{upstream}".
> >
> > What does "master@{wtree}" mean?
> 
> Nothing, but then we already have @{-1} ;-).

That's actually HEAD reflog.

-- 
Jakub Narebski
Poland

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

[Matthieu Moy]

Jakub Narebski <jnareb@gmail.com> writes:

> Matthieu Moy wrote:
>> Jeff King <peff@peff.net> writes:
>> > On Wed, Jun 08, 2011 at 07:28:35PM +0200, Matthieu Moy wrote:
>> >> > Jeff King <peff@peff.net> writes:
>> >> >
>> >> > * @{wtree} would confuse users that it has something to do with reflog
>> >> 
>> >> Well, we already have @{upstream} ...
>> >
>> > Yes, but like all of the @{} things, it's a modifier for the left-hand
>> > side. So "master@{upstream}" is meaningful, and "@{upstream}" is the
>> > same as "HEAD@{upstream}".
>> >
>> > What does "master@{wtree}" mean?
>> 
>> Nothing, but then we already have @{-1} ;-).
>
> That's actually HEAD reflog.

Yes, but neither HEAD@{-1} nor master@{-1} work. So we have one instance
of @{...} which is unrelated from reflog, and another which isn't a
suffix. @{wtree} would be both.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

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

[Jakub Narebski]

Matthieu Moy wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> > Matthieu Moy wrote:
> >> Jeff King <peff@peff.net> writes:
> >> > On Wed, Jun 08, 2011 at 07:28:35PM +0200, Matthieu Moy wrote:
> >> >> > Jeff King <peff@peff.net> writes:
> >> >> >
> >> >> > * @{wtree} would confuse users that it has something to do with reflog
> >> >> 
> >> >> Well, we already have @{upstream} ...
> >> >
> >> > Yes, but like all of the @{} things, it's a modifier for the left-hand
> >> > side. So "master@{upstream}" is meaningful, and "@{upstream}" is the
> >> > same as "HEAD@{upstream}".
> >> >
> >> > What does "master@{wtree}" mean?
> >> 
> >> Nothing, but then we already have @{-1} ;-).
> >
> > That's actually HEAD reflog.
> 
> Yes, but neither HEAD@{-1} nor master@{-1} work. So we have one instance
> of @{...} which is unrelated from reflog, and another which isn't a
> suffix. @{wtree} would be both.

But both are about refs (upstream of a ref, or previously checked-out ref).
@{wtree} ain't.

-- 
Jakub Narebski
Poland

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

[Nguyen Thai Ngoc Duy]

On Thu, Jun 9, 2011 at 12:25 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Perhaps we can use some character that is forbidden in ref names,
> doesn't make trouble when doing allowed operations on said refs, won't
> confuse user, and is not trouble with shell... ehhh...
>
> * :tree:   might be mistaken for 'tree:' in index

Also may clash (or make it more ambiguous) with pathspec magic. Another option

* +tree
-- 
Duy

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

[Nguyen Thai Ngoc Duy]

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.

Also "git put --pretend" or "git put --dry-run" may show the diff of
content movement, without actual moving. "--dry-run --patch"
combination probably does not make sense though.

> As you can see, this handles only three typoes of locations: the
> worktree, the index, and an arbitrary commit (really a tree-ish). Some
> other types I've thought of are:
>
>  ....
>

I find it intuitive (given a source tree and destination one(s), you
can copy content by paths or even by hunks), until you give it more
powers (creating new branch or commit, move subdirs...). The original
git-put idea could reduce a lot of confusion for new users. Your extra
types seem uncommon to me (or can be well covered with current
commands without much confusion). For advanced use cases, maybe the
current command set can be enhanced with new options.
-- 
Duy

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

[Nguyen Thai Ngoc Duy]

(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

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

[Michael Nahas]

On Mon, Jan 23, 2012 at 5:32 AM, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>
> (Bringing up an old thread)

"...thank you so much for bringing up such a painful subject. While
you're at it, why don't you give me a nice paper cut and pour lemon
juice on it."


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

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.

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 --".

<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>

Still, good luck.  It's a useful addition even if it is "git cherry-pick --".

Mike

>
>
> 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

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

[Nguyen Thai Ngoc Duy]

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

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

[Michael Nahas]

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

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

[Junio C Hamano]

Michael Nahas <mike.nahas@gmail.com> writes:

> 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".

These two are not necessarily incompatible.

A proposed new feature needs to be explained well, describing in what
situation it will help what kind of users and without hurting others and
why it is a worthy addition.

We require a general consensus that any proposed change is a worthy
addition, and a working code is often a good addition to help us reaching
one, because people can guess what is being proposed even when the idea is
presented poorly. A poorly presented idea without working code often fares
no better than just a handwaving with crazy talk, as you fail to make
others realize what you are trying to achieve.

But working code is not a requirement to present good ideas. It just helps
to add clarity to it.