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. > 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. > 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. > What is non-treeish about NEXT/WTREE/etc.? They don't resolve to git tree objects. :) > 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). -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