Show 44 quoted lines
> On 6 Jun 2015, at 18:49, Phil Hord <phil.hord@gmail.com> wrote:
>
> On Fri, Jun 5, 2015, 2:58 AM lucamilanesio <luca.milanesio@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
Luca Milanesio <luca.milanesio@gmail.com>