On Mon, Sep 10, 2012 at 12:11 PM, Jack Lawson <[email protected]> wrote: > I agree that subtrees are usually preferable; however, there are many > projects using submodules (perhaps introduced before subtrees were merged > into git master or subsequently popularized.)
Git subtree merge strategy is out there more or less just as long git as submodules. (Note that I do *not* mean the new git-subtree command.) > A ban on submodules would be > shortsighted dogmatism. Furthermore, there are several reasons to use > submodules, even if the interface is complex and it doesn't work for some > use cases. Name one. > Even if it were an option, It wouldn't make any sense to enforce > because of the potential to break otherwise entirely legitimate > repositories. That is true — but I do not *ask* anyone for submodule ban. > (Subtrees wouldn't help over submodules anyway, in your case.) Please do explain the last sentence. "My case" is that a third-party repo that a rock build process depends on suddenly breaks. Subtree merge is, in fact, a full-featured git merge — it includes not only the sources, but original commit history as well (as much of it as deemed necessary by merge author anyway). It completely eliminates the build-time dependency. Alexander. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Luarocks-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/luarocks-developers
