From: "Steven Walter" <stevenrwalter@gmail.com>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Petr Baudis" <pasky@suse.cz>,
"Jakub Narebski" <jnareb@gmail.com>,
"Elijah Newren" <newren@gmail.com>,
"Govind Salinas" <govind@sophiasuchtig.com>,
git@vger.kernel.org
Subject: Re: Revert behavior
Date: Tue, 9 Sep 2008 18:30:05 -0400 [thread overview]
Message-ID: <e06498070809091530n57913304r2eb3920898a3225d@mail.gmail.com> (raw)
In-Reply-To: <7v63p53r93.fsf@gitster.siamese.dyndns.org>
On Tue, Sep 9, 2008 at 6:10 PM, Junio C Hamano <gitster@pobox.com> 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@gmail.com>
"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
next prev parent reply other threads:[~2008-09-09 22:31 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-09 13:26 Revert behavior [Was: Re: [ANNOUNCE] yap: Yet Another (Git) Porcelain] Elijah Newren
2008-09-09 13:38 ` Jakub Narebski
2008-09-09 16:37 ` Govind Salinas
2008-09-09 17:29 ` Steven Walter
2008-09-09 20:19 ` Elijah Newren
2008-09-09 21:50 ` Steven Walter
2008-09-09 23:02 ` Elijah Newren
2008-09-09 20:20 ` Elijah Newren
2008-09-09 21:28 ` Petr Baudis
2008-09-09 21:39 ` Steven Walter
2008-09-09 22:10 ` Revert behavior Junio C Hamano
2008-09-09 22:30 ` Steven Walter [this message]
2008-09-09 22:51 ` Elijah Newren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e06498070809091530n57913304r2eb3920898a3225d@mail.gmail.com \
--to=stevenrwalter@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=govind@sophiasuchtig.com \
--cc=jnareb@gmail.com \
--cc=newren@gmail.com \
--cc=pasky@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).