On Fri, Feb 1, 2019 at 1:23 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Duy Nguyen <pclouds@xxxxxxxxx> writes: > > >> Adding '--soft|--hard' from 'git reset' would go in the opposite > >> direction. > > > > If it's about the confusion, I think we can avoid it. If it's about > > the one-command-do-all, I think it still fits in the main topic of > > git-switch, which is about switching. But in git-reset case it's > > switching HEAD, not a normal branch. > > I do not think "switch branch" should update HEAD for the branch. > Let it be handled by "reset" (or "branch -f that-other-branch"). It can already, it's simply a shortcut for "git switch --force-create <current-branch> -f <commit>" (or "git checkout -fB <current-branch> <commit>"), at least for --hard. --mixed and --soft is just a different variant of "-f". > I personally did not have "it is way too overloaded" problem with > "checkout", but it turns out that many others found it so. You'll > see the same happen for your "switch" if you do not resist > temptation to add unrelated things (or things you may find related > but you see others find unrelated even in this early discussion). The thing about git-reset is it's also overloaded with updating things other than HEAD. All the pathspec form is the same as checkout/restore (except checkout updates both index/worktree while reset is more about index; but restore can cover all index/worktree combination). But yeah maybe just leave it for now. While trying to document the new option in switch to replace reset, the verb "rewind" (the tip of the current branch) seems fitting well. I might revisit this topic with git-rewind or something. -- Duy
