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

Why SQLite does not use Git (2018)

sqlite.org

Post reply on HN
Print view View original

231–240 of 454 posts

Re: Why SQLite does not use Git (2018)

#231

Post by brmgb »

anon35 wrote: post #210

Made a list of all the revision control tools I've used over the decades, the year they were created, and the year I last used them: sccs 1973 2000 rcs 1982 2000 cvs 1990 2004 clearcase 1992 2004 perforce 1995 2011 subversion 2000 2015 mercurial 2005 2015 git 2005 present So, at least for me, they last around 15 years or so. But often time when I tell juinors that when they're my age, git will be distant a strange me…

I migrated a project from clearcase to git at my first company and for all the hate I have for clearcase even I agree there was little point in switching to something else before. We had a bit of svn on other part of the company but that was it.

VCS don’t change that fast. All the tools you list before the advent of DVCS actually have a lot in common. I think git will be there for some time.

Re: Why SQLite does not use Git (2018)

#232

Post by tehbeard »

School-Cotton wrote: post #153
mintplant wrote: post #25

Earlier quoted context omitted.

All the time. I would say at least 50% of my code browsing is done from my phone. I make heavy use of the mobile GitHub web interface for this (find-references support has been a godsend, search is still meh, I hate how they keep breaking basic find-in-page with SPA jank). Also Searchfox [0] when I need to comb through Firefox code (fast, excellent, no complaints—well, I guess blame on mobile could be better). Contex…

Why are you so often in situations where you want to browse code but don’t have access to a general-purpose computer?

I've looked at libraries on github during the commute from links in newsletters.

But never done any serious work off a phone, bar irl device testing for "hand feel" of the UI/UX

Re: Why SQLite does not use Git (2018)

#233

Post by jorvi »

ozim wrote: post #221
Guvante wrote: post #185

I think git gets a bad rep because no one can agree how to use it. GitHub PRs vs pushing a branch, rebase vs merge are just two examples of tools that do identical things in fundamentally different ways. And the problem is none of them are wrong. Rebasing minor commits simplifies unnecessary complexity in your history. Merging preserves what actually happened which can provide insight into why changes occurred. Of co…

To paraphrase Bjarne Stroustrup, there are only two kinds of version control systems: the ones people complain about and the ones nobody uses.

Reminds me of what Bungie said in one of their GDCs. They don’t mind it (too much) if people get heated on their forum or subreddit, because people who care about Destiny are the ones that get worked up. It’s when most stop complaining or praising that they get worried, because it means apathy has set in.

Re: Why SQLite does not use Git (2018)

#234

Post by samtho »

jorvi wrote: post #233
ozim wrote: post #221

Earlier quoted context omitted.

To paraphrase Bjarne Stroustrup, there are only two kinds of version control systems: the ones people complain about and the ones nobody uses.

Reminds me of what Bungie said in one of their GDCs. They don’t mind it (too much) if people get heated on their forum or subreddit, because people who care about Destiny are the ones that get worked up. It’s when most stop complaining or praising that they get worried, because it means apathy has set in.

This is a bit of wisdom that is easy to miss when you are developing a product. When people are getting worked about something and are very vocal, positive or negative, it means they care in some way. Instead of going into the doom spiral of “nobody likes what I’m building,” you can reframe it to be, “people are very passionate about what I’m building,” which is a better way to start the discussion of how to make what you have better.

The opposite of love is not hate, it’s apathy.

Re: Why SQLite does not use Git (2018)

#235

Post by taneq »

herewulf wrote: post #201
taneq wrote: post #119

Earlier quoted context omitted.

"You're using Windows so you obviously want an entire mini-Cygwin type environment for your source control software"

Actually I do to save me from the deprived interfaces the OS ships with. The Git install is one of the best Cygwin-likes I've encountered. It has the majority of tools needed and reasonable integration with the host OS. Very nice for getting something done quickly on any random Windows box.

It's fine if you don't have anything else installed already, but I have MSYS2 installed so it'd be nice if it were optional. Realistically an extra 50mb is not going to materially affect my life, but it's still aesthetically displeasing.

Re: Why SQLite does not use Git (2018)

#237

Post by genocidicbunny »

happymellon wrote: post #224
forrestthewoods wrote: post #170

Earlier quoted context omitted.

> you are trying to force a bad usecase The world has non-text files that require version control support. Version control systems are mostly bad-to-terrible for anything other than source code. Implying that the use case is wrong is borderline offensive. It’d be nice if there were some artist/designer friendly version control systems. I can teach someone who has never even heard of version control how to use Perforc…

> The world has non-text files that require version control support Which is fine, but saying that git is rubbish because it doesn't handle binary files as you want it to is a bad usecase. How version control would handle diffs between PDFs is not the same as photos, which is not the same as video. They have to be content aware for these sorts of things.

Well, to be frank, git doesn't really handle binary files _at all_. I don't really consider treating binary files as opaque blobs of data as 'handling them'. It's more akin to throwing your hands up and saying 'fuck it, we'll treat it like the text stuff and whatever happens, happens.' Yes, over time git has gained some capability for handling binary data as delta patches, but it is so far away from anything even remotely resembling content-awareness.

Re: Why SQLite does not use Git (2018)

#238

Post by toastal »

kasperset wrote: post #106

I saw this video few days ago which describes some of the alternative to Git and of course Fossil is one of them. I have used Fossil in some projects and found to be ok. I found Pijul https://pijul.org/ described in this talk to be very interesting. It was discussed on HN before. Source: https://www.youtube.com/watch?v=M4KktA_jbOE

Pijul will be ready when it support the ability to email patches as a universal fallback method of submitting patches upstream for those that do not wish to create an account with a given service.

Re: Why SQLite does not use Git (2018)

#239

Post by junon »

johannes1234321 wrote: post #103
blagie wrote: post #46

Most of these arguments are nonsense. "Standing up a git server is non-trivial." It's literally just "git init" and providing ssh access to the directory. Most of the other ones seem to suggest the author never learned git. git has a beautiful data model and a horrible user-space to poke at it. Writing a new user-space makes sense. This seems to poorly re-invent the data model, by virtue of not bothering to understan…

> and providing ssh access to the directory Well, doing that securely and somewhat aclainf isn't easy and file access permissions are a pain. If you remember to update the index regularly serving .git via HTTP is easy for read-only access, but all else is quite a bit more involved.

I have no idea what this comment implies. File permissions are a Unix way of life. You'd always have security considerations even with Fossil.

Re: Why SQLite does not use Git (2018)

#240

Post by junon »

ThinkBeat wrote: post #169

I am not a Git fan. The most perplexing to me is how huge companies spend 100.000s (1.000.000s??) of $$ to hack Git so that it will git with their needs. Like Google. One of the biggest issues seem to be the size of the repo, which takes days (?) to download and get started. Does Google contribute all their extra services / tools to make Git for work for then?

Unless you're checking out old commits, `git clone --depth=1`. Then you get close to the ideal download size for any given repo.
Post reply on HN