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

20 years of Git

blog.gitbutler.com

Post reply on HN
Print view View original

101–110 of 240 posts

Re: 20 years of Git

#101

Post by singron »

cryptonector wrote: post #96
zahlman wrote: post #94

Earlier quoted context omitted.

Do you happen to know what Linus didn't like about Mercurial?

I wonder this too. My guess is that he did not like "heavyweight" branching and the lack of cherry-pick/rebase. At any rate that is why I didn't like it back then. Sun Microsystems (RIP) back then went with Mercurial instead of Git mainly because Mercurial had better support for file renames than Git did, but at Sun we used a rebase workflow with Mercurial even though Mercurial didn't have a rebase command. Sun had b…

Ironically hg now has better rebasing than git e.g. the evolve extension

Re: 20 years of Git

#102

Post by heresie-dabord »

forrestthewoods wrote: post #71
jordigh wrote: post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

[flagged]

> In my 18 years of professional dev I’ve never actually used Git professionally. Git is for hobby side projects. Perforce and Sapling are for adult projects.

I have encountered Perforce, Mercurial, and git professionally throughout my career. Considering the prominence of git in the market, it must be obvious that git does some combination of things right. I myself have found git to be solid where the other salient choices have had drawbacks.

The use of git it so widespread that it is hardly a local minimum.

Re: 20 years of Git

#103

Post by forrestthewoods »

heresie-dabord wrote: post #102
forrestthewoods wrote: post #71

Earlier quoted context omitted.

[flagged]

> In my 18 years of professional dev I’ve never actually used Git professionally. Git is for hobby side projects. Perforce and Sapling are for adult projects. I have encountered Perforce, Mercurial, and git professionally throughout my career. Considering the prominence of git in the market, it must be obvious that git does some combination of things right. I myself have found git to be solid where the other salient…

*local maximum

Re: 20 years of Git

#104

Post by forrestthewoods »

squiggleblaz wrote: post #98
forrestthewoods wrote: post #71

Earlier quoted context omitted.

[flagged]

A local minimum is a point in the design space from which any change is an improvement (but there's other designs which would be worse, if they make several larger changes). I think it's hard to make that claim about Git. You're probably referring to a local maximum, a point in the design space from which any change makes it better (but there's other designs which would be better, if they make several larger changes)…

> it's also been easy to teach to newbies

The number of guides proclaiming the ease of Git is evidence that Git is not easy. Things that are actually easy do involve countless arguments about how easy they are.

I can teach an artist or designer who has never heard of version control how to use Perforce in 10 minutes. They’ll run into corner cases, but they’ll probably never lose work or get “into a bad state”.

Re: 20 years of Git

#105

Post by rdtsc »

zahlman wrote: post #94
jordigh wrote: post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

Do you happen to know what Linus didn't like about Mercurial?

I may be misremembering but c vs python was a part of it. I don't think Linus thought too highly of python, or any interpreted languages, except shell perhaps, and didn't want to deal with installing and managing python packages.

Re: 20 years of Git

#106

Post by pseudalopex »

zahlman wrote: post #94
jordigh wrote: post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

Do you happen to know what Linus didn't like about Mercurial?

Linus worried Mercurial was similar enough to BitKeeper that BitMover might threaten people who worked on it. Probably he had other complaints too.

Re: 20 years of Git

#107

Post by pseudalopex »

squiggleblaz wrote: post #98
forrestthewoods wrote: post #71

Earlier quoted context omitted.

[flagged]

A local minimum is a point in the design space from which any change is an improvement (but there's other designs which would be worse, if they make several larger changes). I think it's hard to make that claim about Git. You're probably referring to a local maximum, a point in the design space from which any change makes it better (but there's other designs which would be better, if they make several larger changes)…

Git being easy to teach to newbies is an uncommon opinion. It was not clear if you meant easier than Subversion. But this would be even more uncommon.

Re: 20 years of Git

#108

Post by wat10000 »

forrestthewoods wrote: post #71
jordigh wrote: post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

[flagged]

In my 25ish years I’d professional dev, I’ve used git for about 15 of them. I’ve never used Perforce and never even heard of Sapling.

It’s very likely that most if not all of the software stack you’re using to post your comment is managed with git.

Re: 20 years of Git

#109

Post by remexre »

squiggleblaz wrote: post #98
forrestthewoods wrote: post #71

Earlier quoted context omitted.

[flagged]

A local minimum is a point in the design space from which any change is an improvement (but there's other designs which would be worse, if they make several larger changes). I think it's hard to make that claim about Git. You're probably referring to a local maximum, a point in the design space from which any change makes it better (but there's other designs which would be better, if they make several larger changes)…

> A local minimum is [...]

Unless you're in ML, in which case it's a minimum of the loss function, not the utility function...

Re: 20 years of Git

#110

Post by zahlman »

esafak wrote: post #8

> He meant to build an efficient tarball history database toolset, not really a version control system. He assumed that someone else would write that layer. Famous last words: "We'll do it the right way later!"

On the flip side: when you do intend to make a larger project like that, consciously focusing on the internal utility piece first is often a good move. For example, Pip doesn't offer a real API; anyone who wants their project to install "extra" dependencies dynamically is expected to (https://stackoverflow.com/questions/12332975) run it as a subprocess with its own command line. I suspect that maintaining Pip nowadays would be much easier if it had been designed from that perspective first, which is why I'm taking that approach with Paper.
Post reply on HN