On Mon, Aug 16, 2010 at 00:59, Miles Bader <miles@xxxxxxx> wrote: > On Mon, Aug 16, 2010 at 5:51 AM, Ævar Arnfjörð Bjarmason > <avarab@xxxxxxxxx> wrote: >> 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. > > Of course one question is: why is this "git-checkout's domain" in the > first place? > > From a UI perspective this functionality doesn't seem to make any more > sense in checkout -- and perhaps _less_ -- than it does in git-reset. > "git-checkout <path>" seems like a tacked-on-to-make-cvs-users-happy > wart rather than a natural part of git-checkout. > > I know that as a beginning git user, I always tried to use "git-reset > --hard <path>", because that sort of made sense in my mental model of > git commands, only to be confused when it didn't work. The fact that > one actually needed to to do git-checkout instead was confusing. Yeah, maybe one command to reset a file to various states makes more sense than a singular "checking it out". Anyway, this is the sort of thing I was alluding to, it won't do to make micro-changes to the UI without considering 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