in reply to 'bld' project - signature(SHA1) based replacement for 'make'

If you want people to look at the source, you should probably start by providing easier access to it - .tar.xz files dropped in a Git repo aren't good. Why not provide the unpacked source with a proper version history in the repository? Git and github are incredibly powerful collaboration tools - when used to their full potential.

Replies are listed 'Best First'.
Re^2: 'bld' project - signature(SHA1) based replacement for 'make'
by rahogaboom (Novice) on Aug 25, 2014 at 17:13 UTC
    I plan on doing just that; setting up a git sandbox with only the bld code and the basic examples(not git, svn or systemd). This will make the whole project in the kilobytes. I would still, however, like to have the bld-1.0.2.tar.xz files include the OSS project blds. This makes the files much bigger. I left all the executables in the git project to enable a user to see what it looks like after a full project successful build. Hmmm... Is GitHub suitable for this or should large files be best stored elsewhere? Anyway Thanks!!

      In theory you can put any binary files into Git, but people tend to avoid it since every clone of the repository will become quite large. I'd recommend only placing source code into the repository. Instead, host larger binary downloads like your bld-1.0.2.tar.xz files from some other location that's not a Git repository. Another possibility is to use GitHub's "Releases" feature, see here, I haven't tried it myself but it looks like you can attach binaries to releases. Note that since your current repo already includes the binary files in its history, the best way to get rid of them is to start a new repo with a clean history.

      Also, I would recommend against putting other project's source trees into yours. You'll end up having to keep your repo up to date with the source repo all the time. Instead, look into externals (known as submodules in Git), see for example here. Another approach, useful for when the VCS systems aren't compatible, is to include in your project a script to download the other project's source code.

        I just updated GitHub. Deleted the .xz files. Built a new repo with the source directory viewable. Updated the README. Made a 1.0.0 release with the Releases feature you put me onto. I don't need to update the git,svn,systemd source really because they are only examples of complex builds and not core to the project. I really want to do the Linux kernel. Thanks.