That is good to hear. I would be pretty happy about that. ^.^ Obviously any major changes will need to be done carefully. I was thinking of the way that you guys introduced new defaults for Git 2.0, phasing them in slowly through the 1.x cycle. Maybe I can get my hopes up for Git 3.0 --- 9 years from now :P
On Tue, Jun 3, 2014 at 4:05 PM, Junio C Hamano <gits...@pobox.com> wrote: > Junio C Hamano <gits...@pobox.com> writes: > >> Mara Kim <mara....@vanderbilt.edu> writes: >> >>> Apologies if this question has been asked already, but what is the >>> reasoning behind making git clone not recursive (--recursive) by >>> default? >> >> The primary reason why submodules are separate repositories is not >> to require people to have everything. Some people want recursive, >> some others don't, and the world is not always "majority wins" (not >> that I am saying that majority will want recursive). >> >> Inertia, aka backward compatibility and not surprising existing >> users, plays some role when deciding the default. >> >> Also, going --recursive when the user did not want is a lot more >> expensive mistake to fix than not being --recursive when the user >> wanted to. > > Having said all that, I do not mean to say that I am opposed to > introduce some mechanism to let the users express their preference > between recursive and non-recursive better, so that "git clone" > without an explicit --recursive (or --no-recursive) can work to > their taste. A configuration in $HOME/.gitconfig might be a place > to start, even though that has the downside of assuming that the > given user would want to use the same settings for all his projects, > which may not be the case in practice. > -- Mara Kim Ph.D. Candidate Computational Biology Vanderbilt University Nashville, TN -- 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
