On Monday 06 August 2007, Johannes Schindelin wrote: > > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > >> But I'm wondering whether we'd want to include it in git by default > > >> (instead of having to tell confused users to add the alias). > > > > > > I recommend against that, too. All too often, I have some temporary files > > > in the working tree, and I'll be dimmed if I'm the only one. So > > > "addremove" adds too much possibility for pilot errors. > > > > "Recommend against it"? Why? > > Didn't I say that? It just _asks_ for pilot errors. Ok, in that spirit I also suggest removing _all_ git plumbing-level commands from the default installation. I also suggest adding confirmation dialog to any command that alters the repo, since we have to protect the user against "pilot errors". Get real. Adding a separate command (provided it's well implemented and documented) does not push the user off a cliff. Just because the command doesn't fit your workflow doesn't mean it's dangerous and should never be included. Just don't use it. If git were only to support the (probably non-existing) intersection of its user's workflows, we would probably have to pull e.g. git-rebase out of the tree, because (according to some) rewriting history is evil, and extremely prone to "pilot errors". > > It's a separate command, so if it doesn't fit your working style, don't > > use it. > > Hah! If that were true, we'd have a lot less mails like "I tried this and > it did not work", only to find out that the person assumed that > documentation is for wimps, and tried a command that "sounded" like it > would do the right thing. Having commands that "sound" like they do the right thing is not a bad idea at all. We should have more of those. ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net - 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
