On Tue, Jun 9, 2015 at 2:40 PM, Jens Lehmann <jens.lehm...@web.de> wrote: > Am 07.06.2015 um 08:26 schrieb Stefan Beller: >> >> On 06.06.2015 12:53, Luca Milanesio wrote: >>>> >>>> On 6 Jun 2015, at 18:49, Phil Hord <phil.h...@gmail.com> wrote: >>>> On Fri, Jun 5, 2015, 2:58 AM lucamilanesio <luca.milane...@gmail.com> >>>> wrote: >>>>> >>>>> Ideally, as a "git clone --recursive" already exists, I would like to >>>>> see a "git diff --recursive" that goes through the submodules as well >>>>> :-) >>>>> >>>>> Something possibly to propose to the Git mailing list? > > > Such an option makes lots of sense to me (though "--recurse-submodules" > should be its name for consistency reasons). This could be an alias for > "--submodule=full", as the "--submodule" option controls the format of > submodule diffs.
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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
