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

2013-07-03 Thread Jens Lehmann
Am 03.07.2013 01:26, schrieb Chris Packham:
 On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann jens.lehm...@web.de wrote:
 Am 02.07.2013 12:12, schrieb Chris Packham:
 --- 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

The above hunk is perfectly fine ...

 @@ -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

... but I don't understand the extra '+'-line added here.

 I'm not sure this change is necessary ;-)
 
 Not necessary because it should be documented in
 Documentation/config.txt instead, or not necessary because it's a
 niche feature that doesn't need to be advertised?

Sorry for the confusion, I should have been more specific here.

 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'

 
 Will include in v4 once I write some tests.

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


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

2013-07-03 Thread Chris Packham
On 03/07/13 18:55, Jens Lehmann wrote:
 Am 03.07.2013 01:26, schrieb Chris Packham:
 On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann jens.lehm...@web.de wrote:
 Am 02.07.2013 12:12, schrieb Chris Packham:
 --- 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
 
 The above hunk is perfectly fine ...
 
 @@ -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
 
 ... but I don't understand the extra '+'-line added here.
 
 I'm not sure this change is necessary ;-)

 Not necessary because it should be documented in
 Documentation/config.txt instead, or not necessary because it's a
 niche feature that doesn't need to be advertised?
 
 Sorry for the confusion, I should have been more specific here.
 

Ah that makes sense. It's left over from the '--exec' option in v1. Will
be cleaned up in v4.

On a related note should I be updating Documentation/config.txt as well?
Even if it's a statement that this feature exists refer to
git-submodule(1) for details.

 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'


 Will include in v4 once I write some tests.
 
 Thanks.
 

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


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

2013-07-03 Thread Chris Packham
On 03/07/13 19:54, Chris Packham wrote:
 On a related note should I be updating Documentation/config.txt as well?
 Even if it's a statement that this feature exists refer to
 git-submodule(1) for details.
 

Answering my own question. While 'update' is mentioned it's possible
values are not.

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


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

2013-07-03 Thread Junio C Hamano
Chris Packham judge.pack...@gmail.com writes:

 On 03/07/13 19:54, Chris Packham wrote:
 On a related note should I be updating Documentation/config.txt as well?
 Even if it's a statement that this feature exists refer to
 git-submodule(1) for details.
 

 Answering my own question. While 'update' is mentioned it's possible
 values are not.

Yeah, I think it is good as-is.

The entry in config.txt points at git-submodule(1) and your patch
updates the latter by adding another possible value, so the values
are discoverable; we do not have to maintain two separate lists and
keep them in sync that way.

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


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

2013-07-02 Thread Jens Lehmann
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.pack...@gmail.com
 ---
 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2013-07-02 Thread Chris Packham
On Wed, Jul 3, 2013 at 4:56 AM, Jens Lehmann jens.lehm...@web.de wrote:
 Am 02.07.2013 12:12, schrieb Chris Packham:
 --- 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 ;-)


Not necessary because it should be documented in
Documentation/config.txt instead, or not necessary because it's a
niche feature that doesn't need to be advertised?

 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'


Will include in v4 once I write some tests.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html