From: Junio C Hamano <hidden> Date: 2016-06-15 22:44:36
imyousuf@gmail.com writes:
From: Imran M Yousuf <redacted>
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.
From: Johan Herland <hidden> Date: 2016-06-15 22:44:37
On Tuesday 13 May 2008, Junio C Hamano wrote:
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.
Yes! As more and more porcelains on top of the git submodule plumbing is
created, this is definitely something that is (or will be) sorely needed.
...Johan
--
Johan Herland, [off-list ref]
www.herland.net
On Tue, May 13, 2008 at 12:43 AM, Junio C Hamano [off-list ref] wrote:
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.
How about Windows? Do we want to depend on something like
http://gnuwin32.sourceforge.net/packages/findutils.htm or does msysgit
ship with xargs? (Or do we not intend to build internal commands upon
this system and leave using the output of "recurse" to the user?)
--
Cheers,
Sverre Rabbelier
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:44:37
Hi,
On Sun, 18 May 2008, Sverre Rabbelier wrote:
On Tue, May 13, 2008 at 12:43 AM, Junio C Hamano [off-list ref]
wrote:
quoted
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.
How about Windows? Do we want to depend on something like
http://gnuwin32.sourceforge.net/packages/findutils.htm or does msysgit
ship with xargs? (Or do we not intend to build internal commands upon
this system and leave using the output of "recurse" to the user?)
git-repack already relies on "find", and if you have no silly naming
scheme *1*, you do not need "xargs". Besides, we do ship xargs.exe.
Ciao,
Dscho
*1* Oops, this is Windows, right?
From: Imran M Yousuf <hidden> Date: 2016-06-15 22:44:37
On Tue, May 13, 2008 at 4:43 AM, Junio C Hamano [off-list ref] wrote:
quoted
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:
......
.......
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.
I am not sure whether I understand it correctly or not, we could
simply provide the shell window by invoking 'sh', right? If we do that
then is there need to use xargs? I am not particularly experienced
with xargs, I was thinking of something as follows:
#!/bin/sh
echo "Submodule a"
(
PS1="module/submodule$" sh
)
echo "" #In case of ctrl+D to ensure that there is a blank line
echo "Submodule a ends"
I do agree that it would be powerful enough to serve all the necessary
purpose for traversing git submodules. If my assumption is right in
what we want then I will resubmit the patch with required changes.
--
Imran M Yousuf