Re: master^ is not a local branch -- huh?!?

From: Ron Garret <ron1@flownet.com>
Date: Jan 30, 2010, 07:31 UTC
Message-ID: <ron1-0D3105.23314829012010@news.gmane.org>
In-Reply-To: <7vaavw1478.fsf@alter.siamese.dyndns.org>

In article <7vaavw1478.fsf@alter.siamese.dyndns.org>,
 Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

> Ron Garret <ron1@flownet.com> 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.

Show 9 quoted lines

> > 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.

Show 6 quoted lines

> > 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.

Show 17 quoted lines

> 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