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
