To me, --recurse-submodules means submodules are still not first-class citizens. But let's put that aside for a moment; I don't care about the switch name too much as long as I can configure 'diff.recurse-submodules = true'.
[The following is rather long. I'm sorry for that. Feel free to look away when it gets too vague.]
Let me set up a submodule like so:
$ git init /tmp/Super && cd /tmp/Super
Super$ git submodule add https://github.com/gitster/git.git Foo
I wish to be able to grep from Super and find matches in all my submodules.
Super$ git grep --recurse-submodules base--int
Foo/.gitignore:/git-rebase--interactive
Foo/Makefile:SCRIPT_LIB += git-rebase--interactive
But I want this to work naturally across git-module boundaries, so I want this also to work (grepping a super-project from within a submodule):
Super$ cd Foo
Foo$ git grep --recurse-submodules base--int ..
.gitignore:/git-rebase--interactive
Makefile:SCRIPT_LIB += git-rebase--interactive
I expect some groans from the audience here, because I think if the syntax above worked, then so would this:
$ cd /tmp
tmp$ git grep base--int /tmp/Super/Foo
/tmp/Super/Foo/.gitignore:/git-rebase--interactive
/tmp/Super/Foo/Makefile:SCRIPT_LIB += git-rebase--interactive
This usage has nothing to do with submodules, really, except that it allows git commands to reach into foreign git directories by virtue of the path supplied as some argument instead of via $GITDIR, and in doing so it helps solve some git submodules use cases of mine.
But if that did not turn your stomach, try this one:
$ cd /tmp/Super
Super$ printf "Some submodule data">Foo/data.txt
Super$ git add Foo/data.txt
fatal: Pathspec 'Foo/data.txt' is in submodule 'Foo'
Super$ git add --recurse-submodules Foo/data.txt
Some notes on this usage:
1. --recurse-submodules seems like a reasonable name for this switch,
especially when you consider the 'git add --recurse-submodules .' use
case.
2. This recursive 'git add' seems dangerous to me unless git-status
also shows all the changed/untracked files in submodules as well if
the --recurse-submodules switch is included. This would support the
expectation that 'git add .' is going to add the files shown by 'git
status .'
3. Configuring --recurse-submodules as the default mode for 'git add'
but not for 'git status' seems reckless enough that I think there
should not be separate options for these two commands. There are
probably many other "cross-command" scenarios with similar coupling.
Moving on, as we have :/ to mean 'workdir root', I wonder how you would spell "super-project workdir root". Maybe it would be ::/
I realize the kinds of features I'm talking about require extensive code changes in Git. For example, consider the meaning of this:
Super$ git diff --recurse-submodules origin/next origin/master
Since I created Super just a few minutes ago and it has no remote named 'origin', this command seems meaningless to me. But suppose that origin/next and origin/master did exist in my Super project. Then, I would expect in my wishlist Git, that
A. Super$ git diff --recurse-submodules origin/next origin/master This would include differences in Foo between origin/master:Foo and origin/next:Foo; that is, the commits referenced from those gitlinks in Super.
B. Super$ git diff --recurse-submodules origin/next HEAD This would include differences in Foo between origin/master:Foo and HEAD:Foo; that is, the commits referenced from those gitlinks in Super.
C. Super$ git diff --recurse-submodules origin/next This would include differences in Foo between origin/master:Foo and the current Foo workdir.
D. Super$ cd Foo && git diff origin/next This would include differences in Foo between the Foo submodule's origin/master and the current Foo workdir.
Now, C and D seem confusingly similar to me and technically very different. I could understand the results, but I could easily be led astray, especially if I am writing a script. But I still think it is reasonable and correct.
I think this could have dire consequences for some commands like 'git apply'. But I think it is reasonable for git apply to reject such cross-project diffs, at least in the beginning. :-)
While I am thinking about it, let me also mention these cases: E. Super$ git diff --recurse-submodules origin/next origin/master -- Foo I think 'origin/next' and 'origin/master' here are referring to Super's refs, but I can imagine an implementer choosing to use Foo's instead.
F. Super$ cd Foo
Foo$ git diff --recurse-submodules origin/next origin/master -- ..
If this worked, I would think 'origin/next' and 'origin/master' here
must refer to Super's refs even though I began in Foo. This one is so
ambiguous I think I would have to call this an error. More
specifically, I think it would have to be rewritten like this next one
(G).G. Super$ cd Foo
Foo$ git -C .. diff --recurse-submodules origin/next origin/master
That is, at least for 'git diff', the <path> parameter at the end is
only used to filter the results; it is not used to find the git-dir.But look at me speaking in the present tense. How silly. I live too much in my own imagination.
Phil
Phil Hord
