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