121–130 of 196 posts
Earlier quoted context omitted.
That's also what Git means.
"I'm an egotistical bastard, and I name all my projects after myself." --Linus
There's a lot of different ways that you could interpret the name Linus chose. That's part of what made it clever.
Earlier quoted context omitted.
Git succeeded because it was free, and then business models were able to be built up around the open-source ecosystem after a market evolved naturally. There is a need, but if you go into it trying to build a business from scratch, you're going to have a bad time.
Git succeeded because of Linus. Sure as hell wasn't because of the UX, else Mercurial would have won, or even DARCS. 99.99999% of projects are not the Linux kernel
Earlier quoted context omitted.
Mercurial would not have won. Mercurial has since added features, that are not the recommended workflow according to their docs, to have similar branching model to git but the default "as designed" workflow of hg is arguably inferior to git (yes, I know that word will get downvoted). Without git, git's style of branching would likely never have been added to hg and even though it's been added now AFAICT hg people don…
Git branching is not intuitive, because they are not branches but pointers/labels. When you talk about the master branch, you actually talk about the master pointer. The other VCSes have an intuitive concept of branches, because they are in fact branches. I liked Mercurial more than Git, but when BitBucked dropped Mercurial I also switched to Git.
I started on Mercurial and didn't use Git for years. The moment I switched to Git everything made so much more sense to me. Mercurial seemed like it did magic and wouldn't explain it to you. There were multiple kinds of branches, there were revision numbers, octopus merges were impossible to understand, the whole thing tried to act immutable but effective workflows included history editing for squashing and merging and amending and cherry-picking, which is anything but. Partial commits were a little bit of a mystery to me, and shelves seemed to be their own separate thing.
To me Git was simple in comparison. The working copy was the last state at the end of a long sequence of states. Patches were just the way you represented going from one state to another, rather than canonical, so you woujldn't resolve an octopus merge so much as you would get to your desired state and call it a day. Branches were labels to a particular state. Stashes were labels with an optimized workflow. Reflog was just a list of temporary-ish labels. New commits were built against the index, which you could add or remove to independently of file state. Branches were branches were branches, no matter where the repository was. Disconnecting from upstream was simply a matter of removing a remote.
I know it doesn't match up with other people, but I simply have never been able to see Mercurial as an example of a good tool /despite starting on it/. It's always been easier to use git at any level of complexity I need it depending on the problem I'm solving, whether it's saving code or rescuing a totally botched interactive rebase, merge, etc.
Earlier quoted context omitted.
being free is a huge plus; but more equally or even importantly, it's a better product.
Was git really better than for example Mercury or Darcs for most 'normal' projects when it was released? I certainly don't remember it as such. It was certainly better for Linus and the specific workflow problems he had with kernel development, but I don't recall it being better overall at the time. What its release (and the very public BitKeeper spat leading up its release) did do was bring the idea of distributed V…
Hg back in the day was quite limited and followed other VCS paradigm (which was enforced on you, by the way).
Earlier quoted context omitted.
"I'm an egotistical bastard, and I name all my projects after myself." --Linus
Linus is self-aware enough that I'm sure there's a kernel of truth to that joke, but both git and mercurial were clearly inspired by the BitKeeper fiasco. They describe an unpleasant and ill-tempered person, respectively. There's a lot of different ways that you could interpret the name Linus chose. That's part of what made it clever.
Earlier quoted context omitted.
Mercurial would not have won. Mercurial has since added features, that are not the recommended workflow according to their docs, to have similar branching model to git but the default "as designed" workflow of hg is arguably inferior to git (yes, I know that word will get downvoted). Without git, git's style of branching would likely never have been added to hg and even though it's been added now AFAICT hg people don…
Git branching is not intuitive, because they are not branches but pointers/labels. When you talk about the master branch, you actually talk about the master pointer. The other VCSes have an intuitive concept of branches, because they are in fact branches. I liked Mercurial more than Git, but when BitBucked dropped Mercurial I also switched to Git.
The transparency of the mechanism enables the user to be more powerful while knowing fewer concepts in total. The power of the system comes from the composition of simple parts.
Earlier quoted context omitted.
Linus is self-aware enough that I'm sure there's a kernel of truth to that joke, but both git and mercurial were clearly inspired by the BitKeeper fiasco. They describe an unpleasant and ill-tempered person, respectively. There's a lot of different ways that you could interpret the name Linus chose. That's part of what made it clever.
“Mercurial” doesn’t mean ill-tempered. It typically means fickle, changing. That can be related to moods (regularly pleasant, but inclined to fly off the handle with little provocation) but that is by no means its only application. It can also mean sprightly (connecting with the “changing” meaning), which is quite the opposite of ill-tempered.
Earlier quoted context omitted.
Mercurial would not have won. Mercurial has since added features, that are not the recommended workflow according to their docs, to have similar branching model to git but the default "as designed" workflow of hg is arguably inferior to git (yes, I know that word will get downvoted). Without git, git's style of branching would likely never have been added to hg and even though it's been added now AFAICT hg people don…
Git branching is not intuitive, because they are not branches but pointers/labels. When you talk about the master branch, you actually talk about the master pointer. The other VCSes have an intuitive concept of branches, because they are in fact branches. I liked Mercurial more than Git, but when BitBucked dropped Mercurial I also switched to Git.
Earlier quoted context omitted.
Git succeeded because it was free, and then business models were able to be built up around the open-source ecosystem after a market evolved naturally. There is a need, but if you go into it trying to build a business from scratch, you're going to have a bad time.
Git succeeded because of Linus. Sure as hell wasn't because of the UX, else Mercurial would have won, or even DARCS. 99.99999% of projects are not the Linux kernel
The first time I used Git I swore I would never use SVN again. It was even popular back then to set up git+svn systems so you could work on your git repo, and push a branch to svn to satisfy your employer.
People associate git with Github (and Gitlab), but it used to be very common to just set up a ssh server that people could push projects on to, my server still has a dozen or so projects on it that I haven't touched in a decade. Github spawned from the popularity of Git in the Ruby community, and the desire to make it a little more accessible to people that didn't want to have their own git servers.
Only 39 days since the last "GitHub for data" was announced: https://news.ycombinator.com/item?id=22375774 I'll say what I said in February: I started a company with the same premise 9 years ago, during the prime "big data" hype cycle. We burned through a lot of investor money only to realize that there was not a market opportunity to capture. That is, many people thought it was cool - we even did co-sponsored data c…
I guess "Git for data" is not very useful if you don't have the whole platform built around it to actually use the features. We mainly use it for data synchronization between the nodes and provenance tracking so people can see what data was used to build specific models and to track how the project evolves itself without forcing people to "commit" their changes manually (as we have seen that often data scientists don't even use git, just files on their Jupyter notebooks).