Re: [RFC 2/2] Don't push a repository with unpushed submodules

[Junio C Hamano <gitster@pobox.com>]

Fredrik Gustafsson <iveqy@iveqy.com> writes:

> +static int is_submodule_commit_pushed(const char *path, const unsigned char sha1[20])
> +{
> +	int is_pushed = 0;
> +	if (!add_submodule_odb(path) && lookup_commit_reference(sha1)) {
> +		struct child_process cp;
> +		const char *argv[] = {"rev-list", NULL, "--not", "--remotes", "-n", "1" , NULL};
> +		struct strbuf buf = STRBUF_INIT;
> +
> +		argv[1] = sha1_to_hex(sha1);
> +		memset(&cp, 0, sizeof(cp));
> +		cp.argv = argv;
> +		cp.env = local_repo_env;
> +		cp.git_cmd = 1;
> +		cp.no_stdin = 1;
> +		cp.out = -1;
> +		cp.dir = path;
> +		if (!run_command(&cp) && !strbuf_read(&buf, cp.out, 41))
> +			is_pushed = 1;
> +		close(cp.out);
> +		strbuf_release(&buf);
> +	}

What if

 (1) you are binding somebody else's project as your own submodule, you do
     not make any local changes (you won't be pushing them out anyway),
     and you do not have remote tracking branches in that submodule
     project?

 (2) you have a project you can push to that is bound as a submodule, you
     have pushed the commit that is bound in the superproject's tree to
     that submodule project, but you do not have remote tracking branches
     in that submodule project?

 (3) you have a project you can push to that is bound as a submodule, you
     have multiple remotes defined (e.g. one for the public server you
     intend for this check to be in effect, the other is just for your
     private backup), and you have pushed the necessary commit to your
     backup but not to the public one?

The above check would fail in cases (1) and (2) even though it does not
have to. It would succeed in case (3), but people would not be able to use
the superproject as the necessary commit is not there but only on your
work and backup repositories.

What am I missing?

I am not sure if the check imposed on the client end is such a great
idea. I suspect that it would depend on the superproject which submodule
commit must exist "out there" for others to fetch. If you assume a closed
environment where all the superprojects and necessary submodule projects
are housed at a central location everybody pushes into and have tight
control over how project participants clone and check out the
superprojects and submodules, you do not have to worry about any of the
above, but then the server-side can perform the check when it accepts a
push (and you would already be doing other checks there in your hooks
anyway in the industrial setup, I would guess).