Re: [PATCH v4 4/4] submodule_needs_pushing() NEEDSWORK when we can not answer this question

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

 



Heiko Voigt <hvoigt@xxxxxxxxxx> writes:

> Signed-off-by: Heiko Voigt <hvoigt@xxxxxxxxxx>
> ---

Needs retitle ;-)  Here is what I tentatively queued.

    submodule_needs_pushing(): explain the behaviour when we cannot answer
    
    When we do not have commits that are involved in the update of the
    superproject in our copy of submodule, we cannot tell if the remote
    end needs to acquire these commits to be able to check out the
    superproject tree.  Explain why we answer "no there is no need/point
    in pushing from our submodule repository" in this case.
    
    Signed-off-by: Heiko Voigt <hvoigt@xxxxxxxxxx>
    Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>

>  submodule.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/submodule.c b/submodule.c
> index 11391fa..00dd655 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -531,6 +531,17 @@ static int submodule_has_commits(const char *path, struct sha1_array *commits)
>  static int submodule_needs_pushing(const char *path, struct sha1_array *commits)
>  {
>  	if (!submodule_has_commits(path, commits))
> +		/*
> +		 * NOTE: We do consider it safe to return "no" here. The
> +		 * correct answer would be "We do not know" instead of
> +		 * "No push needed", but it is quite hard to change
> +		 * the submodule pointer without having the submodule
> +		 * around. If a user did however change the submodules
> +		 * without having the submodule around, this indicates
> +		 * an expert who knows what they are doing or a
> +		 * maintainer integrating work from other people. In
> +		 * both cases it should be safe to skip this check.
> +		 */
>  		return 0;
>  
>  	if (for_each_remote_ref_submodule(path, has_remote, NULL) > 0) {



[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]