Re: why doesn't "git reset" mention optional pathspec?

From: Duy Nguyen <pclouds@gmail.com>
Date: Dec 8, 2018, 17:34 UTC
Message-ID: <CACsJy8AC-anZ=EA3zxWeX8UUNcZiKsQMu8x0eCHAOCUjFWoFuQ@mail.gmail.com>
In-Reply-To: <alpine.LFD.2.21.1812081232240.32380@localhost.localdomain>

On Sat, Dec 8, 2018 at 6:32 PM Robert P. J. Day <rpjday@crashcourse.ca> wrote:

Show 23 quoted lines

>
> On Sat, 8 Dec 2018, Duy Nguyen wrote:
>
> > On Sat, Dec 8, 2018 at 5:08 PM Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> > >
> > >
> > >   from "man git-reset":
> > >
> > > SYNOPSIS
> > >   git reset [-q] [<tree-ish>] [--] <paths>...
> > >   git reset (--patch | -p) [<tree-ish>] [--] [<paths>...]
> > >   git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [<commit>]
> > >
> > > oddly, the third form says nothing about possible "<paths>", even
> > > though i'm pretty sure they're valid in that third case (at least
> > > for "--mixed"). thoughts? is that just an oversight in the man
> > > page?
> >
> > --mixed prints a deprecation warning. I don't think it's worth
> > making the synopsis more complicated for that. All other modes
> > reject pathspec.
>
>   i just tested this, and i don't see a deprecation warning.

Hmm.. maybe I misread the code. I just tried it

$ ./git reset --mixed HEAD foo warning: --mixed with paths is deprecated; use 'git reset -- <paths>' instead.

-- 
Duy