Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: >>> It would have been a stronger argument to favor --new if we had "git >>> branch --new <branchname>", but that is not the case. >> >> The argument is that switch's experimental design squats on 2x other >> options, so changing -c to -n so we can make -c and -m do the same thing >> is better. > > Whatever the merit of the argument I'm putting forward here, it would be > useful to get some idea of whether you'd be categorically opposed to > changing the interface of switch/restore in breaking ways even though > they've been marked as "THIS COMMAND IS EXPERIMENTAL". > > Of course any series to implement what I suggested in > <877dkdwgfe.fsf@xxxxxxxxxxxxxxxxxxx> would need to stand on its own > merits. > > I'm not planning on working on that since I expect the response will be > at best "neat, but that ship has sailed", but if that's not the case... cf. <xmqqzgx81x2q.fsf@gitster.g> "Randall S. Becker" <rsbecker@xxxxxxxxxxxxx> writes: >>Which leaves us with two hard choices regarding switch/restore, none of them >>really being comfortable: >> >>- we scrap switch/restore because their usability is not really all that >> improved relative to `git checkout`. > > Please do not do that. Switch/restore is much easier to understand > for new users. The semantics are also more consistent with what > others have done with git over the years anyway (EGit as an > example). I have users who have transitioned because the commands > make sense. They have not hit any missing bits in their workflows. > >>- we leave switch/restore as-are (because by now, changing the options or >> the design would be almost certainly disruptive to users who already >> tried to adopt the new commands, I being one of those users). > > I think we should work on the commands to cover between them > (well... and reset) to functionally cover what checkout > does. Leaving them as-is, I think is not a viable option. People > do know these are experimental and not to use in scripts - we can > hope anyway. Yeah, I tend to agree with you that the third-choice to improve switch/restore before we can confidently say they are no longer "experimental" would be much nicer than giving up on them too early.
