Kevin Bracey <kevin@xxxxxxxxx> wrote: > On 31/05/2014 08:46, Atsushi Nakagawa wrote: > > `git checkout -B <current-branch-name> <tree-ish>` > > > > This is such an useful notion that I can fathom why there isn't a better, > > first-tier, alternative.q > ... > > I guess in theory using "checkout" allows fancier extra options like > "--merge" and "--patch", but I don't think I've ever used those with > checkout, let alone this mode, where I really do just want a "reset", > with safety checks. It does indeed have those fancier options. However, I just noticed there's even a 'reset --merge'! And like you say, I can't remember ever using 'checkout --merge' together with 'checkout -B'. > The original "git reset --hard" used to be a pretty top-level command. > It was used for aborting merges in particular. But I think it now > stands out as being one of the only really dangerous porcelain > commands, and I can't think of any real workflow it's still useful > for. My thoughts exactly. I think the 'reset --soft/--mixed/--hard' pattern is so ingrained, that many people just don't realize there's a safer alternative. (I've heard work mates on more than one occasion recommending 'reset --hard' as the go-to command for discarding commits.) I believe this is likely because many third party GUI tools just don't support 'reset --keep', and these tools present a "Reset..." dialog with the de facto Soft/Mixed/Hard options. (Even 'gitk' does this.) > Maybe it could now be modified to warn and require "-f" to > overwrite anything in the working tree? If people just forgot about '--hard' and used '--mixed/--keep' for regular cases, '--hard' would effectively be -f. ;) > While digging into this, it seems "git reset --keep" is actually > pretty close to "git checkout -B <current branch>". It certainly won't > lose your workspace file, but unlike checkout it /does /forget what > you've staged, which could be annoying. Maybe that could be modified > to keep the index too? Yes, I didn't realize that 'reset --keep' existed and now I'm feeling a bit silly for asking. The index preservation artefact of 'checkout -B' could be useful, though I can't remember at this point if I've relied on it in the past. The documetation for 'reset --keep' is ambiguous about what happens to index entries of differing files, so modifying it may be an option if there's demand.. I'm going to try out 'reset --keep' for a while and see if it does get annoying. Cheers, -- Atsushi Nakagawa <atnak@xxxxxxxxx> Changes are made when there is inconvenience. -- 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