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

251–260 of 454 posts

Re: Why SQLite does not use Git (2018)

#251

Post by justincormack »

fbdab103 wrote: post #104
maxxk wrote: post #42

Earlier quoted context omitted.

> git, for all its issues, is not bundling the kitchen sink. It doesn't bundle the kitchen sink in its native *nix environment, but for Windows it does. Git installer is > 50 MB, including (if I remember correctly) even a terminal. While you can download Fossil as a 3.3 MB standalone binary for any supported platform.

Let's not forget how long it even took for there to be a reasonable Windows build of git. Git implicitly relied on significant amounts of Linux tooling which required bringing over an entire Mingw environment.

Er, it was written by Linus for use in Linux...

Re: Why SQLite does not use Git (2018)

#252

Post by bonzini »

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…

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 turned out to be not a big deal and they allowed very efficient operations without the performance issues of e.g. darcs.

Given all the attempts to fix version control between 1995 and 2010, the basic data model of git seems to be very hard to improve on, especially with additions such as git-lfs.

There could be new command line interfaces but it has become harder and harder to kick away the incumbents. I know no one who is using git switch and git restore instead of the overloaded and confusing git checkout.

Re: Why SQLite does not use Git (2018)

#253

Post by Zacharias030 »

test1235 wrote: post #230
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…

So it looks like you're ready for a change ... What's next on the horizon?

Generally git‘s support for a stacked PR workflow is poor [0], but imho that is the future of team collab (git is great for very asynchronously built projects, like the linux kernel). I also wonder, how much better git could be if it was based on DAGs not trees (I may want to use a changeset that is still developing in more than one branch without maintaining copies of it) and corollarily I‘d like to rebase subtrees (sub-DAGs) instead of single branches.

I have introduced a stacked PR workflow to our team a while ago and a few months later half of the team had migrated to some kind of stacked PR workflow tool (on top of github and git, even though support is sub-optimal). It seems like this is an idea that is really sticky.

[0] https://github.com/ezyang/ghstack

Re: Why SQLite does not use Git (2018)

#254

Post by flohofwoe »

lolive wrote: post #220
_Algernon_ wrote: post #214

Earlier quoted context omitted.

Git BASH (from that page) is what they referred to when they said "you literally have to bring half of a whole unix with you to run git".

GitBash, AutoHotkey, Notepad++, 7zip and PowerToys are the basic installs I do on any Windows I am given. Any dev opening a CMD is suspect, to me.

Except that pretty much all cmdline scripts on Windows are either .bat or .ps scripts, which in turn have tons of Window-isms built into them.

If you are using bash on Windows that just tells me that the software you build probably won't be integrated all that well with Windows ;)

(git and other "UNIX-y" tools work mostly fine on cmd.exe btw)

Re: Why SQLite does not use Git (2018)

#255

Post by maccard »

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.

That's a very naive view.

Re: Why SQLite does not use Git (2018)

#256

Post by nwallin »

tootie wrote: post #102
zeroimpl wrote: post #100

Seems like a textbook example of NIH to me. By the time you understand git well enough to design a good replacement, you’re bound to be an expert and ought to appreciate more the design of git. If you don’t like the lack of a good GUI or web application, you can just build one that works the way you want and still works with git.

Not to be whiny, but we had better versions of git before git was the standard. I'm thinking specifically of Mercurial.

Git came before Mercurial. Both git and Mercurial were spawned by the same event; BitKeeper revoking its free license for Linux kernel development.

Git development began 2005-04-03, and was self hosting on the 7th. The next minor release of Linux used git as its SCM. Mercurial was announced on 2005-04-19, and has been self hosting since 2005-05-03.

Original git commit: https://github.com/git/git/commit/e83c5163316f89bfbde7d9ab23...

Original Mercurial commit: https://repo.mercurial-scm.org/hg/rev/9117c6561b0b

Re: Why SQLite does not use Git (2018)

#257

Post by eru »

quietbritishjim wrote: post #228
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…

In fairness, the rate of change of any type of tool slows down over time as the problem domain becomes well understood. It's like the Joel on Software article (which annoyingly I can't find at the moment) about how software is always pretty much done by about version 4. His example was office software, especially Excel, and sure enough if you loaded Excel 4 today you'd see it does fundamentally all the main things. I…

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

Re: Why SQLite does not use Git (2018)

#259

Post by bobmaxup »

jasonjayr wrote: post #26
willtemperley wrote: post #2

https://git-man-page-generator.lokaltog.net is the funniest thing I've seen in a while

> git-erase-working-treeshould be used when you want to cautiously erase the current working tree of an upstream root and the config, and want to quiltimport to a active GUI. sounds useful!

https://git.savannah.nongnu.org/cgit/quilt.git/tree/quilt

Re: Why SQLite does not use Git (2018)

#260

Post by jdrek1 »

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.

That's a pretty ignorant view, there's tons of developers using Windows. If you take a look at the SO survey (or similar ones), Windows has 47% in the "Professional use" category.
Post reply on HN