Ron Garret <ron1@xxxxxxxxxxx> writes: > No, because it would make it much easier to map intent back into a > command that implements that intent. Don't forget, this whole thing > began because I wanted to do something very simple, tried what seemed to > be the obvious way to do it, and stumbled accidentally on an advanced > feature. That would not have happened if I'd been able to just do a git > update --tree master^. Doing that _will_ confuse you in your next step. Can you explain what happens if you run "git commit" from that state, why "git commit" does so, and how that is useful? You may be too narrowly focused on only one single step, but I am more worried about the whole user experience: "I managed to do this, I am happy, but then the next step doesn't make much sense. Now what?" > What difference does that make? Sure, there would be ways to shoot > yourself in the foot with git update, but there is no shortage of ways > to shoot yourself in the foot now. As long as you have a coherent picture of the workflow individual commands are supporting, there is no "shoot yourself in the foot". "git update" on the other hand is _designed_ not to allow such a coherent picture to be formed in the user's head, by letting random combinations that may or may not make sense. > BTW, nothing prevents you from providing the usual repertoire of > higher-level functionality as thin layers on top of something like git > update. That is more or less the same as what I said in the footnote, which you didn't quote from my message. The flexibility of "update" may help Porcelain writers to pick and use only useful/usable combinations to present "the usual repertoire" for end users. At the philosophical level of "building blocks", I do not oppose to such flexibility [*1*]. But. As the main point of Michael's message was that he thought it may make things less confusing to the end users, I am pointing out that unleashing such an uncontrolled flexibility directly to end users will _not_ help reduce their confusion. [Footnote] *1* As a set of "building blocks" to implement "reset" and "checkout", I don't necessarily agree that "update" would be a good way to go from the implementation standpoint, but that is a totally separate matter. -- 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