On Wed, Nov 23, 2011 at 6:00 PM, Philippe Vaucher <philippe.vaucher@xxxxxxxxx> wrote: >> In any case, I think your proposal makes it even worse than the current >> state, and you should aim higher. > > Why worse? I'd understand if you said it's doesn't improve it enough > for it to be worth the change tho. I think that's what "you should aim higher" means. > Anyway, my proposal was to get a discussion going, and I'm all for > aiming higher if there's a way. What do you propose instead? You > seemed to imply we'd remove --soft and --merge, and make --keep as an > option for --hard but named differently, something like > --keep-changes. Maybe I didn't fully understand. I think there are too many scripts dependent on these switches to remove them. But I love the direction you're going in. Aim higher. > Mathieu even suggested that it'd have the behavior of --keep by > default, and that you have to add --force to get today's --hard > behavior, which sounds like a good idea to me (avoid destructive > behavior by default). Think outside the "reset" command. Like this: >From the "most popular" comment on http://progit.org/2011/07/11/reset.html: > I remember them as: > --soft -> git uncommit > --mixed -> git unadd > --hard -> git undo I don't particular like these names, but conceptually they are helpful. What other commands can we embellish or create to replace the overload git-reset functionality? How about: --soft: git checkout -B <commit> --mixed: git reset -- <paths> --hard: git checkout --clean Phil -- 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