Ron Garret [off-list ref] 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.
In article [off-list ref],
Junio C Hamano [off-list ref] wrote:
Ron Garret [off-list ref] writes:
quoted
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.
quoted
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.
quoted
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