From: Junio C Hamano <gitster@pobox•com>
To: Jens Lehmann <Jens.Lehmann@web•de>
Cc: Lars Hjemli <hjemli@gmail•com>,
Jonathan Nieder <jrnieder@gmail•com>,
git@vger•kernel.org, Heiko Voigt <hvoigt@hvoigt•net>
Subject: Re: [PATCH v4 1/2] for-each-repo: new command used for multi-repo operations
Date: Mon, 28 Jan 2013 12:34:00 -0800 [thread overview]
Message-ID: <7vlibdvyh3.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <5106DBB7.70007@web.de> (Jens Lehmann's message of "Mon, 28 Jan 2013 21:12:39 +0100")
Jens Lehmann <Jens.Lehmann@web•de> writes:
> Am 28.01.2013 19:51, schrieb Junio C Hamano:
>> Lars Hjemli <hjemli@gmail•com> writes:
>>
>>>> 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?
>>>
>>> Yes, but I see some possible problems with that approach:
>>> -'git for-each-repo' does not need to be started from within a git worktree
>>
>> True, but "git submodule foreach --untracked" can be told that it is
>> OK not (yet) to be in any superproject, no?
>
> Hmm, I'm not sure how that would work as it looks for gitlinks
> in the index which point to work tree paths.
I was imagining that "foreach --untracked" could go something like this:
* If you are inside an existing git repository, read its index to
learn the gitlinks in the directory and its subdirectories.
* Start from the current directory and recursively apply the
procedure in this step:
* Scan the directory and iterate over the ones that has ".git" in
it:
* If it is a gitlinked one, show it, but do not descend into it
unless --recursive is given (e.g. you start from /home/jens,
find /home/jens/proj/ directory that has /home/jens/proj/.git
in it. /home/jens/.git/index knows that it is a submodule of
the top-level superproject. "proj" is handled, and it is up
to the --recursive option if its submodules are handled).
* If it is _not_ a gitlinked one, show it and descend into it
(e.g. /home/jens/ is not a repository or /home/jens/proj is
not a tracked submodule) to apply this procedure recursively.
Of course, without --untracked, we have no need to iterate over the
readdir() return values; instead we just scan the index of the
top-level superproject.
>>> -'git for-each-repo' and 'git submodule foreach' have different
>>> semantics for --dirty and --clean
>
> I'm confused, what semantics of --dirty and --clean does current
> 'git submodule foreach' have? I can't find any sign of it in the
> current code ... did I miss something while skimming through this
> thread? Or are you talking about status and diff here?
I think Lars is hinting that "submodule foreach" could restrict its
operation to a similar --dirty/--clean/--both option he has. Of
course, the command given to foreach can decide to become no-op by
inspecting the submodule itself, so in that sense, --dirty/--clean
can be done without, but I think it would make sense to have it in
"submodule foreach" even without the "--untracked" option.
> But I think the current for-each-repo
> proposal doesn't allow to traverse repos which contain untracked
> content (and it would be nice if the user could somehow combine
> that with the current --dirty flag to have both in one go).
Perhaps. I personally felt it was really strange that submodule
diff and status consider that it is a sin to have untracked and
unignored cruft in the submodule working tree, though.
next prev parent reply other threads:[~2013-01-28 20:34 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
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 [this message]
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=7vlibdvyh3.fsf@alter.siamese.dyndns.org \
--to=gitster@pobox$(echo .)com \
--cc=Jens.Lehmann@web$(echo .)de \
--cc=git@vger$(echo .)kernel.org \
--cc=hjemli@gmail$(echo .)com \
--cc=hvoigt@hvoigt$(echo .)net \
--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