On Wed, Jun 15, 2016 at 10:02 PM, lvh <_...@lvh.io> wrote: > > These are important to the software we’re building, so they ought to live > in VCS, or at least a reference to them should. How do you manage this? > Just put the .git dir in version control? Bare checkout? Something that > references the repo + commit but keeping the actual checkout out of source > control? >
The .git dir is the local copy of the git repository, so that could be a huge thing to keep in another VCS - Fossil or other. If you are only "reading" the upstream projects, you could export the git repo and import it to Fossil. Once done the first time, you should be able to do it incrementally. Other VCSs can be exported to Fossil. Fossil recently acquired support for importing from SVN. Other VCSs would require exporting to either git or SVN export format, then importing to Fossil. Would be simpler to just fetch tar/zip files of the other projects as needed. Then you could either untar/unzip those and commit in to Fossil locally, or just reference in your makefile (or whatever your build system uses) by defining a "pointer" to where the files were untared/unzipped. To make contributions to the upstream projects, you could send patch files. But many projects - especially those on github - expect pull requests, so you'd need to have local copies of the repos. When I make contributions to git based projects, I update my local copy of the repo, update my Fossil repo of the project and manage my changes with Fossil. When I'm ready to submit my changes, I update my local git repo, merge any upstream changes to my changes and commit to my local git repo (and to Fossil). Then, if applicable, push to my github "fork". Then,send out the pull request.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
