Re: [RFC/PATCHv3] submodule update: allow custom update command

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

 



Am 02.07.2013 12:12, schrieb Chris Packham:
> Users can set submodule.$name.update to '!command' which will cause
> 'command' to be run instead of checkout/merge/rebase.  This allows the
> user some finer grained control over how the update is done. The primary
> motivation for this was interoperability with stgit however being able
> to intercept the submodule update process may prove useful for
> integrating or extending other tools.
> 
> Signed-off-by: Chris Packham <judge.packham@xxxxxxxxx>
> ---
> v3 updated as per Junio's review.

Thanks, a few comments below.

> Still needs tests. Any suggestions? I've been manually testing by setting
> submodule.$name.update to '!echo'. I haven't looked to see if there are
> existing 'submodule update' tests yet.

t7406-submodule-update.sh should be the right place.

>  Documentation/git-submodule.txt | 5 ++++-
>  git-submodule.sh                | 6 ++++++
>  2 files changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
> index e576713..0befc20 100644
> --- a/Documentation/git-submodule.txt
> +++ b/Documentation/git-submodule.txt
> @@ -159,7 +159,9 @@ update::
>  	This will make the submodules HEAD be detached unless `--rebase` or
>  	`--merge` is specified or the key `submodule.$name.update` is set to
>  	`rebase`, `merge` or `none`. `none` can be overridden by specifying
> -	`--checkout`.
> +	`--checkout`. Setting the key `submodule.$name.update` to `!command`
> +	will cause `command` to be run. `command` can be any arbitrary shell
> +	command that takes a single argument, namely the sha1 to update to.
>  +
>  If the submodule is not yet initialized, and you just want to use the
>  setting as stored in .gitmodules, you can automatically initialize the
> @@ -172,6 +174,7 @@ If `--force` is specified, the submodule will be checked out (using
>  `git checkout --force` if appropriate), even if the commit specified in the
>  index of the containing repository already matches the commit checked out in
>  the submodule.
> ++
>  
>  summary::
>  	Show commit summary between the given commit (defaults to HEAD) and

I'm not sure this change is necessary ;-)

> diff --git a/git-submodule.sh b/git-submodule.sh
> index eb58c8e..a7c2375 100755
> --- a/git-submodule.sh
> +++ b/git-submodule.sh
> @@ -799,6 +799,12 @@ Maybe you want to use 'update --init'?")"
>  				say_msg="$(eval_gettext "Submodule path '\$prefix\$sm_path': merged in '\$sha1'")"
>  				must_die_on_failure=yes
>  				;;
> +			!*)
> +				command="${update_module#!}"
> +				die_msg="$(eval_gettext "Unable to exec '\$command \$sha1' in submodule path '\$prefix\$sm_path'")"

Hmm, "Unable to exec" does not quite cut it, as the command was executed
but returned an error, right? Maybe something like this:

   Execution of '\$command \$sha1' failed in submodule  path '\$prefix\$sm_path'

> +				say_msg="$(eval_gettext "Submodule path '\$prefix\$sm_path': '\$command \$sha1'")"
> +				must_die_on_failure=yes
> +				;;
>  			*)
>  				command="git checkout $subforce -q"
>  				die_msg="$(eval_gettext "Unable to checkout '\$sha1' in submodule path '\$prefix\$sm_path'")"
> 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




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