On Sat, May 12, 2018 at 08:23:32PM -0600, Dannier Castro L wrote: > Currently, <checkout> is a complex command able to handle both > branches and files without any distintion other than their names, > taking into account that depending on the type (branch or file), > the functionality is completely different, the easier example: > > $ git checkout <branch> # Switch from current branch to <branch>. > $ git checkout <file> # Restore <file> from HEAD, discarding > # changes if it's necessary. > $ git checkout -- <file> # The same as the last one, only with an > # useless '--'. > > For GIT new users, this complicated versatility of <checkout> could > be very confused, also considering that actually the flag '--' is > completely useless (added or not, there is not any difference for > this command), when the same program messages promote the use of > this flag. > > Regarding the <checkout>'s power to overwrite any file, discarding > changes if they exist without some way of recovering them, the > solution propuses that the usage of '--' is strict before to > specify the file(s) path(s) for any <checkout> command (including > all types of flags), as a "defense barrier" to make sure about > user's knowledge and intension running <checkout>. > > The solution consists in detect '--' into command args, allowing > the discard of changes and considering the following names as > file paths, otherwise, they are branch names. > > Signed-off-by: Dannier Castro L <danniercl@xxxxxxxxx> One data point indicating this is giving issues is that today on IRC a user was confused why `git checkout pt` did not show any message and did not checkout a remote branch called 'pt' as they expected. It turned out they also had a local file/dir called 'pt', which caused git to checkout that file/dir rather than creating a local branch based on the remote branch. Kevin
