I've been following this thread for a long time and now I feel the need to chime in... On Fri, Nov 27, 2009 at 2:53 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > And it makes things inconsistent. That is why I do not use it. The number one problem my users have with git is inconsistent behavior, both internally to git, and externally with respect to the rest of the OS. But really, the issue is one of managing expectations, which is where we here tend to fall down. When you name the command grep, whether you like it of not, you've bought into a certain set of expectations from the user who has been using unix's grep since she was a baby. Saying, "well, in git it works this way", (or saying "well in git those path looking things you've been providing to commands are not really paths, so don't expect them to act as such"), would make my users want to vomit all over me, and then, not use git (a shame since it's the best scm system around IMHO). If we intend the behavior of the command to be materially different from the good old unix standby, then we shouldn't use the same name, and create the expectation that they are getting essentially the same thing (git search, git pickaxe, or something carries no semantic baggage---and no, I'm not suggesting we change the name). > I, for one, do not like Git's reputation... There's the rub. How do we achieve consistency without breaking the world? The short answer is, you really can't. As programmers we tend to be a very timid bunch, but sometimes (and David A. can attest to this, at least at dayjob) it's better to just make a change for the better, and just deal with the breakages. It is possible to change behavior (and even break some scripts! I firmly believe it is worthwhile sacrificing some scripts on the altar of consistency). The key once again, is managing expectations. We can't go around changing everything willy-nilly, and we can't be continually changing things. Here is where we could take a lesson from the python community. When they decided they needed to change things, they bundled a bunch of backwards incompatible changes together and went for it. Yes, Python 3 will break your scripts, but the most important thing is, everybody knows it. A similar thing was done here with the huge warning that push spits out, but in the general case I would argue, that the wisest course is to save backwards incompatible changes for a git 2 or something, where we know we're breaking the world, and then scratch all our (well thought out) backwards incompatible itches at once. Whew. A bit of a rant, but there you go... -- Uri Please consider the environment before printing this message. http://www.panda.org/how_you_can_help/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html