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.
more like
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. <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>
with tar -xf <filename> -x means extract
-f means force
and my favorite to put in there is: -v for verbose
This shows you all of the files being processed, sometimes it can be really helpful to see. Try: tar -xvf <filename>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.
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.
'git' is not recognized as an internal or external command,
operable program or batch file.
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.