Here's a thought:
Let's remove the rm alias and make it just "fossil remove". That will
eliminate all my objections.
When I issue a "rm", whether at my shell, or in hg, git, svn, everywhere
else but CVS apparently, which is the reason for establishing this
expectation, it behaves a certain way.
Forget VCSs for a minute. When I issue "rm" on every Unix implementation
on the planet, the file is removed from disk. Unix does not have a
"remove" command about which I have expectations.
So let's just ditch "fossil rm" entirely so that expectation is broken?
Then when someone asks for rm to be aliased, we explain that there is a
dissonance between how Fossil and just about everything else handles rm,
so the non-standard behavior is called "remove" and nothing more?
I have no issues with "fossil remove" not removing the file from the
filesystem, but I will probably almost always hit this "fossil rm"
dissonance.
And thus the bikeshed is painted.
On 12/14/2012 11:32 AM, Chad Perrin wrote:
On Thu, Dec 13, 2012 at 05:04:52PM -0700, Matt Welland wrote:
This is the classical divide between pragmatists (I want to get my job with
with minimal pain so I can go home a play ball with my son) versus the
idealists (source code management means doing x, y and z and no more and no
less and I'm sorry that it will take you twice as long to do your job right
*grin*).
Fossil is caught between the messy world of the pragmatists and the nice
tidy world of the idealists. There is no one right way to do it. One group
or the other will be disappointed.
I don't think that's all there is to it. It isn't really fair to those
who prefer automation of the full set of rm tasks to suggest they
necessarily lack a sense of the idea, or to those who oppose that
automation to suggest they lack a sense of pragmatism. I think that the
two sides of this discussion are more sophisticated and complex than
that, with several different types of argument being possible and
presented on each side. The major argument types I have seen so far are:
for rm automation | against rm automation
----------------------------------|----------------------------------
idealist (Unix way) | idealists (airbags way)
pragamtists (POLS way) | pragmatists (backward compat)
trolls (haven't noticed any) | trolls (NIH and "you're dumb")
If you know of any trollish argument forms on the pro-automation side,
please feel free to point them out. I may be suffering some confirmation
bias in this case. Anyway, my explanations of the various arguments, as
I have noticed them, follow.
* Unix way idealists: When you tell it to do something, it damned well
does it.
* airbags way idealists: When you tell it to do something that might be
accidentally applied in an unintentionally destructive manner by an
incautious user, it should second-guess your intentions and try to
convince you to do things differently, on the assumption that is not
what you wanted.
* POLS pragmatists: When you issue a command that seems like it should
perform a given task, you expect it to perform the whole task, and not
only part of it. Tool design should account for that.
* backward compat pragmatists: This is how it has been done so far,
establishing a set of expectations particular to long-time users and
the automation scripts they have written that rely on the behavior in
question. We should not change the tool's behavior to violate those
ingrained expectations because there may be backward incompatibility
problems.
* NIH trolls: You're trying to turn Fossil into Git! Stop it!
* "you're dumb" trolls: Obviously you are all too stupid to understand
the benefits of keeping things the way they are. You are wrong because
you are stupid; you are stupid because you disagree with me.
If we could eliminate those "troll" category participants in the
discussion, I think we would get a lot further in sorting this out.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
