From: Junio C Hamano <gitster@pobox•com>
To: Jonathan Nieder <jrnieder@gmail•com>
Cc: Lars Hjemli <hjemli@gmail•com>, git@vger•kernel.org
Subject: Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
Date: Mon, 28 Jan 2013 09:45:46 -0800 [thread overview]
Message-ID: <7vham1xktx.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20130128081006.GA2434@elie.Belkin> (Jonathan Nieder's message of "Mon, 28 Jan 2013 00:10:06 -0800")
Jonathan Nieder <jrnieder@gmail•com> writes:
> Tracing backwards: it would be really nice to be able to do
>
> git for-each-repo git grep -e foo -- '*.c'
This is a very good example that shows the command that is run in
the repositories found may want pathspecs passed, but at the same
time, makes me realize that these repositories have to be fairly
uniform for this command to be useful. For example, 'src/*.c' or
'inc/*.h' pathspecs wouldn't be useful unless majority if not all
projects the loop finds follow that layout convention. This is not
necessarily limited to pathspecs, of course. Unless they all have
the 'next' branch "git for-each-repo checkout next" would not work,
etc. etc.
As to the pathspec limiting to affect the loop itself, not the
argument given to the command that is run, I don't think it is
absolutely needed; I am perfectly fine with declaring that
for-each-repo goes to repositories in all subdirectories without
limit, especially if doing so will make the UI issues we have to
deal with simpler.
As to the "option to the command, not to the subcommand, -a option",
I have been assuming that it was a joke patch, but if "git -a grep"
turns out to be really useful, "submodule foreach" that iterates
over the submodules may also want to have such a short and sweet
mechanism. Between "for-each-repo" and "submodule foreach", I do
not yet have a strong opinion on which one deserves it more.
Come to think of it, is there a reason why "for-each-repo" should
not be an extention to "submodule foreach"? We can view this as
visiting repositories that _could_ be registered as a submodule, in
addition to iterating over the registered submodules, no?
If these two are unified, then we do not have to even worry about
which one deserves "git -a" more.
next prev parent reply other threads:[~2013-01-28 17:46 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-27 12:46 [PATCH v4 0/2] for-each-repo: new command for multi-repo operations Lars Hjemli
2013-01-27 12:46 ` [PATCH v4 1/2] for-each-repo: new command used " Lars Hjemli
2013-01-27 19:04 ` Junio C Hamano
2013-01-27 19:42 ` John Keeping
2013-01-27 19:45 ` Junio C Hamano
2013-01-28 7:50 ` Lars Hjemli
2013-01-28 8:10 ` Jonathan Nieder
2013-01-28 17:11 ` Lars Hjemli
2013-01-28 18:35 ` Junio C Hamano
2013-01-28 17:45 ` Junio C Hamano [this message]
2013-01-28 18:35 ` Lars Hjemli
2013-01-28 18:51 ` Junio C Hamano
2013-01-28 19:42 ` Lars Hjemli
2013-01-28 20:12 ` Jens Lehmann
2013-01-28 20:34 ` Junio C Hamano
2013-01-28 21:25 ` Jens Lehmann
2013-02-04 6:41 ` Junio C Hamano
2013-01-27 12:46 ` [PATCH v4 2/2] git: rewrite `git -a` to become a git-for-each-repo command Lars Hjemli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vham1xktx.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=hjemli@gmail$(echo .)com \
--cc=jrnieder@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox