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.
As far as I know though you can't grab a specific revision this way (I'd love to be shown otherwise) - which is an issue when setting up dockerfiles since you want to bake the sha hash which works into the file.
Ironically git actually supports TAR for this exact thing: git archive exports tar files.
You can do a low depth to minimize that if you want (--depth=1 or something like that if I remember correctly). You could just rm -rf the root .git directory after but that is a download bloat issue.
There are still a lot of networks that don't have enough bandwidth to make git trivial. Most home networks, it's going to turn a 5-second download into 60 seconds or more. Some networks, it's going to turn a 1-minute download into a half an hour.
Sure, but on the other hand, downloading a tarball for every minor release means you're redownloading a lot of code. Depending on how much churn there is, you may save bandwidth in the long run by keeping a clone and updating as you go.
The problem tarballs solve is bundling files together. That use-case will probably be with us for awhile even if it has fallen out of favor for source code.
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.
>Tarballs are just as offline as git repositories...
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.
> Why is that of concern regarding "tarballs vs git"? If anything it's a win for git.
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.
The exact same can be said of git. You're reaching. Git has builtin verification of absolutely everything it holds (tags included) since it uses sha1 for objects and commit messages, and they include the previous state... so a point in a git tree in that way is a hell of a lot more immutable than a tarball.
My colleagues complain of people moving tags and sometimes branches around, or fucking things up with a bad merge. I haven't heard the same criticisms of tarballs.
I'm not a tarball warrior, I'm just going off what I hear people saying.
You haven't heard the same criticisms of tarballs because tarballs aren't used as a version control system. These issues are specific to (fairly bad) VCS usage, not packaging usage.
docker brought back the frenzy of delivering software in a tarball just like slackware in the past. Long live patrick volkerdig and tar -zxvf ... -C / !
Even though Docker's disk and transport format are technically tar, I think that this is still a wrong statement.
tarballs are ubiquitous already. Docker actively hides that it uses tarballs (it abstracts away all interactions with them, to the point that it really is an implementation detail excluding docker export/import).
Tarballs versus DVCS appears to be a false dilemma. They're independent mechanisms. The more proper question to ask here is "Are tarballs obsolete for distributing source code?".
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 documentation. The user of the distributed tarball is fully capable of re-running these steps, but they have become optional.
This is a fact often forgotten when projects switch to github and just start using the automated release tarballs github will make from the repo.
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 changes your application could break through no fault of your own. You cannot rely on maintainers to not release breaking changes in minor versions, it happens all the time, intentionally or not.
Yes, incluinding the maintainer-mode option can be important, which is why this line should be included in configure.ac most of the time when using automake:
AM_MAINTAINER_MODE([enable])
This includes the --disable-maintainer-mode configure option, while leaving maintainer mode on by default which is the traditional behavior you get when you don't include that macro. This shouldn't change any behavior for most projects.
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].
To the newcomer, autoconf looks really scary. Are there any good tutorials and are there clear advantages of using autoconf over CMake, waf, scons, ninja or other hipster-language-build-systems?
I'm going to start looking at CMake to build HTML and javascript based projects soon.
I consider myself rather adept with Makefiles for Gnu make, and I also find autoconf scary (I'll be checking out the "autotools mythbuster" linked above though).
I'd guess that autotools and cmake have a lot of complexity to do C/C++/libs related stuff that is inapplicable to html/js projects, and I'd suggest almost any of the others: waf, scons, plain make ...
ninja, as you've probably heard, is designed to be the backend to some other frontend which generates all the explicit dependencies and commands. That could be cmake, it could be a custom script of yours. Then ninja identifies changed files and runs an "incremental" build as fast (parallel and minimal) as possible.
CMake has been a huge improvement over autoconf and over visual studio projects/solutions for me. I have a repeatable and multiplatform build system with CMake. Autoconf seems like the ugly and old bastard brother of CMake in comparison, and that's praising autoconf.
However I don't know if CMake is really the best fit to build html projects. In fact, I don't know what should be built about them... my composer scripts barely copy some JavaScript and CSS files to the public/assets folder, nothing fancy like what CMake has to do.
To add to this, this is the purpose of the "maintainer" targets generated by automake. To fully clean an automake project so everything is rebuilt, you want "make maintainer-clean".
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.
Another issue with GitHub's automated release tarballs is that they do not include submodules. Though, I've also found that submodules are often overlooked when cloning.
I have been very happy with how will this has worked over the last few years. These days it's a rare surprise when I download software and it doesn't compile easily. Of course I much prefer to use an up-to-date binary from the package manager, if one is available.
That's largely because you still have the package manager to resort to in order to take care of most dependencies. Prior to that, you'd still have to install (a lot of) dependencies by hand. Not all of them used autotools, not all of them used standard install locations by default... it was pretty atrocious.
In fact, I remember that one thing which kept me on Debian for a long time was that it had so many available packages. Back then Debian was even slower than today and many of those packages were a little old, but it didn't really matter to someone who was just discovering things.
It's easy to forget about them, but package maintainers are incredibly important in today's Linux (and *nix-inspired in general) world. There's a lot of hard work behind the fact that you can just apt-get whatever new program you found out about.
What I find hardest (as a manual installer) is those packages which were designed with a package manager in mind and end up depending on many third party packages rather than incorporating the needed functionality.
As an example, program X might need to compute a statistic like the skewness of a distribution. A stats package might implement the skewness calculation, so the author of X adds the dependency and calls the right function.
However, building the stats package might require a Fortran compiler and some matrix libraries, since the stats package does much more than compute skewness.
Another approach would be for the author of X to incorporate the few tens of lines needed for the skewness as part of X. This is of course more work for the author X, so I can well understand the desire to simply declare it as a dependency.
To provide a little more information: the standard Makefile target for generating tarballs is `dist` (which all GNU projects should implement). For those curious, go take a look at some of your favorite projects that implement this target and see what the resulting tarball may result in, versus the contents of the repository.
I got bitten by this a couple of days ago - I wrongly assumed that tags on GitHub were identical to the tarballs offered on the project's website. Not so much, as it turns out: https://github.com/Tarsnap/spiped/issues/26
SHA-1 is clearly imperfect, but not that big a problem here. The writing is on the wall for SHA-1's collision resistance. A break in collision resistance would allow a malicious software maintainer to distribute different tarballs to people of interest than to the internet at large, but would not allow a third party to replace a honestly-generated tarball with some other tarball ("second pre-image").
Since you almost certainly need to trust the maintainer not to insert backdoors anyway (a well-hidden backdoor will not be detected by the normal packaging process), trusting the maintainer not to maliciously distribute different software to a small number of people of interest isn't that unreasonable.
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:
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.
Another place where tarball/zip is significantly more viable than Git: the browser (and Chromebooks as such). I know there are things like Tim Caswell's JSGit, but they're woefully unfinished and assembly-required compared to an interface like JSZip.
No! Things like package managers and git, however pervasive, are agents and not the testable, serialized representation of data.
Why wouldn't you make the same file set available as a single download via plain, old HTTP(S)?
What's so hard about that? Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser?
You CAN'T hash a tree of files quickly by hand. You need a program to help test the integrity of a tree with some recursive problem solving. Take tarballs away from people, and you're putting things on a shelf, out of reach, taking away a level of safety and reliability from a certain cross-section of your audience.
Not only that, but EVERY platform has a web browser, even if it's curl or wget. With a single file, available by HTTP, any platform can get to it, so if your machine dies, and you have to call a friend for help, and they don't use the same OS, they won't have to install a special tool, or hope an intervening third-party web service provides coverage.
If we're simply talking file formats, and possibly exchanging the tarball for zips, ISOs or what-have-you, as alternative serial representations of the same data, that's not even a discussion.
If you're worried about practical utility, load, bandwidth and/or availability (or even, perhaps, culling the dull, dumb, toxic and obnoxious from the herd, terrible as that sounds) then changing the agent permitted to access the resource might be one solution, but not necessarily the right solution.
> Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser?
wget <filename>
git clone <repo url>
What is the difference in learning curve ?
> With a single file, available by HTTP, any platform can get to it, so if your machine dies, and you have to call a friend for help, and they don't use the same OS, they won't have to install a special tool, or hope an intervening third-party web service provides coverage.
People have been making an argument for static compiling basic tools for a long time now ( I support it ). I think git can be considered a pretty basic tool now given its popularity.
so what about CVS, svn, Mercurial and fossil? Git is hip right now, but including it in an initrd seems excessive. Furthermore git downloads the entire repo, all the history/commits, this isn't always what you want or can handle or want to pay for.
Why, these are pretty basic too. Especially if what you want is just to get the code. Having a bit of experience with any VCS will let you skim the relevant manpage and use another VCS in minutes tops.
> including it in an initrd seems excessive.
True...
> Furthermore git downloads the entire repo
Not necessarily? I think you can download just the source files, without any git metadata, turning git into SVN essentially. I'm not 100% sure though, but I'd be really surprised was it not the case.
---
I started my VCS adventure with RCS, then (quickly) moved to CVS, then (even more quickly) to SVN. As soon as DVCS started to appear I switched to bazaar (bzr), then git. These are the VCS I used for my own projects; I probably used a couple more VCSes in a situation where I needed latest code for some project which used something like Mercurial, or Darcs, etc.
In general, I think it's fair to say that Version Control, as a whole, is a basic tool.
>Not necessarily? I think you can download just the source files, without any git metadata, turning git into SVN essentially. I'm not 100% sure though, but I'd be really surprised was it not the case.
Partially possible. You're always fetching diffs, not files, with git. You can get close to what you said with `git clone --depth 1`, which tells git to only get history for the latest revision, but you still get some git metadata about available branches. Depending on the version of git you're using, you may also have to pass --single-branch in order to only fetch one branch's revision.
wget <filename>
<some hard to remember command with like 4 flags to unpack,
plus hope it ends up in a subdirectory and does not put all files in this dir>
<filename>
until you've done it enough times to remember it. Learning curve indeed.
If you want a stable version, you can't necessarily just git clone. (Maybe if the default branch is kept stable, but I wouldn't trust that by default.) You also have to find the right branch/tag and do a checkout.
Everyone knows how to use an http client and everyone has an http client. Most people do not know how to use git and most people do not have a git client. It's more of a vertical line than a curve.
I am strongly in favour of tarballs for releases. Git tags can be moved, for example, so that's an extra thing to be careful about, if one is worried about reproducibility.
Thanks for posting your blog post link. Having only published static websites, I've been curious about the release process and your notes provide some insight, especially the parts about signatures.
tarballs which are also usually compressed (gz, bz2, 7z, xz) may have the benefit of being more efficient to download over bandwidth constraint or size constrained links. Also being 1 file, it's only one request and it works over zmodem or modern derivatives.
I like tarballs. Speaking as a non-programmer who compiles things like Vim and Scrypt, it is nice to be able to download a release without having to install a VCS first.
Consider using core OS tools (wget/fetch, tar, etc.) versus the dependency tree required to run git on your system. Do you need curl? Do you need perl? Do you need a XML parser and a regex runtime engine?
I love tarballs. They got a whole lot more enjoyable with all the paralell compression utilities out there. My favourite is for a file format that has fallen out of grace (bzip2) [1]. It is fast enough to make IO the bottleneck on my HDD (although not on my ssd).
84 comments
[ 2.9 ms ] story [ 144 ms ] threadYou can do a low depth to minimize that if you want (--depth=1 or something like that if I remember correctly). You could just rm -rf the root .git directory after but that is a download bloat issue.
That said this should work:
but.. yeah. Not really great.What is so cumbersome about downloading a project's history?
- 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.
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.
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.
I'm not a tarball warrior, I'm just going off what I hear people saying.
tarballs are ubiquitous already. Docker actively hides that it uses tarballs (it abstracts away all interactions with them, to the point that it really is an implementation detail excluding docker export/import).
This is a fact often forgotten when projects switch to github and just start using the automated release tarballs github will make from the repo.
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 changes your application could break through no fault of your own. You cannot rely on maintainers to not release breaking changes in minor versions, it happens all the time, intentionally or not.
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 associated comments.
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].
[1] https://autotools.io/
[2] https://autotools.io/automake/maintainer.html
I'm going to start looking at CMake to build HTML and javascript based projects soon.
I'd guess that autotools and cmake have a lot of complexity to do C/C++/libs related stuff that is inapplicable to html/js projects, and I'd suggest almost any of the others: waf, scons, plain make ...
ninja, as you've probably heard, is designed to be the backend to some other frontend which generates all the explicit dependencies and commands. That could be cmake, it could be a custom script of yours. Then ninja identifies changed files and runs an "incremental" build as fast (parallel and minimal) as possible.
Just btw, I wrote a from-first-principles sort of tutorial on Gnu make: http://www.ploxiln.net/make.html
However I don't know if CMake is really the best fit to build html projects. In fact, I don't know what should be built about them... my composer scripts barely copy some JavaScript and CSS files to the public/assets folder, nothing fancy like what CMake has to do.
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.
In fact, I remember that one thing which kept me on Debian for a long time was that it had so many available packages. Back then Debian was even slower than today and many of those packages were a little old, but it didn't really matter to someone who was just discovering things.
It's easy to forget about them, but package maintainers are incredibly important in today's Linux (and *nix-inspired in general) world. There's a lot of hard work behind the fact that you can just apt-get whatever new program you found out about.
As an example, program X might need to compute a statistic like the skewness of a distribution. A stats package might implement the skewness calculation, so the author of X adds the dependency and calls the right function.
However, building the stats package might require a Fortran compiler and some matrix libraries, since the stats package does much more than compute skewness.
Another approach would be for the author of X to incorporate the few tens of lines needed for the skewness as part of X. This is of course more work for the author X, so I can well understand the desire to simply declare it as a dependency.
https://www.gnu.org/prep/standards/standards.html#Standard-T...
> Here’s an advantage of the clone/pull distribution system; every clone is implicitly validated by its SHA1 hash chain.
Given that TLS does not consider SHA1 secure[1] anymore… I'm not sure that's an assumption I'd be making.
[1] in the sense that it's being rapidly deprecated; even if it doesn't trigger validation failures today, the fact that it will tomorrow is telling.
Since you almost certainly need to trust the maintainer not to insert backdoors anyway (a well-hidden backdoor will not be detected by the normal packaging process), trusting the maintainer not to maliciously distribute different software to a small number of people of interest isn't that unreasonable.
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.
Why wouldn't you make the same file set available as a single download via plain, old HTTP(S)?
What's so hard about that? Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser?
You CAN'T hash a tree of files quickly by hand. You need a program to help test the integrity of a tree with some recursive problem solving. Take tarballs away from people, and you're putting things on a shelf, out of reach, taking away a level of safety and reliability from a certain cross-section of your audience.
Not only that, but EVERY platform has a web browser, even if it's curl or wget. With a single file, available by HTTP, any platform can get to it, so if your machine dies, and you have to call a friend for help, and they don't use the same OS, they won't have to install a special tool, or hope an intervening third-party web service provides coverage.
If we're simply talking file formats, and possibly exchanging the tarball for zips, ISOs or what-have-you, as alternative serial representations of the same data, that's not even a discussion.
If you're worried about practical utility, load, bandwidth and/or availability (or even, perhaps, culling the dull, dumb, toxic and obnoxious from the herd, terrible as that sounds) then changing the agent permitted to access the resource might be one solution, but not necessarily the right solution.
wget <filename>
git clone <repo url>
What is the difference in learning curve ?
> With a single file, available by HTTP, any platform can get to it, so if your machine dies, and you have to call a friend for help, and they don't use the same OS, they won't have to install a special tool, or hope an intervening third-party web service provides coverage.
People have been making an argument for static compiling basic tools for a long time now ( I support it ). I think git can be considered a pretty basic tool now given its popularity.
so what about CVS, svn, Mercurial and fossil? Git is hip right now, but including it in an initrd seems excessive. Furthermore git downloads the entire repo, all the history/commits, this isn't always what you want or can handle or want to pay for.
That's the default behavior, but with `git clone --depth 1` you can apparently download only the latest version of all files: https://news.ycombinator.com/item?id=10449157
Googling around, most pages confirm it. Found this one also informative: http://stackoverflow.com/q/6941889/1201863
Why, these are pretty basic too. Especially if what you want is just to get the code. Having a bit of experience with any VCS will let you skim the relevant manpage and use another VCS in minutes tops.
> including it in an initrd seems excessive.
True...
> Furthermore git downloads the entire repo
Not necessarily? I think you can download just the source files, without any git metadata, turning git into SVN essentially. I'm not 100% sure though, but I'd be really surprised was it not the case.
---
I started my VCS adventure with RCS, then (quickly) moved to CVS, then (even more quickly) to SVN. As soon as DVCS started to appear I switched to bazaar (bzr), then git. These are the VCS I used for my own projects; I probably used a couple more VCSes in a situation where I needed latest code for some project which used something like Mercurial, or Darcs, etc.
In general, I think it's fair to say that Version Control, as a whole, is a basic tool.
Partially possible. You're always fetching diffs, not files, with git. You can get close to what you said with `git clone --depth 1`, which tells git to only get history for the latest revision, but you still get some git metadata about available branches. Depending on the version of git you're using, you may also have to pass --single-branch in order to only fetch one branch's revision.
more like
until you've done it enough times to remember it. Learning curve indeed.Everyone knows how to use an http client and everyone has an http client. Most people do not know how to use git and most people do not have a git client. It's more of a vertical line than a curve.
http://yakking.branchable.com/posts/releases/
That's my write-up on the topic of making releases, from about a month ago.
1:http://compression.ca/pbzip2/