Re: [PATCH] diff: allow --recurse-submodules as an synonym for --submodule

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 6, 2018 at 2:12 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
>
> > It seems like various commands are gaining --recurse-submodules options
> > taking different kinds of arguments:
> >
> > - clone takes --recurse-submodules=<pathspec>
> > - fetch takes --recurse-submodules=<mode>
> > - after this patch, diff takes --recurse-submodules=<mode>
> >
> > Is there a unifying principle?  Can Documentation/gitsubmodules.txt
> > say a word or two about what kind of argument values the user should
> > expect to be accepted by these options?
>
> I am not sure if the above is rhetorical.  The only thing such a
> document can say about status-quo is that the user cannot make an
> educated guess, as there is no consistency.  Some take an option to
> clarify which subset of submodules to act on, others take an option
> to specify what variant of operation to be made on the submodules.
>
> In the ideal world, the users ought to be able to give these two
> independently, i.e. "fetch" should be able to say "only fetch these
> submodules" with pathspec while "run the fetch in all of these
> submodules specified (with the pathspec) as necessary" with
> "on-demand" mode, for example.
>
> It may mean that it is too early to add "diff --recurse-submodules"
> as a synonym for "diff --submodule", before what we can do to
> improve the situation for commands that already take that
> "--recurse-submodules" option.

Good point. So let's retreat that patch for now?

Stefan



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux