41–50 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.
Earlier quoted context omitted.
> 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.
> 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.
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?".
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 ha…
wget
git clone
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.
Earlier quoted context omitted.
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…
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'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
Earlier quoted context omitted.
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…
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.
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 ha…
> Why place something on a shelf, behind an agent that demands a learning curve, when it could also be available to a browser? wget git clone 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 thi…
My comment from yesterdays post on this topic: 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, so…
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.
You can use `--depth=1` to only download one revision, and `--branch` to specify an alternate branch or tag.