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

311–320 of 454 posts

Re: Why SQLite does not use Git (2018)

#311

Post by amadeuspagel »

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]: https://medium.com/glitch/reinventing-version-control-with-g...

Re: Why SQLite does not use Git (2018)

#312

Post by sanderjd »

GabrielTFS wrote: post #303
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 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!

Re: Why SQLite does not use Git (2018)

#313

Post by erik_seaberg »

KerrAvon wrote: post #137
forrestthewoods wrote: post #91

Earlier quoted context omitted.

Git is a “distributed version control system” (DVCS). You’re just adding the term “source code” for no particular reason. I make video games. Video games contain far more data than mere source code. Almost all game devs use Perforce because Git is insufficient. Artists and designers desperately need more version control in their lives. They are mostly absent because their programmers use Git which is insufficient. It…

Ah, this is why you have a bad attitude about the “D” part of “DVCS”, right? The workflow for art is “I need to lock that graphics asset so that no one else edits it while I’m editing it,” which you can’t do with a DVCS. Disallowing exclusive edits is generally what most programming teams want; otherwise it’s a daily occurrence to try to get someone to unlock a file they locked for editing and forgot about.

Locking is just punting on the problem. If a version control system can't merge non-conflicting changes to the same file by different people, that file is unmaintainable and shouldn't have been checked in as if it were source code. Instead it should be generated from a set of files that can be edited normally.

Re: Why SQLite does not use Git (2018)

#314

Post by renegade-otter »

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…

Right, and a lot of tools out there already provide a less horrible Git experience by taking care of all the user-hostile command-line arguments (SmartGit, etc).

The only problem with Git is that it is not user-friendly - and that is the Porcelain, the nice API version.

Re: Why SQLite does not use Git (2018)

#315

Post by maccard »

masklinn wrote: post #294
tester756 wrote: post #278

Earlier quoted context omitted.

git gets bad rep because its cli is a terrible mess if apple designed git's cli it'd be bilion times better from ux perspective while only 10% less powerful I guess

Eh. Apple’s cli utilities are hot garbage, and with some of the poorest documentation you can find when they’re at all documented. As bad as git is, and god knows it’s bad, launchctl is in an other galaxy of unusability.

At least launchctl is usable as a cli. Look at the xcode command line tools, in particular try to sign a bundle from the command line.

Re: Why SQLite does not use Git (2018)

#316

Post by sanderjd »

eru wrote: post #301
lloeki wrote: post #296

Earlier quoted context omitted.

I seem to understand GP wants to move a whole DAG potentially having multiple leaves, not just a DAG ending at a single leaf. IOW git rebase --onto shaX shaY shaZ ends at shaZ, git walks backwards from it until the commit whose parent is shaY to produce the list of commits to cherry-pick onto shaX So presumably this would be useful: git rebase --onto shaX shaY [shaZ1 shaZ2 shaZ3 ...] with shaZn being optional and con…

OK, that makes sense. I think if you wanted to do this, it would probably be easiest to produce an artificial leaf that points to all the leaves you want to rebase.

Yes, and the original commenter's point is that git does not support this well, at the data model layer even. Because commits have exactly one parent commit, which is immutable, and because rebasing creates a new commit, rebasing an entire subtree with N nodes under it requires N operations, rather than just 1.

Personally I think it's a pretty small price to pay for the advantage of the single-immutable-parent model, but I do think it's surprising that there aren't better tools for this workflow. I do this all the time, but manually and painstakingly.

Re: Why SQLite does not use Git (2018)

#317

Post by matheusmoreira »

qbasic_forever wrote: post #86
ohthatsnotright wrote: post #21

I'm glad Fossil works for them, but this line is bothered me: > In contrast, Fossil is a single standalone binary which is installed by putting it on $PATH. That one binary contains all the functionality of core Git and also GitHub and/or GitLab. It manages a community server with wiki, bug tracking, and forums, provides packaged downloads for consumers, login managements, and so forth, with no extra software require…

Git actually is bundling a lot of stuff you probably don't realize. Run 'git instaweb' for example and it will spin up a local CGI server and perl CGI script to give a very simple web UI: https://git-scm.com/docs/git-instaweb Fossil isn't much different in core functionality here. There is a ton of email client integration and functionality in git too that most people who only use GitHub probably have absolutely no i…

Git send-email is actually the best email client I've ever used. It's the only reason I managed to post to mailing lists. I couldn't figure out anything else.

Re: Why SQLite does not use Git (2018)

#318

Post by maccard »

jpc0 wrote: post #187
FpUser wrote: post #66

Earlier quoted context omitted.

Can't imagine reading code on those tiny screens.

And this is why you should stick to an 80 column limit. It's only a pain when you decide your codebase is fine with 120+ columns because "everyone has a widescreen monitor" except no they don't. What if I like vertical monitors, or want 5:4 etc.

Having to cater to the absolute lowest common denominator holds back progress. Why should I be forced to adapt your preferred workflow and limitations if I prefer to have a wide-screen monitor or another standard tool.

Re: Why SQLite does not use Git (2018)

#319

Post by maccard »

Brian_K_White wrote: post #57
NBJack wrote: post #7

I think there are some legitimate criticisms of Git here. But some of them are...odd. Despite using Git in a variety of circumstances, from a local personal repo project to very large company repos, I admit I haven't run into about half of these issues. > The closest I have found is the network, which is slow to render (unless it is already cached), does not offer nearly as much details, and scarcely works at all on…

There are all kinds of non-optimal optional ways to do things where it's valuable to have the options and have them work as well as possible vs not having the option. I guess it falls under graceful degrade vs die. It doesn't matter how much better the proper gold plated option is. If it's the only option then it's fragile and that makes it garbage.

I disagree. If the alternative is to force everyone to have a sub par experience, them I'd rather a single enforced standard that is usable.

Re: Why SQLite does not use Git (2018)

#320

Post by jon-wood »

bonzini wrote: post #252
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 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.
Post reply on HN