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.
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.