On Tue, Sep 9, 2008 at 6:10 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > If you implement "eg svn-like-revert" to checkout the given paths out of > the last commit, instead of the index, shouldn't that be sufficient? eg's "revert --since <commit> <path>" command is actually most similar to "svn update -rXXX path." In this case, except for the special case where commit is HEAD, it is not sufficient; checking the path out of the last commit would not be what the user wanted. >> It it a delicate balance to have the user interface match both the >> mental model of the user and the storage model of the tool. > > I do not think it is that simple. > > You could match the user experience to the mental model of the other tool, > by hiding the differences and insisting that people use only your tool. > > The real issue is that you may need to castrate the underlying tool in > certain places if its world model is richer than the model the tool you > are trying to emulate. Ignoring the index by making "svn-like-revert" > work on both index and the working tree file at the same time is a good > example of that. > > If the castrated feature is truly too exotic and rarely useful for mere > mortals, that strategy works very well. A simpler world model that lets > you do the same job equally well is a much better UI than the needlessly > complex one. But if that is not the case, your users would eventually > graduate out of the training wheel and would want to use that feature you > hid away from them, and at that point they need to unlearn parts of the > simpler world model and shift their world view somewhat. If you try to > support both classes of users, that become hard. Indeed so. Hiding the index is not a design goal of yap. However, neither is it absolutely necessary to understand the distinction between "staged" and "unstaged" changes to use yap. If a use never runs the "stage" command, everything would work as he expects. Achieving this is as simple as making "yap commit," in the presence of only unstaged changes, do the equivalent of "git commit -a." If it turns out that _wasn't_ what the user wanted, salvation is only a "yap uncommit" away. In your position as an integrator, what is a necessary tool for you may indeed be an exotic command for another user. For example, users who primarily interact with svn repositories (a target demographic for yap), "merge" is not terribly useful given the information loss when a commit is eventually "pushed" to subversion. I do not hide merge functionality, but neither is it emphasized as a standard part of the workflow (there is no "pull" command). > I have to admit that I used to have my own Porcelain when git was very > young, not because I did not like existing UI git had, but there was no UI > back then. "My own" Porcelain is relatively easy -- I have to only cater > to my own needs and need to expose only the limited subset of the features > the underlying tool (in this case, the storage model and history view of > git) I understand, and nobody complains that he cannot access the parts I > do not expose to him. Growing it to satisfy wider audience is the hard > part. No argument that supporting an audience greater than 1 is considerably more difficult. Indeed I intend and hope to support users other than myself with yap, else I would not have gone to the trouble of announcing it. However, without concrete discussion on where yap hides too much or "castrates" a feature in a way that hinders learning of the lower-level tools, there's only so much one can do. -- -Steven Walter <stevenrwalter@xxxxxxxxx> "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects." -Robert Heinlein -- 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
