In article <7vaavw1478.fsf@xxxxxxxxxxxxxxxxxxxxxxxx>, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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, Nothing. > why "git commit" does so, Because my index would be empty. > and how that is useful? It wouldn't. Was this a trick question? Did you mean to ask what would happen if I ran commit -a? > 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?" I think you may be making some unwarranted assumptions about my end goal. > > 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. That is a valid point. I guess this depends on whether you think of git as merely a revision control system for computer source code, or if you think of it as a more general tool that can and should be used in other kinds of applications as well. > > 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. Yes, sorry about that. > 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. Did you mean "don't necessarily DISagree"? rg -- 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