21–30 of 85 posts
Correct me if I'm wrong but doesn't a git clone involve downloading the project's entire git history as well as $CURRENT_VERSION? That seems a little excessive.
Correct me if I'm wrong but doesn't a git clone involve downloading the project's entire git history as well as $CURRENT_VERSION? That seems a little excessive.
And what if you find a bug, and want to regress to a previous version? What is so cumbersome about downloading a project's history?
Absolutely not; there are a myriad of reasons to prefer tarballs over Git: - Offline use - Permission restrictions (Internal git networks) - True-persistent versioning (Can always delete and update a tag), no external tools needed to download - Can restrict extra garbage that may not be need to be shipped - Etc.
> Offline use Tarballs are just as offline as git repositories... > Permission restrictions (Internal git networks) What? > True-persistent versioning (Can always delete and update a tag) Why is that of concern regarding "tarballs vs git"? If anything it's a win for git. > Can restrict extra garbage that may not be need to be shipped Only valid point you presented, and it's better discussed elsewhere in this thread.
Tarballs are easier to shoenet into an offline machine. To do this with git repositories, you would either need to deal with transfering a directory structure or, more likely, pack the respository into some sort of tarball.
The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the docume…
Exactly. Many web tool chains involve pulling from external repositories such as npm, bower or even github itself. If one of these are down you cannot deploy your application. Even better many packaging systems such as npm or setuptools allow you and library maintainers to specify a flexible version numbers for your dependencies. If during the course of your build, test and deploy chain one of these dependencies chan…
The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the docume…
Running the more common "clean" or "distclean" targets leaves not only the generated Makefile.in files, but also generated source like the generated .c/.h files from a lex/yacc parser. This is important behavior; while C compilers are available everywhere, having bison and flex (or ANTLR, or any other less-common code generation tool) installed isn't as common.
The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the docume…
This becomes more complex when distributions want to patch configure.ac or Makefile.am -- they need to patch the included Makefile.in files as well. Trying to balance these two forces is the reasoning behind the AM_MAINTAINER_MODE flag. These days, I prefer to simply use git archive for a tarball and make users run autogen.sh themselves. See https://blogs.gnome.org/desrt/2011/09/08/am_maintainer_mode-... and the asso…
AM_MAINTAINER_MODE([enable])
You can change the default to off with the same macro, if that is important; the key point is to include the macro so it can be changed by the automated packaging scripts used in some distributions.
I recommend Autotools Mythbuster[1] for a nice overview of how to use modern versions of autotools, including maintainer mode[2].
If you're willing to hand-wave away certain things as being outside of the "center of the open-source software-release ritual", then you can get a 'yes'.
But in addition to source-distributions mentioned in the essay, which are "too tiny a minority", two other issues are:
1) If you define "git" as "pervasive" then you can declare that git is the solution. In my field, some of the tools are still only accessible via tarball/zip. Two examples are the IUPAC InChI distribution, from http://www.iupac.org/home/publications/e-resources/inchi/dow... , and VMD from http://www.ks.uiuc.edu/Development/Download/download.cgi?Pac... . PyMol, a more popular free software visualization package, is also not developed using git.
2) If you define "open-source software-release" to exclude fee-based free software distribution (perhaps it is also "too tiny a minority"?), then it preferentially excludes certain flavors of 'open-source software'. For example, I write free software, and distribute it for money. A tarball is an easy way to identify the delivery of the contractually obligated product. I can also send it via email, vs. setting up a private git server and getting accounts set up for my customers.
How much free software development is part of the hidden world of non-publicly accessible development? I don't think anyone really knows.
So if your free software baseline assumes "pervasive git", a public development repo, and no cost to access the code, then sure, the answer is a "yes". Until then, it's a "no."
And my examples show that baseline is only a subset of free software development, with no clear idea of how large it is.
The distributed form of a project (especially one based on GNU autotools) is often not merely a tarball of the upstream repository. Often the author has pre-run some stages of the build that she feels would impose unnecessary or esoteric dependencies. Typically this involves pre-generating Makefile.in from Makefile.am and configure from configure.ac. Another common one is for the maintainer to pre-generate the docume…
Absolutely not; there are a myriad of reasons to prefer tarballs over Git: - Offline use - Permission restrictions (Internal git networks) - True-persistent versioning (Can always delete and update a tag), no external tools needed to download - Can restrict extra garbage that may not be need to be shipped - Etc.
> Offline use Tarballs are just as offline as git repositories... > Permission restrictions (Internal git networks) What? > True-persistent versioning (Can always delete and update a tag) Why is that of concern regarding "tarballs vs git"? If anything it's a win for git. > Can restrict extra garbage that may not be need to be shipped Only valid point you presented, and it's better discussed elsewhere in this thread.
Git tags (and branches) are mutable. Tarballs technically are, but don't move around as much. Unless someone's being actively malicious, you can be confident that no-one's going to put new code in an old-versioned tarball.