On 9/11/2015 3:28 PM, Warren Young wrote:
On Sep 11, 2015, at 4:19 PM, Ross Berteig <r...@cheshireeng.com>
I personally think that "diff --from undo" is the best of all the
proposals floated in this thread, and tend to assume that "undo" is
an unlikely branch or tag name.
I agree that it is unlikely to cause a conflict. I just don’t like
that it makes you think about undo, when that is an implementation
detail here.
But you just did something, and it made a bigger splash than you
expected. One reaction is to immediate undo it so you can research it
better. The other is to ask, as the OP did, what just happened here.
Let me put it a bit differently than before, since I don’t seem to be
getting my point across. When you say “fossil up” and get a whole
pile of changes, your next question is, “What exactly is the content
of those changes?” This feature answers that question, and although
it *happens* to do so using the undo mechanism, the user isn’t
thinking about undoing the changes here, so why make them give a
command that exposes this detail?
One reason is that this implementation detail is prominently exposed
already. That is, the output of "fossil update ...." ends with text like
this:
.... lots of files listed as the update churns ....
---------------------------------------------------------------
updated-to: d43847c96809b76481c173b9e75dee771b5541a9 2015-08-27
14:24:09 UTC
tags: trunk
comment: Update change log. (user: mistachkin)
changes: 9 files modified.
"fossil undo" is available to undo changes to the working checkout.
So the user is directly reminded that undo exists, and that using it
would reverse the update actions, and that was important enough to show
that it is the last thing printed so it is guaranteed not to have
scrolled away in the noise.
Other commands populate the undo buffer too, and usually mention that to
the user in a similar way.
It is possible that a better name for the undo buffer itself could be
"undo-buffer", which is at least a noun and not a verb. A noun would be
better. Other nouns that might fit the bill include "buffer" or "cache".
If we also allowed reference to the stash, then "--from stash" could be
the most recent (or only?) thing in it, and --from stash-foo could be
the item in the stash with STASHID foo. Of course, it might be better to
use "stash:foo" by analogy with "tag:foo" and "root:foo".
This is all very bikesheddy, though.
The feature clearly has some value, especially after an update does more
than you expected. Having lots of ways to recover one's context is a
good thing.
And naming things is hard. And in my experience it is harder to get
right the more fundamental the concept is. This case seems pretty
typical to me: the need was easy to express and the feature easy to
create, but finding the right name for it is trickier.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
