Leaderboard

It really depends on what you are trying to do so I get that. For me even just setting the VI file to read-only would be enough, but I ran into a few times when a mass compile would want to overwrite the VI despite it having separate compile code, but that was years ago. For me the purpose was that a developer would be drilling into the code and not realize they were in a reuse function and would start messing around with it and changing things that will now make the program behave differently on one developers machine, than the others. A gentle reminder to not mess with something was all we needed. But I get your points.

Files that don't have revisions don't need to be commited into the repository itself. GitHub has a nice feature called GitHub Releases which lets you host "release files" -- it's designed for installers/packages/binaries, but you're free to store other files there too. Each Release is linked to a tag/commit in your Git repo so you know which version of your code was used to generate the installer. Here's an example of some releases from an NI repo: https://github.com/ni/niveristand-scan-engine-ethercat-custom-device/releases/ BitBucket has a lightweight variant of this called BitBucket Downloads (the link is somewhat tangential, but it's the best I could find). I like GitHub's release file hosting more than BitBucket's, but I like BitBucket's issue tracker more than GitHub's.

What's the reason for moving to Github? I was using Kiln to host my code, which used Mercurial. I switched to Bitbucket with Git. I had to migrate many projects from Mercurial to Git. I did the migration using the HG-GIT extension: https://hg-git.github.io The main problem I encountered was using the "large files" Mercurial extension. The automatic import tools provided by GitHub and others don't like that extension and barf. Otherwise you can use the web migration tool provided by GitHub. My workaround to the large files problem was to accept the fact that I will lose the revision history on those files. Not a huge deal, since most large files I had were installers and binaries that didn't have revisions per say. So after the migration I did a diff on the project folder, identified the large files, which were missing from the new Git project and just copied them over and pushed them up to the Git repo. Don't forget that the core GIT functionality is the same regardless of service provider. So let's say you found a way to import your repo to GitHub, you can easily turn-around and move it to GitLab, bitbucket or whatever. You're not locked-in. But it might be an issue if you are using an extension that only one service provider supports. The future is GIT. I made the jump over a year ago and haven't looked back. The service provider you choose should give you the tools you need to do your job. The reason I picked Bitbucket was because I liked and used all the other products that Atlassian provides, JIRA, Confluence etc. The tools from Github are a bit weak for my business. I also like companies that continuously improve and invest in their products, among other things. Github seems to be the popular choice for open-source, since that's how it got started. Now that Microsoft owns them, perhaps they don't have to worry about generating revenue (don't know if it's good or bad). But I don't see features that compare to what Atlassian offers.

Obligatory Bobby Tables reference