On Sun, Aug 15, 2010 at 18:36, Junio C Hamano <gitster@xxxxxxxxx> wrote: > What if we: > > - change "reset --hard [<commit>] -- <pathspec>" to internally run the > moral equivalent "checkout" without complaining; > > - change "reset --mixed [<commit>] -- <pathspec>" to do the same thing as > it has always done without complaining; and > > - make sure "reset --soft [<commit>] -- <pathspec>" barfs loudly. > > Do people see major downside? Generally I'd like to see Git move towards have a more internally consistent UI and less warts. Doing what you suggest would make git-reset(1) more internally consistent, while duplicating the git-checkout functionality. So it's a question of whether git-reset should do all reset-y things without complaining, even when that infringes on git-checkout's domain. I don't know which should be picked, but it's something to consider. One thing I'd like to see is some documentation showing how we'd like Git to act if we didn't have to worry about backwards compatibility. I sometimes see little warts like mixing of cached/index/stage, but I haven't seen any plan for these sort of things. Are we planning to change some of these things in the future? If so when, and what should be changed? It's hard to say whether a UI change like this makes sense without the bigger picture. -- 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