Thank you Phil, you anticipated me :-) Luca.
> 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: >>> >>> Some devs of my Team complained that with submodules it is >>> difficult to see the “full picture” of the difference >>> between two SHA1 on the root project, as the submodules >>> would just show as different SHA1s. When you Google >>> “subtree submodules” you find other opinions as well: >>> >>> Just to mention a few: >>> - >>> https://codingkilledthecat.wordpress.com/2012/04/28/why-y >>> our-company-shouldnt-use-git-submodules/ - >>> http://blogs.atlassian.com/2013/05/alternatives-to-git-su >>> bmodule-git-subtree/ >>> >>> To be honest with you, I am absolutely fine with >>> submodules as I can easily leave with the “extra pain” of >>> diffing by hand recursively on submodules. But it is true >>> that it may happen to either forget to do a git submodule >>> update or otherwise forget you are in a detached branch >>> and start committing “on the air” without a branch. > > ... > >> 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? > > > I've worked on git diff --recursive a bit myself, along with some > simpler use cases (git ls-tree --recursive) as POCs. I think some of > the needs there begin to have ui implications which could be > high-friction. I really want to finish it someday, but I've been too > busy lately at $job, and now my experiments are all rather stale. > > It would be a good discussion to have over at the git list (copied). > Heiko and Jens have laid some new groundwork in this area and it may > be a good time to revisit it. Or maybe they've even moved deeper than > that; I have been distracted for well over a year now. > > 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
