From: Jonathan Nieder <jrnieder@gmail.com>
To: Stefan Beller <sbeller@google.com>
Cc: gitster@pobox.com, git@vger.kernel.org, Jens.Lehmann@web.de
Subject: Re: [PATCHv4] submodule deinit: require '--all' instead of '.' for all submodules
Date: Wed, 4 May 2016 16:26:42 -0700 [thread overview]
Message-ID: <20160504232642.GC395@google.com> (raw)
In-Reply-To: <1462401603-2067-1-git-send-email-sbeller@google.com>
Hi,
Stefan Beller wrote:
> Signed-off-by: Stefan Beller <sbeller@google.com>
> ---
> * reworded commit message slightly (realize, pathspec)
> * reworded the documentation
Yay, thanks for your work on this.
[...]
> +++ b/Documentation/git-submodule.txt
> @@ -13,7 +13,7 @@ SYNOPSIS
> [--reference <repository>] [--depth <depth>] [--] <repository> [<path>]
> 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
> 'git submodule' [--quiet] init [--] [<path>...]
> -'git submodule' [--quiet] deinit [-f|--force] [--] <path>...
> +'git submodule' [--quiet] deinit [-f|--force] (-a|--all|[--] <path>...)
> 'git submodule' [--quiet] update [--init] [--remote] [-N|--no-fetch]
> [-f|--force] [--rebase|--merge] [--reference <repository>]
> [--depth <depth>] [--recursive] [--] [<path>...]
> @@ -140,12 +140,20 @@ deinit::
> tree. Further calls to `git submodule update`, `git submodule foreach`
> and `git submodule sync` will skip any unregistered submodules until
> they are initialized again, so use this command if you don't want to
> - have a local checkout of the submodule in your work tree anymore. If
> + have a local checkout of the submodule in your working tree anymore. If
> you really want to remove a submodule from the repository and commit
> that use linkgit:git-rm[1] instead.
> ++
> +When the command is run without pathspec, it errors out,
> +instead of deinit-ing everything, to prevent mistakes. In
> +version 2.8 and before the command gave a suggestion to use
> +'.' to unregister all submodules when it was invoked without
> +any argument, but this suggestion did not work and gave a
> +wrong message if you followed it in pathological cases and is
> +no longer recommended.
Why tell the user what happened in 2.8 and earlier? It's not clear what
the reader would do with that information.
I think this paragraph could be removed. --all is explained lower
down and the error message points it out to users who need it.
> +
> -If `--force` is specified, the submodule's work tree will be removed even if
> -it contains local modifications.
> +If `--force` is specified, the submodule's working tree will
> +be removed even if it contains local modifications.
(unnecessary rewrapping)
[...]
> update::
> +
> @@ -247,6 +255,11 @@ OPTIONS
> --quiet::
> Only print error messages.
>
> +-a::
> +--all::
> + This option is only valid for the deinit command. Unregister all
> + submodules in the working tree.
This could use an explanation of why I'd want to use it. E.g.
This option is only valid for the deinit command. Unregister all
submodules. Scripts should use this option instead of passing '.'
to deinit because it works even in an empty repository with no
submodules present.
Not about this patch: the organization of options is a little strange.
A separate section with options for each subcommand would be easier to
read.
Do we want to claim the short-and-sweet option -a? (I don't mind but it
doesn't seem necessary.)
[...]
> @@ -257,8 +270,8 @@ OPTIONS
> --force::
> This option is only valid for add, deinit and update commands.
> When running add, allow adding an otherwise ignored submodule path.
> - When running deinit the submodule work trees will be removed even if
> - they contain local changes.
> + When running deinit the submodule working trees will be removed even
> + if they contain local changes.
Unrelated change?
[...]
> @@ -544,9 +548,13 @@ cmd_deinit()
> shift
> done
>
> - if test $# = 0
> + if test -n "$deinit_all" && test "$#" -ne 0
> + then
> + die "$(eval_gettext "--all and pathspec are incompatible")"
This message still feels too low-level to me, but I might be swimming
uphill here.
Another option would be to call 'usage' and be done.
[...]
> --- a/t/t7400-submodule-basic.sh
> +++ b/t/t7400-submodule-basic.sh
Makes sense.
In the context of the original motivation: this patch improves the
advice printed by plain "git submodule deinit" but doesn't help with
existing callers that might have run "git submodule deinit .". It might
make sense to handle '.' as a historical special case in a separate
patch.
Thanks and sorry for all the complication,
Jonathan
next prev parent reply other threads:[~2016-05-04 23:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-04 22:40 [PATCHv4] submodule deinit: require '--all' instead of '.' for all submodules Stefan Beller
2016-05-04 23:08 ` Junio C Hamano
2016-05-04 23:26 ` Jonathan Nieder [this message]
2016-05-04 23:38 ` Stefan Beller
2016-05-04 23:59 ` Jonathan Nieder
2016-05-05 18:03 ` Junio C Hamano
2016-05-05 19:20 ` Jonathan Nieder
2016-05-05 19:35 ` Stefan Beller
2016-05-05 19:02 ` Stefan Beller
2016-05-05 17:59 ` Junio C Hamano
2016-05-05 18:11 ` Stefan Beller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160504232642.GC395@google.com \
--to=jrnieder@gmail.com \
--cc=Jens.Lehmann@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sbeller@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).