Re: Reset by checkout?
- From
- Atsushi Nakagawa <atnak@chejz.com>
- Date
- Jun 1, 2014, 04:26 UTC
- Message-ID
- <20140601132624.821C.B013761@chejz.com>
- In-Reply-To
- <53898448.8040105@bracey.fi>
Kevin Bracey <kevin@bracey.fi> wrote:
Show 11 quoted lines
> 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'.
Show 5 quoted lines
> 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. ;)
Show 5 quoted lines
> 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@chejz.com> Changes are made when there is inconvenience.