Re: Command-line interface thoughts

From: Michael Nahas <mike.nahas@gmail.com>
Date: Jun 10, 2011, 00:00 UTC
Message-ID: <BANLkTim7ZAGHO3a-G6cBwKjg4wKzskbVTg@mail.gmail.com>
In-Reply-To: <20110609223825.GA7771@sigill.intra.peff.net>

On Thu, Jun 9, 2011 at 6:38 PM, Jeff King <peff@peff.net> wrote:

Show 30 quoted lines

> On Thu, Jun 09, 2011 at 06:27:11PM -0400, Michael Nahas wrote:
>
>> I dunno Michael, your idea sounds dangerous.
>>
>> You're saying that the user interface should be defined with concepts
>> that have nothing to do with the plumbing.  That's crazy talk!  Next
>> you'll be arguing that users don't need to know that the Index file
>> has 4 stages!
>>
>> ;)
>
> I know you are being sarcastic, but it _is_ a dangerous thing. One of
> the great things about git is that it exposes the details of its data
> structures. So you rarely run into corner cases where the UI has given
> you an inaccurate mental model, and you have to reconcile what is
> actually happening with your mental model. The tradeoff, of course, is
> that you get exposed to the full complexity of what is happening.
>
> And note that I'm not saying it's impossible, or it's something we
> definitely shouldn't do. Only that we should be aware of what
> inaccuracies we might be feeding to the user, and asking questions about
> how that might bite is. Like: how likely is the user to run into a
> corner case where git does something unexpected? If it does happen, how
> much worse will explaining the behavior be than simply having exposed
> them to lower-level constructs in the first place?
>
> Also note that I'm not even sure that this token proposal is in fact
> introducing inaccuracies, and is not simply an alternate but equivalent
> mental model. But these are the types of things I think people should be
> thinking about in a proposal like this.

The beauty of building a level of abstraction is that you don't need to know about the lower level. Git's plumbing is built on files, and directories, and communication libraries, but, in general, we don't talk about manipulating the plumbing in those terms. We talk in the concepts of the higher level: commits, trees, branches, pushes, and pulls.

I don't know what are the right concepts are for the porcelain. I have a feeling that a lot of the concepts will map 1-to-1 will concepts in the plumbing, which is what makes the two hard to separate. At the moment, the NEXT and HEAD concepts "feel" right. But I also think they're just part of the solution.

A partial step towards the right idea is not always a good thing. It could leave users confused or give them the power to create a mess but not fix it. We should be careful, but not fearful.

>> Peff: "... use tokens to describe non-treeish sources and destinations"
>> What is non-treeish about NEXT/WTREE/etc.?
>
> They don't resolve to git tree objects. :)

Touchee'. Actually, nice succinct definition.

Tree objects have SHAs and are long lasting.  Good differences to keep in mind.

Show 7 quoted lines

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

I took a quick look at some documentation. The index has almost all the stats about a file that are directly available from a file in the working tree. It also looks like the index has far more stats than can be stored in a tree object entry. Is that right?

Mike