Re: [PATCH 5/8] submodule API & "absorbgitdirs": remove "----recursive" option

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

 



Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:

> Remove the "----recursive" option to "git submodule--helper
> absorbgitdirs" (yes, with 4 dashes, not 2).

o.O

At least this makes it pretty easy to grep for usage, and it makes sense
that we've never used it (otherwise this would've been caught).

> diff --git a/submodule.c b/submodule.c
> index fe1e3f03905..8fa2ad457b2 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -2332,8 +2331,7 @@ static void absorb_git_dir_into_superproject_recurse(const char *path)
>   * having its git directory within the working tree to the git dir nested
>   * in its superprojects git dir under modules/.
>   */
> -void absorb_git_dir_into_superproject(const char *path,
> -				      unsigned flags)
> +void absorb_git_dir_into_superproject(const char *path)
>  {
>  	int err_code;
>  	const char *sub_git_dir;
> @@ -2382,12 +2380,7 @@ void absorb_git_dir_into_superproject(const char *path,
>  	}
>  	strbuf_release(&gitdir);
>  
> -	if (flags & ABSORB_GITDIR_RECURSE_SUBMODULES) {
> -		if (flags & ~ABSORB_GITDIR_RECURSE_SUBMODULES)
> -			BUG("we don't know how to pass the flags down?");
> -
> -		absorb_git_dir_into_superproject_recurse(path);
> -	}
> +	absorb_git_dir_into_superproject_recurse(path);
>  }

Maybe I'm misreading, but I don't follow this change.

Before, we recursed into the submodule only if the
ABSORB_GITDIR_RECURSE_SUBMODULES flag is set (which we now know is
never), but now we unconditionally recurse into the submodule.

Wouldn't it be more accurate to get rid of this recursing behavior
altogether? i.e. drop the previous patch and delete that code when we
delete this conditional.




[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