imyousuf@xxxxxxxxx writes:
> From: Imran M Yousuf <imyousuf@xxxxxxxxxxxxxxxxxxxxxx>
>
> There is a scenario which has been put forward several times in
> discussion over the recurse subcommand and it is that commands chould have
> different arguments for different modules.
>
> For example, one module could want to checkout 'master', while another might want
> to checkout 'work'. The [-a|--customized-argument] argument provides platform
> just for that. Consider the following command and its followup for further info:
>
> git submodule recurse -a checkout
>
> Submodule b is not initialized and skipped
> git submodule recurse a checkout
> Please provide an argument: master
> Press y to provide another arg...
> git checkout master
> Already on branch "master"
> Submodule d is not initialized and skipped
> git submodule recurse . checkout
> Please provide an argument: master
> Press y to provide another arg...
> git checkout master
> Already on branch "master"
Is it only me who finds this UI (and the one 4/5 further introduces)
somewhat clumsy and extremely ugly?
I am almost tempted to suggest going to the extreme and spawn interactive
shell in each repository directory, like this:
toplevel$ git submodule recurse -a
(info) Submodule b is not initialized and skipped
(info) git submodule recurse 'a'
(info) we now give you a shell in that directory. Do whatever you
(info) like and type cntl-D (or "exit") once you are done.
toplevel/a$ git checkout
toplevel/a$ exit
(info) Submodule d is not initialized and skipped
(info) git submodule recurse '.'
(info) we now give you a shell in that directory. Do whatever you
(info) like and type cntl-D (or "exit") once you are done.
toplevel/.$ git checkout
toplevel/.$ exit
(info) git submodule recurse recursion ended.
toplevel$
so that the users can do whatever they want there.
If we want a useful and flexible "recurse", perhaps the only thing we need
to do is a command that lists a submodule directory path, one path at a
time, in optionally different traversal order and depth cutoff, so that
the user can feed it to xargs and do whatever they want to run in there.
--
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
