Hi, On Tue, 13 Oct 2009, Jeff King wrote: > On Tue, Oct 13, 2009 at 11:20:28PM +0200, Johannes Schindelin wrote: > > > So in my opinion, we should DWIM "git checkout $X" to mean "git checkout > > -b $X refs/remotes/$REMOTE/$X" when there is no ref $X, refs/heads/$X and > > no other refs/remotes/$OTHER/$X. > > The similar suggestion that is less magical is to say something like > "there is no $X; maybe you meant $REMOTE/$X?". At some point, trying to educate the user is not helpful but annoying. If Git already knows what I want, why does it not do it already? _That_ is the question I already hear in my ears. > Is there a reason not to phase in the behavior, to make sure it is not > doing unexpected things? Sure, I have nothing against that. But just insisting on the current behavior, or on some behavior that is not helpful at all, well, is not really clever. Note that I am fully aware that my "git checkout -t origin/master" DWIMery backfired quite badly. So I am in the same boat. > In other words: > > 1. In v1.6.6, find all error-correcting candidates and print them as > a suggestion (similar to what we do with "git foo"). > > 2. Then, if we all agree that it seems to be producing sane results, > the next step is to turn the unambiguous cases into a DWIM (and > leave the ambiguous ones with the "did you mean?" message). > > Because right now I think there are a lot of hypothetical "maybe it > would be less convenient or more confusing in this instance", but we > don't have any data on how often those instances occur, or how actual > users might react. Oh, I do not want to spam the list with user experiences. But I do have not only a faint idea how users react. Thankyouverymuch. > So doing step (1) would be a way of collecting some of that data (will > users say "stupid git, if you knew what I wanted, why didn't you just do > it?" or "stupid git, your suggestion is just confusing me!"). I disagree. It is not about collecting data. We will not get any feedback from the affected people. You know that, I know that. The step (1) would help in the way that it is a smoother transition. Ciao, Dscho -- 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