I used to keep messing up git till the time I studied the internal model. As long as you imagine a DAG and where the refs point to in your mind every time you execute a git command, you are good. Not that I am complaining - it is very powerful and tends to gets easier with use.
Initial revision of "git", the information manager from hell
61–70 of 71 posts
Re: Initial revision of "git", the information manager from hell
#62Earlier quoted context omitted.
Why would/do you run git on a mobile device?
You could use it to automatically get firmware and software updates. One likely way of doing it: use git to list out tags and branches, find most recent one with appropriate text in the name. Then check out the data from that revision, and use it. Maybe delete the local git stuff afterwards (since you don't need it any more). Or, better yet, archive the data from that revision. You might not necessarily supply this s…
Isn't this a problem that should be solved with a package management solution like yum or apt-get plus something for configuration management like puppet, chef or ansible? Git would still be useful, but only on the server side.
Re: Initial revision of "git", the information manager from hell
#63Earlier quoted context omitted.
svn is quite over-engineered and has significantly more dependencies than git. There's no way a statically linked svn would come out smaller than git, so either you're trolling, lying, or stupid. Besides, file sizes of statically linked version control binaries is utterly uninteresting for anyone with an ounce of sanity.
> Besides, file sizes of statically linked version control binaries is utterly uninteresting for anyone with an ounce of sanity. Unless, you, say, want to be able to use it on an embedded device for some reason, or to be able to ship it as part of some project where you have little control over what environment users might want to run it in, say for an IDE running on Android. Or for ports to far more constrained plat…
If you cared about binary size, you'd be using dynamic linking to avoid duplication in the first place.
Re: Initial revision of "git", the information manager from hell
#64Earlier quoted context omitted.
> Besides, file sizes of statically linked version control binaries is utterly uninteresting for anyone with an ounce of sanity. Unless, you, say, want to be able to use it on an embedded device for some reason, or to be able to ship it as part of some project where you have little control over what environment users might want to run it in, say for an IDE running on Android. Or for ports to far more constrained plat…
If you cared about binary size, you'd be using dynamic linking to avoid duplication in the first place.
Maybe he cares first about portability, e.g., easily moving a binary from one BSD-based device to another. Not all devices have the same space limitations.
There might be other reasons, too. Static binaries fork faster, but this works best if they are also small enough to remain entirely in the OS's cache.
There's nothing wrong with dynamic linking per se. Nor is there anything wrong with static linking per se. ("Per se" as used here is intended to mean "in all circumstaces".) The use of one or the other is simply a choice. There are advantages and disadvantages with each method, based on the circumstances and whatever the desired result(s) is/are.
Re: Initial revision of "git", the information manager from hell
#65Earlier quoted context omitted.
a 230MB executable is no fun.. it needs to be read from disk to be executed, and bigger code means worse cache use (for instructions) when running.
It's 115 links to a 2 MB executable. The actual on-disk size is 2 MB.
Right.
I feel stupid that I did not realise this. I am a big fan of crunched binaries, actually. That guy at U of Maryland who introduced it to BSD in the early 90's is a software hero in my book. For Linux fans, I guess your hero would be Bruce Perens or whoever was behind Busybox.
Anyway I've learned something more about git from admitting my error. Thank you HN!
Re: Initial revision of "git", the information manager from hell
#66Earlier quoted context omitted.
So ls -i should show they all share the same inode number? Thanks for this. I was not aware of that. Perhaps I will give it another try.
> So ls -i should show they all share the same inode number? It would, yes. Another useful tool here is du which by default will screen out files with duplicate inode numbers. So for an example where I have two 100M files each with multiple hard links: me@swann:/tmp/tmp$ ls -lhi total 701M 180277 -rw-r--r-- 3 me us 100M Aug 17 13:44 zero.file 180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2 180278 -rw-r--r-- 4…
I am no expert with du and all it's options and behaviours, but it's funny you mention the h, c and s ones because I did bother to learn and commit those three to memory long ago and routinely that combination.
I also use routinely use dd to get "exact" file sizes (yes, it's crude, but dd is on almost every UNIX-like system and it works), unless I have access to a good stat utility.
Re: Initial revision of "git", the information manager from hell
#67Tridgwell's "reverse engineering" of BitKeeper is one of the funniest, and at the same time the saddest stories, I've read about software. http://lwn.net/Articles/132938 It's companies like BitKeeper, who think using a command line is "not allowed" that are the reason so much software sucks. The interface Tridgewell used was the only one I'd be interested in. It's something you could build on top of. You could add ab…
> As for git, it's not nearly as simple as people portray it to be. git's famous simplicity is in the form of its well-designed and stable (and well-documented) underlying data structures, it has nothing to do with the size or runtime dependencies of a particular implementation.
I do understand about the simplicity of the design, though I haven't tried to figure out exactly how git works.
When I see people commenting about git's simplicity it is not about data structures. It is about commands. And that really tells me little about simplicity. Anyone can manipulate the argument structure for a function and positional parameters in a command line interface. The real question is what does the function do, and how does it accomplish it?
The first thing that struck me about git is the apparent use of SHA1 hashing as a basic foundation for the whole system. Maybe that's not even true and no doubt there is much more to it. I'm not out to become an expert in version control nor to understand git completely because I only use it out of necessity. Older systems work just as well for my purposes.
I do not need many advanced features in version control; I'm using version control on a personal basis, not as a contributor to some highly dynamic project with many other contributors. Plain old rcs is still my main tool when I need the ability to move between versions. And diff still seems to work for detecting and printing differences after so many years.
But to me, as a user, the compilation process of any program is also part of any purported "simplicity of design". Programs that compile easily and quickly and are easy to modify score very highly in my book. I am constantly looking for more programs that fit this description.
I was not aware that there were many implementations of git.
I'll now be looking for some other implementations. On github of course.
Re: Initial revision of "git", the information manager from hell
#68Earlier quoted context omitted.
It's 115 links to a 2 MB executable. The actual on-disk size is 2 MB.
Right. I feel stupid that I did not realise this. I am a big fan of crunched binaries, actually. That guy at U of Maryland who introduced it to BSD in the early 90's is a software hero in my book. For Linux fans, I guess your hero would be Bruce Perens or whoever was behind Busybox. Anyway I've learned something more about git from admitting my error. Thank you HN!
You know what's funny? I made the same mistake a year or two ago. :)
Re: Initial revision of "git", the information manager from hell
#69Earlier quoted context omitted.
He means stupid as in simple, unaware of things it does not need to know. Stupidity and ignorance in software is high praise and it's very difficult to achieve. See: http://en.wikipedia.org/wiki/Information_hiding That style is just linus' way. It comes across as a lot more aggressive on screen than in person. To get a better sense of him, I'd recommend watching this talk he gave evangelising git at google back in 20…
Ouch! No heed to be harsh. I certainly appreciate Linus's work. Kudos to him! I understood his point on the stupidity thing. It even took some laughs out of me. And that's the reason I posted that, so other people could too. I don't mean to start a flamewar on scm, really. But I think git is overly complicated, and I believe I'm not alone on that. Anyway, don't take things too seriously and have a good one! PS: You g…
Sorry, really didn't mean to be mean whatsoever. It's hard to convey tone in internet comments :)
Re: Initial revision of "git", the information manager from hell
#70Earlier quoted context omitted.
You could use it to automatically get firmware and software updates. One likely way of doing it: use git to list out tags and branches, find most recent one with appropriate text in the name. Then check out the data from that revision, and use it. Maybe delete the local git stuff afterwards (since you don't need it any more). Or, better yet, archive the data from that revision. You might not necessarily supply this s…
Isn't this a problem that should be solved with a package management solution like yum or apt-get plus something for configuration management like puppet, chef or ansible? Git would still be useful, but only on the server side.
Possibly. I'm thinking more of retrieving an entire image, so you could also use FTP. Anyway, this isn't really my field of expertise, I'm just foolishly throwing out a random suggestion...