git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Prathamesh Chavan <pc44800@gmail.com>
Cc: git@vger.kernel.org, sbeller@google.com, christian.couder@gmail.com
Subject: Re: [PATCH v1 2/2] submodule: port submodule subcommand 'deinit' from shell to C
Date: Tue, 09 Jan 2018 13:24:29 -0800
Message-ID: <xmqq7esq4tf6.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20180109175703.4793-3-pc44800@gmail.com>

Prathamesh Chavan <pc44800@gmail.com> writes:

> The same mechanism is used even for porting this submodule
> subcommand, as used in the ported subcommands till now.
> The function cmd_deinit in split up after porting into four
> functions: module_deinit(), for_each_listed_submodule(),
> deinit_submodule() and deinit_submodule_cb().
>
> Mentored-by: Christian Couder <christian.couder@gmail.com>
> Mentored-by: Stefan Beller <sbeller@google.com>
> Signed-off-by: Prathamesh Chavan <pc44800@gmail.com>
> ---
>  builtin/submodule--helper.c | 153 ++++++++++++++++++++++++++++++++++++++++++++
>  git-submodule.sh            |  55 +---------------
>  2 files changed, 154 insertions(+), 54 deletions(-)
>
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index dd7737acd..54b0e46fc 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -20,6 +20,7 @@
>  #define OPT_QUIET (1 << 0)
>  #define OPT_CACHED (1 << 1)
>  #define OPT_RECURSIVE (1 << 2)
> +#define OPT_FORCE (1 << 3)
>  
>  typedef void (*each_submodule_fn)(const struct cache_entry *list_item,
>  				  void *cb_data);
> @@ -908,6 +909,157 @@ static int module_sync(int argc, const char **argv, const char *prefix)
>  	return 0;
>  }
>  
> +struct deinit_cb {
> +	const char *prefix;
> +	unsigned int flags;
> +};
> +#define DEINIT_CB_INIT { NULL, 0 }
> +
> +static void deinit_submodule(const char *path, const char *prefix,
> +			     unsigned int flags)
> +{
> +	const struct submodule *sub;
> +	char *displaypath = NULL;
> +	struct child_process cp_config = CHILD_PROCESS_INIT;
> +	struct strbuf sb_config = STRBUF_INIT;
> +	char *sub_git_dir = xstrfmt("%s/.git", path);
> +	mode_t mode = 0777;
> +
> +	sub = submodule_from_path(&null_oid, path);
> +
> +	if (!sub || !sub->name)
> +		goto cleanup;
> +
> +	displaypath = get_submodule_displaypath(path, prefix);
> +
> +	/* remove the submodule work tree (unless the user already did it) */
> +	if (is_directory(path)) {
> +		struct stat st;
> +		/*
> +		 * protect submodules containing a .git directory
> +		 * NEEDSWORK: automatically call absorbgitdirs before
> +		 * warning/die.
> +		 */

I guess that you mean "instead of dying, automatically call absorb
and (possibly) warn"?  That sounds like a sensible improvement.

> +		if (is_directory(sub_git_dir))
> +			die(_("Submodule work tree '%s' contains a .git "
> +			      "directory use 'rm -rf' if you really want "
> +			      "to remove it including all of its history"),

This changes the message text by removing () around "use ... history",
which I do not think you intended to do.

> +			      displaypath);
> +
> +		if (!(flags & OPT_FORCE)) {
> +			struct child_process cp_rm = CHILD_PROCESS_INIT;
> +			cp_rm.git_cmd = 1;
> +			argv_array_pushl(&cp_rm.args, "rm", "-qn",
> +					 path, NULL);
> +
> +			if (run_command(&cp_rm))
> +				die(_("Submodule work tree '%s' contains local "
> +				      "modifications; use '-f' to discard them"),
> +				      displaypath);
> +		}
> +
> +		if (!lstat(path, &st)) {

What is this if statement doing here?  It does not make sense,
especially without an 'else' clause on the other side, at least to
me.

At this point in the flow, the code has already determined that path
is a directory above before starting to check if it has ".git/"
immediately below it, or trying to run "git rm" in the dry run mode
to see if it yields an error, so at this point lstat() should
succeed (and would say it is a directory).  I would sort-of
understand it if this "if()" has an "else" clause to act on an
error, but that is not something the original does not do, so I am
not sure if it belongs to a "rewrite to C" patch.

> +			struct strbuf sb_rm = STRBUF_INIT;
> +			const char *format;
> +
> +			strbuf_addstr(&sb_rm, path);
> +
> +			if (!remove_dir_recursively(&sb_rm, 0))
> +				format = _("Cleared directory '%s'\n");
> +			else
> +				format = _("Could not remove submodule work tree '%s'\n");
> +
> +			if (!(flags & OPT_QUIET))
> +				printf(format, displaypath);
> +
> +			mode = st.st_mode;
> +
> +			strbuf_release(&sb_rm);
> +		}
> +	}

If the reason is "avoid losing the original directory mode by
removing and recreating", then you should be able to do much better
by using REMOVE_DIR_KEEP_TOPLEVEL in the above "do we still have a
directory?  if so get rid of working tree contents" thing.  And the
call to mkdir() below can be placed in the else clause of that
check, i.e. "the user has removed the directory as well, but there
should be an empty directory even for a de-initialized submodule"
side of this.

That of course does not have to be part of "rewrite to C" patch.  In
fact, it probably should come as a follow-up improvement after the
dust settles.

> +	if (mkdir(path, mode))
> +		die_errno(_("could not create empty submodule directory %s"),
> +		      displaypath);
> + ...
> +
> +static int module_deinit(int argc, const char **argv, const char *prefix)
> +{
> +...
> +	if (module_list_compute(argc, argv, prefix, &pathspec, &list) < 0)
> +		BUG("module_list_compute should not choke on empty pathspec");
> +...
> +	if (all && argc) {
> +		error("pathspec and --all are incompatible");
> +		usage_with_options(git_submodule_helper_usage,
> +				   module_deinit_options);
> +	}
> +
> +	if (!argc && !all)
> +		die(_("Use '--all' if you really want to deinitialize all submodules"));

Shouldn't these two checks come before we call module_list_compute()?  

> +
> +	for_each_listed_submodule(&list, deinit_submodule_cb, &info);
> +
> +	return 0;
> +}

  reply index

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 17:57 [PATCH v1 0/2] Incremental rewrite of git-submodules Prathamesh Chavan
2018-01-09 17:57 ` [PATCH v1 1/2] submodule: port submodule subcommand 'sync' from shell to C Prathamesh Chavan
2018-01-09 20:57   ` Junio C Hamano
2018-01-09 17:57 ` [PATCH v1 2/2] submodule: port submodule subcommand 'deinit' " Prathamesh Chavan
2018-01-09 21:24   ` Junio C Hamano [this message]
2018-01-10 20:22     ` Prathamesh Chavan
2018-01-10 21:47       ` Junio C Hamano
2018-01-09 19:25 ` [PATCH v1 0/2] Incremental rewrite of git-submodules Stefan Beller
2018-01-09 20:06 ` Brandon Williams
2018-01-11 20:17 ` [PATCH v2 " Prathamesh Chavan
2018-01-11 20:17   ` [PATCH v2 1/2] submodule: port submodule subcommand 'sync' from shell to C Prathamesh Chavan
2018-01-11 20:31     ` Junio C Hamano
2018-01-11 20:17   ` [PATCH v2 2/2] submodule: port submodule subcommand 'deinit' " Prathamesh Chavan
2018-01-11 20:48     ` Junio C Hamano
2018-01-11 20:37   ` [PATCH v2 0/2] Incremental rewrite of git-submodules Junio C Hamano
2018-01-14 21:15   ` [PATCH v3 " Prathamesh Chavan
2018-01-14 21:15     ` [PATCH v3 1/2] submodule: port submodule subcommand 'sync' from shell to C Prathamesh Chavan
2018-01-14 21:15     ` [PATCH v3 2/2] submodule: port submodule subcommand 'deinit' " Prathamesh Chavan
2018-01-16 19:32     ` [PATCH v3 0/2] Incremental rewrite of git-submodules Junio C Hamano

Reply instructions:

You may reply publically 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq7esq4tf6.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pc44800@gmail.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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox