Jens Lehmann [off-list ref] writes:
Am 28.01.2013 19:51, schrieb Junio C Hamano:
quoted
Lars Hjemli [off-list ref] writes:
quoted
quoted
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.
quoted
quoted
-'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.
Am 28.01.2013 21:34, schrieb Junio C Hamano:
Jens Lehmann [off-list ref] writes:
quoted
Am 28.01.2013 19:51, schrieb Junio C Hamano:
quoted
Lars Hjemli [off-list ref] writes:
quoted
quoted
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.
Thanks for explaining, that makes tons of sense.
quoted
quoted
quoted
-'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.
Nice idea. E.g. that would help submodule users to easily script
a workflow which descends only into modified submodules to create
branches and push them there. Or to remove branches which were
created everywhere only in those submodules that weren't changed.
quoted
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.
The VCS we used at work before Git didn't show us any untracked
files, which caused trouble on a regular basis as people were
breaking builds for others because they forgot to check in new
files. That didn't happen with Git anymore, which was very cool.
But the problem reappeared as we started using submodules. Since
I taught status and diff to show that we're happy again. So for
us it was everything but strange ;-)
But for for-each-repo I would rather propose that modifications of
tracked files can optionally and/or solely be used to pick the
repos. Maybe: --dirty=modified, --dirty=untracked and --dirty=both
with --dirty defaulting to modified?