Hi Duy
On 11/03/2019 11:47, Duy Nguyen wrote:
On Mon, Mar 11, 2019 at 6:16 PM Phillip Wood <phillip.wood123@xxxxxxxxx> wrote:
Hi Duy
On 08/03/2019 09:57, Nguyễn Thái Ngọc Duy wrote:
"git checkout" doing too many things is a source of confusion for many
users (and it even bites old timers sometimes). To remedy that, the
command will be split into two new ones: switch and
something-to-checkout-paths.
I think this is a good idea, thanks for working on it. I wonder if it
would be a good idea to have the new command refuse to checkout a new
branch if there is a cherry-pick/revert/merge/rebase in progress (with
an option to override the check) as switching branches in the middle of
one of those is likely to be confusing to users (if I do it it is
normally because I've forgotten that I've not run 'git whatever
--continue').
Interesting. I think this would be a good default if we have an escape
hatch (which could even come later). I often wander off to some other
branch and go back. But then half the time I end up forgetting I'm in
a middle of something and just "git rebase --quit" :P
Of course with git-stash (*) and git-worktree, I guess there's little
reason to just switch away from a something-in-progress worktree. I'll
try to implement this in the next round, unless someone objects.
(*) I hope git-stash remembers and restores "something-in-progress"
status. Dunno. Never used it much.
I don't think it does. For rebase it's non trivial as it needs to
remember the refs under refs/rewritten and stop gc from collecting any
of them or the original head (in theory the todo list can contain
commits that the user has added from other branches as well so they'd
also need to be protected from gc). For cherry-pick there are gc issues
as well.
Best Wishes
Phillip
+-C <new-branch>::
+--force-create <new-branch>::
+ Similar to `--create` except that if `<new-branch>` already
+ exists, it will be reset to `<start-point>`. This is a
+ convenient shortcut for:
If we're renaming the options to be more meaningful then maybe we should
consider a different name for this one - it has nothing to do with
creating a branch. Maybe --reset or --update?
-C can also create a new branch like -c though. --reset or --update
does not convey that (and --update sounds a bit too safe). Another
option is --recreate.
+-f::
+--force::
+ Proceed even if the index or the working tree differs from
+ HEAD. Both the index and working tree are restored to match
+ the switching target. This is used to throw away local
+ changes.
I'd always thought that --force meant "throw away my local changes if
they conflict with the new branch" not "throw them away regardless"
(which is better as it is deterministic). Maybe we can come up with a
clearer name here --discard-changes? At the moment --force does not
throw away conflicts properly (see the script below in my comments about
--merge).
Yeah if you want to redefine --force, now is a very good time.
Personally I'd rather have separate options than the "one catch all"
--force (or worse, multiple of --force). I'll leave this for the
community to decide.
Adding Elijah too. He also had some concern about "git restore
--force". Maybe he's interested in this as well.
