On Thu, Oct 21 2021, Johannes Schindelin wrote: > 7. Ævar: On switch/restore in particular, there was a recent discussion. > > 1. Ultimately came down to inconsistency with other commands in the same > area > > 2. I gave some suggestions Those suggestions are at: https://lore.kernel.org/git/877dkdwgfe.fsf@xxxxxxxxxxxxxxxxxxx/ copying the most relevant part from that: In summary, I think it should be changed to act like this: |---------------------------+------------------------+---------------------------| | What | Now | New | |---------------------------+------------------------+---------------------------| | Switch | git switch existing | git switch existing | | Error | git switch nonexisting | <no change (errors)> | | Switch with --merge | git switch -m branch | git switch --merge branch | | Create | git switch -c new | git switch -n new | | Create from existing | N/A | git switch -c new [<old>] | | Move & switch to existing | N/A | git switch -m new [<old>] | |---------------------------+------------------------+---------------------------| > 3. Some patches started, there was some trepidation about making changes, > though I was thinking of this patch, i.e. it implements the "-n" option for "git switch": https://lore.kernel.org/git/20210709174310.94209-1-felipe.contreras@xxxxxxxxx/ We could then add the same to "git branch", i.e. "git branch foo" could also be invoked as "git branch -n foo". We'd then need to have a hard change in the semantics of the (experimental) "git switch" commant to make "-c" mean "copy" (like in "git branch"). We'd then reach an end-state where these two commands would behave in the same way for these common options, with the difference being that "branch". Whatever anyone thinks of my specific suggestions there I think that in general we should be trying to aim more towards that in git's UI, even to the point of slowly phasing in deprecations for non-experimental commands. E.g. the "-n" option to "git fetch" comes to mind, which isn't a synonym for "--dry-run", as in most other places. I realize that doing that is hard, e.g. Josh Steadmon has a patch on-list now to add a configurable "inherit" mode to "git branch[1]. I noted in a similar vein as the table above that it would leave us with another inconsistency between "branch" and "checkout"/"switch" in [2]. Does that mean we shouldn't take that patch and others like it until such UX inconsistencies are addressed? I really don't know, but I do think that the most viable path to a better UX for git is to consider its UX more holistically. To the extent that our UX is a mess I think it's mainly because we've ended up with an accumulation of behavior that made sense in isolation at the time, but which when combined presents bad or inconsistent UX to the user. 1. https://lore.kernel.org/git/9628d145881cb875f8e284967e10f587b9f686f9.1631126999.git.steadmon@xxxxxxxxxx/ 2. https://lore.kernel.org/git/87a6j6tbsv.fsf@xxxxxxxxxxxxxxx/
