Thread (5 messages) flat view 5 messages, 5 authors, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:26

Jeff King [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help