Re: Command-line interface thoughts

[Jakub Narebski <jnareb@gmail.com>]

On Fri, 10 Jun 2011, Jeff King wrote:
> On Thu, Jun 09, 2011 at 06:27:11PM -0400, Michael Nahas wrote:

> > Jakub: "it is unnecessary power"
> > Yeah, like that an argument that anyone here will listen to.  "I can't
> > let you have diff3.  It's too much power for you.  You might trash the
> > repository with ... uh... diff3."
> 
> It's also wrong. Diff already does combined diff on arbitrary trees. So
> unnecessary, perhaps, but already there.

BTW. I should have written "too much flexibility", not "too much power".
What I had in mind is _convention_-based branching model in Subversion,
and its svn:mergeinfo property... which allow things like recording
cherry-picking, partial merges (of subtree), comitting on a tag or
commits over more than one branch... but which things are usually user's
error, not prevented by a tool.
 
> > Peff: "... use tokens to describe non-treeish sources and destinations"
> > What defines "tree-ish"ness?
> 
> I was using tree-ish there in the sense that it is used in the git
> documentation, which is: a reference that can resolve to a git
> tree object. So a tree sha1, a commit sha1 (which would resolve to its
> tree), a tag that points to a tree or commit, a ref that points to any
> of the above, and so on.
> 
> I think it is actually dying out from git documentation, though.  I was
> writing to Junio there, who I know understands that term, but I should
> have been more mindful that other readers of the thread wouldn't.

Historical note: "tree-ish" (now just "tree") were once called "ents" :-)
c.f. 3f0073a (Axe the last ent, 2006-08-21)

    Axe the last ent
    
    In the name of Standardization, this cleanses the last usage string of
    mystical creatures.  But they still dwell deep within the source and in
    some debug messages, it is said.

> > Do you know of anything in the INDEX file that would not be visible
> > from NEXT/WTREE/OURS/THEIRS?
> 
> The stat information, but that is usually ignored in porcelain, anyway
> (we refresh the state information at the beginning of most porcelain
> commands, so you can just assume everything is up to date with the
> working tree and will be shown as such).

Hmmm... there is additional complication that I haven't thought about,
namely assume-unchanged bit, and partial checkouts.

-- 
Jakub Narebski
Poland