On Tue, Jun 6, 2017 at 12:03 PM, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > On Tue, Jun 6, 2017 at 8:48 PM, Stefan Beller <sbel...@google.com> wrote: >> On Tue, Jun 6, 2017 at 8:12 AM, Ævar Arnfjörð Bjarmason >> <ava...@gmail.com> wrote: >>> Add an option to use the sha1collisiondetection library from the >>> submodule in sha1collisiondetection/ instead of in the copy in the >>> sha1dc/ directory. >>> >>> This allows us to try out the submodule in sha1collisiondetection >>> without breaking the build for anyone who's not expecting them as we >>> work out any kinks. >>> >>> Signed-off-by: Ævar Arnfjörð Bjarmason <ava...@gmail.com> >> >> Other projects using submodules sometimes have >> a .gitattributes entry to have .gitmodules not exported >> via git-archive. Do we want a similar thing? > > Right now we end up with an empty directory due to the issue you noted > in > https://public-inbox.org/git/cagz79kzc98cxa69qjmx2s_su6z1csgkgwzeqvwimraqc6+s...@mail.gmail.com/ > > It's probably best to have the .gitmodules file as some hint that > something should be there. We also ship the other .git* files.
Ok, but then let's talk about the other .git* files, would we want to distribute these via tarballs? (I guess it is a minor thing if at all and nobody downloading a git tarball would be surprised by these metadata files or annoyed by them, so all is good?) > >> Speaking of attributes, I wonder if we want to specify >> the .gitmodules file to be text with unixy file endings: >> Having an entry >> .gitattributes eol=crlf >> to simulate a Windows environment doesn't harm >> submodule operation, which is good. I'll check if we >> have a test for that. > > I have no idea what that would do or why we'd have it, but I'm going > to understand this as you looking into it :) I looked briefly into it and it seems to be no problem just as config files on Windows are no problem. I just spoke up too quickly.
