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

321–330 of 454 posts

Re: Why SQLite does not use Git (2018)

#321

Post by matheusmoreira »

willdr wrote: post #198
NikkiA wrote: post #109

Earlier quoted context omitted.

Actually it does, because with the windows git it includes it's own copy of ssh and bash, both of which will clash and fight with msys and/or other ssh installs - including the copy of ssh that microsoft themselves tuck away in \windows\system32 it's quite 'normal' for git-for-windows' ssh-agent to completely disable ssh-agent from working properly system-wide because it ends up pointing things at the wrong ssh-agent…

But a developer isn't using Windows.

If only that were true. Linux really should be the developer's system but for many reasons it isn't for a lot of people.

Re: Why SQLite does not use Git (2018)

#322

Post by htfu »

sanderjd wrote: post #312
GabrielTFS wrote: post #303

Earlier quoted context omitted.

> I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout. Welp, I guess there's me, but it does indeed seem like adoption of the new commands hasn't been very forthcoming - I guess that's what happens when "the old way still works just fine" - but personally I'd expect that more and more people will change to the new commands over time.

It makes sense for old timers to keep just doing it the way we always have, but I wonder how newcomers to version control are being taught. I would really hope they aren't just being thrown a bunch of these inscrutable commands by their leads, like when I learned it!

Judging by my colleagues (whether more or less experienced than me), "whatever the GUI allows for".

Yes, almost the entire company runs on the subset of git presented by Visual Studio and Azure DevOps. I would guess this is more and more common, and even the more obvious shortcuts available for many things through git itself will become more and more arcane.

Re: Why SQLite does not use Git (2018)

#323

Post by londons_explore »

sanderjd wrote: post #310
eru wrote: post #257

Earlier quoted context omitted.

I think mostly it will depend on what we will call the replacement to git. We might end up calling it 'git', too. Less weirdly: ethernet has been replaced a few times already, but they always just end up branding the replacement as a new version of 'ethernet'.

I think this is a great point! What even is "git"? If it's the binary program named "git", then there are already lots of replacements for that binary that people use, and it would not be surprising at all if one of those different frontends becomes more dominant than "git" itself. But if "git" is the protocol, the specification of how a particular construction of a database of versions, then I suspect that will be p…

Old versions of the git binary are incompatible with new versions.

I suspect everything about git is the ship of Theseus

Re: Why SQLite does not use Git (2018)

#324

Post by asnyder »

toastal wrote: post #243

I've been getting the hang of darcs recently. There's been your typical hiccups of learning something new, but it’s been an interesting process. I wouldn’t be surprised to see a Patch Theory-based DVCS be the Git successor, & if true, darcs will be the early inspiration and the terminology would likely be copied from darcs when in doubt so it doesn’t feel like a waste to learn. It’s definitely not a beta software sup…

Sorry to tell you but git won out over darcs back in the very beginning.

I loved darcs, unfortunately everyone else got on the git bandwagon. Fortunately darcs has built in conversion to git so all is not lost!

Unfortunately though you do lose some of the pleasantry of darcs but such is life...

Re: Why SQLite does not use Git (2018)

#325

Post by p-e-w »

amadeuspagel wrote: post #311
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…

The internet tends to lock things in. There were many languages dominant in history at some point or another, english will be the final one. There were many scripting languages, javascript will be the final one. Many networking protocols, TCP/IP the final one. Same for git. I think the only thing that might displace git is some environment for new programmers with its own version control system like glitch[1]. [1]: h…

> The internet tends to lock things in.

More generally, a globally connected civilization locks things in, once they are sufficiently widespread.

Barring an apocalypse, our present is eternity. I'm always amused when I read science fiction that assumes in the future, Chinese will be the lingua franca, or that we'll have political offices modeled after Ancient Rome, or that there's a world government, or similar nonsense.

To paraphrase O'Brien from 1984: "If you want a picture of the future, imagine a crony-capitalist, meme- and outrage-driven society that always seems on the brink of collapse but never actually does collapse – forever."

Re: Why SQLite does not use Git (2018)

#326

Post by datavirtue »

jon-wood wrote: post #320
bonzini wrote: post #252

Earlier quoted context omitted.

Subversion is basically CVS done right. The problem is that CVS was a dead end that didn't scale to a distributed development model. Git goes back to the local RCS model and adds atomic commits to that model. That's how it climbed out of the local optimum that was Subversion. There were a couple controversial choices that Git made, for example not tracking renames and not having linear revision numbers, but they turn…

I should at some point alias git checkout to throw a warning, git switch/restore are clearly a better choice, but unfortunately checkout is ingrained in muscle memory at this point.

"what the hell is git switch" --every developer

Re: Why SQLite does not use Git (2018)

#327

Post by datavirtue »

mattbillenstein wrote: post #288
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…

Point could be made people don't really use git anymore - they use github as the primary interface. Branching, merging, review, etc.

The only git GUI I use is GitLens. I have always found the command line much easier to understand...and the GUIs make me nervous.

Re: Why SQLite does not use Git (2018)

#328

Post by sidpatil »

p-e-w wrote: post #325
amadeuspagel wrote: post #311

Earlier quoted context omitted.

The internet tends to lock things in. There were many languages dominant in history at some point or another, english will be the final one. There were many scripting languages, javascript will be the final one. Many networking protocols, TCP/IP the final one. Same for git. I think the only thing that might displace git is some environment for new programmers with its own version control system like glitch[1]. [1]: h…

> The internet tends to lock things in. More generally, a globally connected civilization locks things in, once they are sufficiently widespread. Barring an apocalypse, our present is eternity. I'm always amused when I read science fiction that assumes in the future, Chinese will be the lingua franca, or that we'll have political offices modeled after Ancient Rome, or that there's a world government, or similar nonse…

> More generally, a globally connected civilization locks things in, once they are sufficiently widespread.

This idea is known as the end of history.

https://en.m.wikipedia.org/wiki/End_of_history

Re: Why SQLite does not use Git (2018)

#329

Post by gumby »

medstrom wrote: post #295
mattbillenstein wrote: post #288

Earlier quoted context omitted.

Point could be made people don't really use git anymore - they use github as the primary interface. Branching, merging, review, etc.

How many people know GitHub can do that? Your comment was the first I'd heard about it.

I suspect it’s the opposite way around: most people, when they hear “git”, macroexpand it to “github” and don’t even know that there is a (more powerful) command-line interface.

The peer-peer distributed nature is barely known — these days it’s a centralized client/server system. I remember the Internet connection going out at work a few years ago and developers saying they couldn’t coordinate bc github was not accessible when they could easily have synced, merged etc with each other directly.

Re: Why SQLite does not use Git (2018)

#330

Post by forrestthewoods »

josephg wrote: post #275
ogurechny wrote: post #183

Earlier quoted context omitted.

Then the author of that script is the one who deals with said complexity in that specific manner, either because of upstream inability to provide releases for every combination of operating system and hardware, or because some people are strictly focused on hard problems in their part of implementation, or something else. A package manager with “well designed” packages still can't define what they do, invent program…

> A package manager with “well designed” packages still can't define what they do, invent program logic and behavior. The solution to this is easy and widespread. Just ship scripts with the package which allow it to compile and configure itself for the host system. Apt, npm, homebrew and cargo all allow packages to do this when necessary. A well designed PyTorch package (in a well designed package manager) could cont…

> Just ship scripts with the package which allow it to compile and configure itself for the host system.

Eek. That sounds awful to me. it is exceptionally complex, fragile, and error prone. The easy solution is to SHIP YOUR FUCKING DEPENDENCIES.

I’m a Windows man. Which means I don’t really use an OS level packages manager. What I expect is a zip file that I can extract and double-click an exe. To be clear I’m talking about running a program as an end user.

Compiling and packaging a program is a different and intrinsically more complex story. That said, I 1000% believe that build systems should exclusively use toolchains that are part of the monorepo. Build systems should never use any system installed tools. This is more complex to setup, but quite delightful and reliable once you have it.

Post reply on HN