Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Initial revision of "git", the information manager from hell

github.com

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Initial revision of "git", the information manager from hell

#41

Post by dspillett »

jeltz wrote: post #39
dspillett wrote: post #23

Earlier quoted context omitted.

Has Linus ever said why he disregarded Darcs and the other OSS options (wasn't Mercurial already starting to get somewhere at that time?). Other projects not mature enough yet (and/or moving fast enough in that direction) and he wanted something now ? Or some technical points that he disagreed on, so wrote his own solution that worked the way he preferred instead of trying to change the established workings of other…

> Has Linus ever said why he disregarded Darcs and the other OSS options (wasn't Mercurial already starting to get somewhere at that time?). I think you might be thinking of Monotone here. Mercurial was started some days after git. EDIT: Wikipedia has some info about what Linus thought of Monotone. The key problem with it was performance. I have no idea to what degree they have been fixed today. https://en.wikipedia.…

You are probably right there, I think I have mixed up Monotone and Mercurial in my chronology.

Re: Initial revision of "git", the information manager from hell

#42

Post by Niten »

ggggit wrote: post #5

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

Re: Initial revision of "git", the information manager from hell

#43

Post by kzrdude »

humbledrone wrote: post #6
ggggit wrote: post #5

Tridgwell'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…

Uh, is "being easy to statically compile" some benchmark for simplicity that I've never heard of? Also, what do you care if git is 230MB? Do they even make thumb drives that small any more?

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.

Re: Initial revision of "git", the information manager from hell

#44

Post by dspillett »

ggggit wrote: post #16
vidarh wrote: post #15

Earlier quoted context omitted.

git is built as a multi-call binary. I wonder if he's perhaps not realizing that all those other "git-*" binaries are hard linked to "git". Depending on which boxes I check on, my git binary has in the region of 80-110 or so hard links (EDIT: admittedly not a statically linked version, but none of it dependencies are big enough that it should add up to anywhere remotely near 230MB)

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 me us 100M Aug 17 13:45 zero.file.2.link1
  180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2.link2
  180278 -rw-r--r-- 4 me us 100M Aug 17 13:45 zero.file.2.link3
  180277 -rw-r--r-- 3 me us 100M Aug 17 13:44 zero.file.link
  180277 -rw-r--r-- 3 me us 100M Aug 17 13:44 zero.file.link2
  me@swann:/tmp/tmp$ du -shc *
  101M    zero.file
  101M    zero.file.2
  201M    total
du does this duplicate ignorance trick across whole trees so the links do not have to be in the same directory, and you can have it scan a whole tree and it will show how much space it really taken, not how much is nominally taken. Like so:

  me@swann:/tmp/tmp$ cd ..
  me@swann:/tmp$ du -shc tmp
  201M    tmp
  201M    total
The reason I'm getting 101Mb instead of 100Mb (and 701Mb in total in ls) is that it is counting each link as taking a small amount of space, then "100MByte-plus-a-bit" is being rounded up to 101Mb (and 700-and-a-fraction rounds up to 701).

Also the number in the 3rd column of the ls output above is the number of links to the object, which can be helpful in understanding this sort of situation too.

Re: Initial revision of "git", the information manager from hell

#45

Post by ciupicri »

ontouchstart wrote: post #36
ciupicri wrote: post #31

Earlier quoted context omitted.

Why would/do you run git on a mobile device?

I am running git on a jailbroken 3G iPad 1 during commute. :)

Yeah, but what's the purpose? Are you editing text files (source code) on the iPad and you need to keep track of the changes?

Re: Initial revision of "git", the information manager from hell

#47

Post by adharmad »

thaumaturgy wrote: post #4
ajross wrote: post #2

What's most notable about this isn't so much that all the core ideas of git are already in place in the first version. It after all is, fundamentally, a pretty simple piece of software. What shocks me is that that README was written literally days after the kernel project's license to bitkeeper got revoked.

Isn't it funny to think about how, if Tridge hadn't done what he did, if all of Linus' public shaming of Tridge had done the trick and the Linux kernel had stayed on Bitkeeper, that we wouldn't have had git, or Github? Linus did a good job of coming up with a replacement tool in a hurry, but I'm also grateful to Tridge for poking a stick into the hornets' nest.

Yes. I was subscribed to LKML around the time the Bitkeeper sage was in progress.

One thing that I do remember was just how arrogant Larry McVoy was about whether a replacement SCM could be developed and have feature parity with Bitkeeper. He kept on talking about how he/Bitkeeper is at least a decade ahead of the rest of the community and it would be very difficult to come up with an alternative.

Thankfully, the open source community proved him wrong!

Re: Initial revision of "git", the information manager from hell

#48

Post by voltagex_ »

adharmad wrote: post #47
thaumaturgy wrote: post #4

Earlier quoted context omitted.

Isn't it funny to think about how, if Tridge hadn't done what he did, if all of Linus' public shaming of Tridge had done the trick and the Linux kernel had stayed on Bitkeeper, that we wouldn't have had git, or Github? Linus did a good job of coming up with a replacement tool in a hurry, but I'm also grateful to Tridge for poking a stick into the hornets' nest.

Yes. I was subscribed to LKML around the time the Bitkeeper sage was in progress. One thing that I do remember was just how arrogant Larry McVoy was about whether a replacement SCM could be developed and have feature parity with Bitkeeper. He kept on talking about how he/Bitkeeper is at least a decade ahead of the rest of the community and it would be very difficult to come up with an alternative. Thankfully, the ope…

Any particular threads worth digging up?

Re: Initial revision of "git", the information manager from hell

#49

Post by ramses0 »

voltagex_ wrote: post #48
adharmad wrote: post #47

Earlier quoted context omitted.

Yes. I was subscribed to LKML around the time the Bitkeeper sage was in progress. One thing that I do remember was just how arrogant Larry McVoy was about whether a replacement SCM could be developed and have feature parity with Bitkeeper. He kept on talking about how he/Bitkeeper is at least a decade ahead of the rest of the community and it would be very difficult to come up with an alternative. Thankfully, the ope…

Any particular threads worth digging up?

I ran into McVoy on reddit a few years ago. He seemed totally different than the "scary evil public persona" that has been bandied about...

http://www.reddit.com/r/programming/comments/9zdlf/git_and_m...

...humble, concerned, and proud of how they've advanced the "state of the art" and his company's contributions to modern version control.

"""Imagine how I'd feel if Linus used BK for years and when moving off he made a centralized VCS."""

Re: Initial revision of "git", the information manager from hell

#50

Post by onedognight »

luriel wrote: post #37
markokocic wrote: post #33

Earlier quoted context omitted.

Darcs was pretty neat at the time, especially since it was the only open DVCS. And the theory behind it was interesting to read. The only problem is that it had a feeling of non-robustness when using it, and because of that I was tempted to have multiple copies of my repos, just in case of corruption. And that kinda defeats the purpose of VCS. Then, git came along. Although a bit strange in the beginning, especially…

> Darcs was pretty neat at the time, especially since it was the only open DVCS. You are forgetting Tom Lord's arch, which had a really bizarre interface (even more so than Darcs), but was conceptually very nice.

> You are forgetting Tom Lord's arch, which had a really bizarre interface (even more so than Darcs)

Darcs has a terrific consistent interface. Git has taken liberally from it. "git log -p" and "git add -p" are straight from darcs. AFAIK, nothing before darcs could look at a repo as a stream of diffs and comments.

Post reply on HN