Message ID | 20190130094831.10420-1-pclouds@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Add new command "switch" | expand |
On Wed, Jan 30, 2019 at 04:48:12PM +0700, Nguyễn Thái Ngọc Duy wrote: > The > only one left is adding options similar to "git reset" (but with > better names this time than --soft and --hard, hopefully). Oh no, what for?! As the commit message or patch 19/19 'doc: promote "git switch"' states: The new command "git switch" is added to avoid the confusion of one-command-do-all "git checkout" for new users. Adding '--soft|--hard' from 'git reset' would go in the opposite direction.
On Thu, Jan 31, 2019 at 8:37 PM SZEDER Gábor <szeder.dev@gmail.com> wrote: > > On Wed, Jan 30, 2019 at 04:48:12PM +0700, Nguyễn Thái Ngọc Duy wrote: > > The > > only one left is adding options similar to "git reset" (but with > > better names this time than --soft and --hard, hopefully). > > Oh no, what for?! As the commit message or patch 19/19 'doc: promote > "git switch"' states: > > The new command "git switch" is added to avoid the confusion of > one-command-do-all "git checkout" for new users. > > 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. What I have in mind so far is this, let's see if it's so bad so I can find another direction. git switch --reset-branch [--keep-index] [--keep-worktree] [<commit>] This updates worktree and index to <commit> and "rewinds" the current branch to <commit>. If either of those --keep-* is given, that part will be left untouched. So "git reset --hard" is the same as "git switch --reset-branch", --soft "--reset-branch --keep-index --keep-worktree" and --mixed "--reset-branch --keep-worktree". I've been updating docs with this new format to see what it looks like and I think it expresses the idea behind git-reset much better.
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes: > This is the first half of the previous "switch-branch and > restore-files" RFC series [1]. I only focus on switch-branch for now > because it's already getting long and I still have some work to do on > restore-files. Exciting ;-) This will probably become the best UI improvement in the past few years.
Duy Nguyen <pclouds@gmail.com> 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"). 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).
On Fri, Feb 1, 2019 at 1:23 AM Junio C Hamano <gitster@pobox.com> wrote: > > Duy Nguyen <pclouds@gmail.com> 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.