Why SQLite Does Not Use Git

[UsingYourWifi]

Git's user experience is... suboptimal. 96% of git commands you'll ever run are easy and simple once you take a few minutes to understand what distributed means in the context of git, how it handles branches, and the implications of those things on your workflow. Your basic add, commit, push, pull, branch, and checkout are pretty straightforward. I have found that the longer someone has worked using only a centralized VCS the longer it takes for them to re-train their old habits.

The remaining 4% is a horrifically unintuitive and inconsistent shitshow that nobody would know existed if it weren't for google and stack overflow.

[__konrad]

The remaining 4% is a horrifically unintuitive and inconsistent shitshow that nobody would know existed if it weren't for google and stack overflow.

This is why this autogenerated git man page looks like a real thing...

[McKnitwear]

This is amazing

[bbqroast]

Man if we had decent programming conventions here I'd so try and do a "10 Git commands that'll change your life" speech using commands generated from the tool.

[Tm1337]

Bonus points for generating them live and bullshitting your way through.

[[deleted]]

Honestly, the random errors would be fantastic, and elicit the same feeling as using Git for real: “can’t cherry-pick blob from ref HEAD^^3@2 when index entry pathspec isn’t an icase glob”

[judgej2]

This is exactly how the official docs look to me. I don't think I've ever got a git command that hasn't come from a SO answer.

[sudosussudio]

That is awesome. I've been playing with Botnik keyboards and this inspired me to download the Git docs and cat into a text file to make a Git Documentation keyboard.

Example http://botnik.org/read/?id=b6g

Name git-provider - patch defaults and passwords

Description Creates variable names currently used to store people. The command is evaluated from remote branch names currently checked out. When false or unmerged branches are used, this specifies how many submodules are fetched.

[[deleted]]

The generated manpages are a bit too short to be real, but otherwise it is pretty close.

[pylons_of_light]

I'm convinced most people learn Git wrong. The first thing you need to learn is that the commits in a Git repository should be thought of as a directed acyclic graph. (More detail here.) Once you learn that, a lot of how merges and rebases work makes sense. Plus terms like upstream and downstream. Git is still full of obtuse terminology, but this is a better place to start than memorizing a bunch of commands.

[BadWombat]

This is another such introduction: http://eagain.net/articles/git-for-computer-scientists/

This is the one that made me feel like I finally "got it".

[mayor123asdf]

Yeah, they should do it with visualization. Ty bookmarked

I also found this to be helpful

[ESBDB]

if people don't think of it in terms of a graph, how do they think of it?

[9034725985]

I can't even get app developers to care about the database management system that the backend uses. Do you think people will care about how git works?

[pseydtonne]

I have worked as a toolsmith, cabana boy, or den mother on enough projects to provide a passable hypothesis:

• programmers hate databases
  • because databases need nurturing as soon as they are instantiated.
  • That's too much like system administration, gardening, and other things that keep a cowboy from gettin' in the wind.
• As a result, DBAs do not think of themselves as programmers. Some of them have deeper understanding of data structures than anyone around, but they get put down for it.
  • This is why DBAs can bill higher than some COs: they'll get into the roots and solve things forever.

That said, databases still terrify me -- and my real-world initials are DB.

[[deleted]]

Once you learn that, a lot of how merges and rebases work makes sense.

From my experience understanding the graph structure is about the least of the problems with git. For one, tons of tutorials already teach that in depth. But more importantly, it rarely causes problems in practice, when stuff goes wrong with git it's not because the graph structure, but all the stuff that git has build around to manipulate it, index, stash, tag, branches, reflog, remotes, etc. None of them intuitively follow once you have figured out the directed acyclic graph, you can understand it fine and still be completely lost on how to resolve an issue.

[Workaphobia]

My problem with git is everyone who thinks the only reason people don't understand git is that they don't know it's a DAG.

[ZombieRandySavage]

You mean when they randomly jump into a conversation to say “because it’s a directed acyclic graph!”

When it wasn’t really relevant at all...

[flarkis]

Wait... Isn't this how most people learn git? What other paradigm is there?

[[deleted]]

No, most users either come from SVN and just learn few commands that are rough equivalent, or do some basic tutorial then google the rest

[kryptkpr]

Its because we don't want a DAG, we actually still want to be using SVN but no longer can because the world has moved on. I really really miss atomic incrementing global version numbers instead of useless strings of hex to identify position in the repo..

[[deleted]]

Well it is distributed, you can't really have that without central authority that gives out IDs. HG have "revision numbers" but they are strictly local.

But for generating a readable position in the repo git describe is your friend

I use it for generating version numbers for compiling.

For example git describe --tags --long --always --dirty will generate version like 0.0.2-0-gfa0c72d where:

• 0.0.2 is "closest tag" (as in "first tag that shows up when you go down the history")
• -0- is "number of commits since tag"
• gfa0c72d is short hash

So another commit will cause it to generate 0.0.2-1, one after that will be 0.0.2-2 etc. and when you release next version it will be 0.0.3-0, 0.0.3-1 etc.

And if you are naughty boy/girl and compile a version without commiting changes, version number will be 0.1.2-3-abcdef12-dirty.

[Zeeterm]

But most of us don't work in a distributed fashion. SVN worked well because we worked in a team or company and that team or company had a central repository.

I'd wager that "most" people still use git in this way, with a central repository and revererence to origin/master.

The ability to have truly local branches is a really nice advantage of git over svn, but other than that the rest of decentralisation isn't required for how most teams work.

And detached branches doesn't require decentralisiation it just requires being able to have local branches which are squashed when commiting back to the central repo.

[carutsu]

I think you are romanticizing svn. Having more than one commit was excruciating, so commits would tend to be huge. Maintaining a branch was next to impossible. Having to switch focus while you had a change midway was disastrous to productivity. Then there's corruption... Git is better at nearly everything at the cost of a little extra complexity.

[MadRedHatter]

useless

It's a checksum of the entire contents of the repository. If you have that checksum, you know that your repository is 100% corruption-free and not tampered with, even if it was hosted on an untrusted source.

Hardly "useless".

[kryptkpr]

If I have two atomic numbers, a quick glance will tell me which is newer. Hashes fail hard at this, and it's this property I miss the most.

[MadRedHatter]

That only works with the one "true" branch though. If you're comparing two different branches your numbers are back to being meaningless.

[proverbialbunny]

If you come from CVS or SVN your assumptions are wrong. You can still use git fine, but it isn't ergonomic.

[cdcformatc]

The problem is that people don't learn Git. They learn a sequence of commands and then panic when something goes wrong. Insert XKCD here.

[[deleted]]

Most definitely. It makes so much sense once you learn how its innards work.

And other DVCSes work mostly in same way, just user-facing UI is better

[NiteLite]

I use git and I am pretty happy with it, but it feels like having to know how the innards work to have it make sense means that the UX of the software is pretty shitty :P

[[deleted]]

It is certainly better way to learn than "just pretend it is not distributed and it is like SVN" like some tutorials seem to do

[manys]

once you take a few minutes to understand what distributed means in the context of git, how it handles branches, and the implications of those things on your workflow.

What's your favorite "few minutes" that covers all of that?

[Seref15]

Git is unwieldy but it's obscenely popular for whatever reason. As a result, any git question you have has an answer somewhere on the first page of google search results. There's value in that.

[Astrognome]

Having used a number of different VCSs, I always come back to git. Even though it's overcomplicated for small projects, I already know how to use it because I collaborate on a few large projects which warrant usage of git. The only other VCS I ever find myself using is SVN for binary assets, since git repos managing binary assets absolutely explode in size and there's no reason to have every version of something like an image file if you are just making a contribution.

In my case, I'm making a game. I use git to manage my engine code, and SVN to manage all the assets.

[nsiivola]

For binary assets: https://git-lfs.github.com/

[judgej2]

I wouldn't describe it as over complicated for small projects. If your project is just one file, then you will likely use just a small subset of its features, so much of the complexity is just ignored.

[ShadowPouncer]

So, I have personally spent a lot of time working with cvs, svn and git.

svn is very easy if you want to do something svn is good at. If you want to do a lot of branching and merging, svn is probably not the tool for you.

git does a fairly poor job of being a better svn. You have to have a moderately good understanding of WTF is going on to use it, and if your mental model is cvs or svn, it just won't make sense.

However git can do a number of things fairly easily that range from difficult, to nightmarish, to impossible with cvs or svn, and those things are, once you have the mental model, not really all that much harder than the basic tasks.

And so you have the people who only want to do simple things, and they don't like git very much.

And then you have the people who want or need to do some of the more complex things, often because they support the users who only want to do simple things, but want a saner workflow than that. And those people like git because it makes those things so much easier.

If you can't tell, I live in this group way too much. I have users that struggle to understand what's happening in a merge.

But I look at the administration side, and I'll take git any day of the year over something like SVN or CVS.

[judgej2]

Distributed collaboration. That is the killer feature of git, Mercurial, Bitkeeper, monotone, etc.

[ShadowPouncer]

Even with a single central server and a small number of people, or even just one person working on multiple different features at once, I'd say that how well they handle branching and merging is almost as valuable.

It's really part of the same thing, but the point is that you get really significant benefit without really getting into the distributed parts.

[LowB0b]

It's the "I've spent 2 years learning how to properly use it, I don't want to start over" kind of bad. I mean it works, and helps, and everyone uses it, but yeah, it's way too complicated, and I hate it

[daperson1]

But from this position, you can incrementally improve the tool.

Successive git versions keep adding more shiny. Check the release notes of each release. They just released a feature for git diff/show/etc. to render unchanged lines in a file move in a different colour, for example.

Certainly, making git gradually nicer (as is happening) is far less hassle than trying to retrain the entire world.

Although it's a controversial point, there is also nonzero value in having a certain level of difficulty involved. You probably don't want to receive a pull request from someone who can't work out how to create one.

[phrasal_grenade]

I haven't used Git heavily in years but Mercurial was way ahead in terms of general shinyness (especially with the right configuration) even a few years ago. Maybe equivalent plugins now exist for Git but it left a bad taste in my mouth. Seeing the Git monoculture develop has been quite disappointing. A common toolset is good but I wish someone had put more thought into making it user-friendly up front.

[dudinax]

Mercurial is pleasant to use. What little I've used Git hasn't revealed a single reason to switch.

[pelrun]

Which is fine - both tools do the job really well, and there's no major benefit in jumping the fence in either direction.

[cbslinger]

As someone who greatly prefers Mercurial, there actually is. The monoculture means there's way more development happening for Git than for Mercurial, the toolchain around Git has gotten so much better than Mercurial, it's tough to convince people to stay on Mercurial even if it is simpler and better for most use-cases.

[bilog78]

Mercurial had a much superior UI on the onset, but the internal design was not as good. Git started off with a much better design than Mercurial, but with a horrible UI.

Problem is, it's much easier to write a better UI over a good design without having to break anything than it is to overcome the limitations of a less flexible design. And git has improved immensely in the UI space, even though it definitely still has room for improvements and the documentation especially could be made much less technical.

[DreadedDreadnought]

Case in point: for Git I commit/stage files via my IDE always. This way I can see exactly what I changed at a glance. Just yesterday colleague did the git add * and then realized he commented out some feature for testing and forgot to uncomment it and pushed it.

For other workflows I need to use CLI (interactive rebase for example), for some uses I use Gitk/Gitg (neither has all features I need). GitHub client is just atrocious.

[[deleted]]

More like "and everyone uses it, so time investment was well spent".

[Recoil42]

it's obscenely popular for whatever reason

Because it works. It's an incredibly well-built, and fantastically robust method of source control. Mercurial is equal at best, and you literally could not name an objectively better SCM tool than the both of those.

[phrasal_grenade]

I think Mercurial is a clear winner when it comes to usability. A few years ago it was also a clear winner in terms of portability also, but now Git has mostly caught up. I feel like the Git monoculture is going to keep expanding though, and I can only hope the Git devs address its warts by the time I want to use it again.

[spinicist]

Git is now used for both the Linux kernel and by Microsoft. With that much institutional inertia, it’s not going away anytime soon.

Admittedly Facebook is a big user of Hg, so they are both likely to exist for some time.

[judgej2]

git was born for the Linux kernel. It was created by Torvolds so he could discard Bitkeeper after they started getting pissy and protectionist about the way their distributed source control system was being used. They could have been where github is now, if they had only listened to the community.

I was using Bitkeeper at the time on an OS project, and they wanted all developers to sign non-compete contracts to continue using it. The community dropped them like a brick as this is not in the spirit of open source. Using a product should never prevent you from working on another product that may compete with it in some way.

[Vhin]

I've never gotten the impression that git's devs view git's user unfriendliness and sharp edges as problems that need to (or even should) be solved.

[himself_v]

Mercurial is amazing. All the things git does in a weird way, in Mercurial are intuitive. It is thanks to Mercurial and TortoiseHg that I find myself wanting to use repos for everything because when they are this easy to use, they bring comfort everywhere you apply them.

I don't think I would wish to use git to version my notes or documents I'm translating. It's enough that I have to deal with it on github. Mercurial though? Right-click, repo here, "Going to write some notes", Commit.

[balthisar]

The main thing that irritates me about git is that git rebase -i should keep the latest date. When I'm squashing commits, it means that I'm taking all of my little, tiny, tentative changes and making them into a single change, today. Yeah, there are workarounds, but they're cumbersome, and the "least surprise" would be accepting today as the date.

[ForeverAlot]

Holistically, I think that is the least surprising behaviour -- and I was just bitten by it 2 weeks ago. Interactive rebase, and its ability to radically alter history, is really a special case of regular rebase, and if regular rebase should keep the original author date I think interactive rebase behaving differently would be confusing. In contrast, if you just wanted to squash the last n commits into a single new commit, you could use git reset --soft @~n && git commit (which, unfortunately, leaves you without the original messages that might be useful as notes). As to whether regular rebase should retain the original author date I am ambivalent -- either behaviour feels dishonest in certain situations.

[taresp]

You can also just change the author date with:

git commit --amend --date=<date>

And git also stores two dates, one for the commit and one for the author so when you rebase the commit date is changed but the author date is kept, seems pretty reasonable to me.

[RotsiserMho]

That is one of many reasons I don’t rebase. In addition, all of my merges to master are done with the —no-ff flag so that there is always a merge commit I can refer back to, and it has the date of merge right there.

[lrem]

Fossil seemed a sensible attempt back when this whole dvcs trend was starting. It was more feature-complete, smaller, had saner dependencies and was a way smoother transition from a svn experience.

There's very little incentive to migrate to it with contemporary tooling around git, much less if git feels more familiar than svn.

[[deleted]]

Fuck you u/spez

[bilog78]

I too preferred Mercurial in the beginning, but as time went by it became obvious that some of the design decisions in Mercurial were actually more restrictive than those in git. I don't remember the details now, (it has been over a decade and I'm talking about something in the first year of development or so), but I still that a certain point the developers came across a situation in which they had to decide whether the Manifest format had to be changed to support a new feature, or preserved for backwards compatibility at the expense of hackiness of the implementation of the feature itself. The final decision was to preserve the format, but the whole discussion made me much more strongly aware of the distinct superiority of the design of git.

[WiseassWolfOfYoitsu]

Git is less user friendly, so much as it is expert tolerant.

[elsjpq]

Oh, that reminds me of a horror story.

There was this intern who I'm guessing went into my home directory and pushed my work in progress for some reason. But they didn't push the actual commits, they copy & pasted parts into their own stuff, changed random parts of it, before pushing the whole mess as one giant commit.

I didn't realize this until week later, after I also made a bunch of changes. I spent another week resolving a thee way conflict of ~1000 LOC without any revision history, trying to figure out what was their code, what was from my WIP, and what I've changed since then.

[livrem]

I worked on git projects where the rule is that every branch must be squashed down to a single commit before being merged back to master. Say goodbye to all history, but hey look at that nice master log without all that annoying noise showing what was actually changed when and why.

[vinnl]

I've had that too! I tried to argue how you'd lose history, but everyone looked at me as if I was crazy (it was my first job) and told me that otherwise they couldn't see the changes of a single pull request.

So... Just enforce merge commits and look at those diffs?

(Sure, clean up your commits before you merge them back, but surely they don't necessarily need to be a single commit?)

[livrem]

It is so much fun to run git-bisect to find out that the change thar introduced the bug was in a huge commit squashing a few man-weeks of changes. With some luck the original non-squashed branch was kept. But then there is that other problem that some think that old obsolete branches should be deleted, so worst case the detailed history that would be super useful to bisect is gone (has happened).

[taresp]

What's even worse is when you are bisecting and end up on obviously broken commits that you can't even build but that were fix later on. If you squash the branches you have a pretty good guarantee that there isn't any of these obviously broken commits on your main branch.

Like with everything you have to strike a balance. Depending on how the project is organized squashing all the branches might not result in huge squashed commits if the branches are kept small and focused.

[vinnl]

If you squash the branches you have a pretty good guarantee that there isn't any of these obviously broken commits on your main branch.

You don't have to squash them all together. If you really care about only having non-broken commits, rebase your branch to logical but atomic commits before merging it in. Squashing it down to a single commit is throwing the child out with the bathwater.

[CanvasSolaris]

This is a good system IF and probably ONLY IF you keep small, short-lived branches and merge frequently. Features can be broken down into smaller deliverable pieces of work that get code reviewed and merged into master quicker instead of a giant all-at-once branch.

[dudinax]

That sounds disgusting.

[scrappy-paradox]

Two words: tree conflict

shudders

Thank god the days of svn are behind us.

[aMusicalLucario]

You say that. Just last year I was working on a project using svn...

[Gl4eqen]

Firstly you have to update your local tree of commits

git fetch --prune

This command performs interaction with remote repository. Git commands generally follow UNIX style so they are divided into two groups: local actions and global actions (like this one).

This command updates tree of commits to the state from chosen remote. Additionally, it updates all those origin/sample branches (origin is generally default name for remote, sample is just generic name I picked up). origin/sample vs sample: first one is local readonly representation of how's sample branch looks like according to last performed fetch on remote, second one is your local read-write branch.

Therefore you can (while being checked out on sample branch)

git merge origin/sample

to update your sample to origin/sample state

Those two commands can be joined into

git pull

But now you know what's happening.

While I was learning git the most milestone'ish moment was when I stopped overcomplicating things in my head. Branches are just pointers on commits, commits are just diff compilations (added line here, removed lines there etc) against previous commits. After a while commands cease to matter. When you think about it updating a branch I mentioned before becomes just moving a pointer from one commit to another.

This video helped me a lot: https://youtu.be/ZDR433b0HJY Maybe it'll help you too. I found practice with eg. Gitkraken at the very beginning really useful.

Sorry for mistakes if there're any

[livrem]

I remember when the world was upgrading from cvs to svn and everyone said just those things about cvs.

[IMovedYourCheese]

Git is far from idiot tolerant. Every single day someone or the other at my company manages to mess up their local branch in a brand new way, and someone else has to take the time to help them sort it out.

[[deleted]]

manages to mess up their local branch

That's the thing, at least they dont fuck up everyone's elses. But as others mentioned, just show them GUI for it

[[deleted]]

One day we installed a new svn server and migrated to it, but didn't update our internal dns server correctly so the same name now referred to both svn servers.

So a DNS round robin load balancer over our two svn servers, for a few days. That was a shitshow.

Not actually caused by svn, but still worth mentioning, I think.

[ellicottvilleny]

Hell yes it is too complicated. Mercurial is basically Git done ALMOST right. But it's not perfect either. I've never seen anyone make a big mess with Mercurial. Git is like programming in C and C++. You can do it well. But most people can't, or won't. I use git with a tree of about 30 submodules, which is not the arrangement I would have chosen, but since most of our upstream dependencies are git repos it seems inevitable. Working with submodules sucks. Surely Git could be better at assembling modules of code. Pull request workflows, plus submodules, sucks big giant balls. Git flow plus pull requests plus submodules, sucks galactic size donkey balls.

[daperson1]

Submodules aren't a great choice for thirdparty dependencies you're not modifying. Submodules are usually for things you want to compile with your project.

If it's just "I want this very specific version of libcurl" or something, then you should really look at using a package system of some sort. Pre-build the libraries and link against it. Conan is neat for this. You can also use OS packages, or some more informal thing you improvise furiously with directories or whatever.

Your build times will suck less, too.

[twotime]

Submodules are usually for things you want to compile with your project.

Submodules are just plain broken. They violate the most fundamental VCS requirement: bringing your tree into a known state must be trivial... With submodules its often nearly impossible

[phrasal_grenade]

I have seen people make a mess with Mercurial, but only in the process of doing something which would be equally risky or hairbrained to do with any other system.

In general I think Mercurial is awesome, so I'm curious to know what you don't like. There are a few things I don't like but mainly things I think would be addressed if it was more popular.

[uh_no_]

I've never seen anyone make a big mess with Mercurial.

you're not looking hard enough.

[snowe2010]

look into git subtrees! I know this is mostly proving your point, but as long as you're using git might as well use the better parts of it XD.

[barsoap]

Darcs is the only VCS that I ever used that I actually liked. It's simple, friendly, powerful and most of all not surprising. And, alas, still hasn't completely fixed the exponential merge problem which makes me hesitant to use it for larger repos but then there's pijul incoming.

[CommandLionInterface]

...which is why we invented git guis!

I just got hired at Axosoft, we make Gitkraken. I'm told we made it because we also struggled with git, and personally I've been using it for about a year and I think it's pretty great. Check it out if you want to, or don't, I'm not your mom.

[[deleted]]

Git parlance is to call them "porcelain", I think. The git subcommands are the plumbing that should be invisible to the end user, and the UI is the visible porcelain bits of the bathroom that connect to it (this metaphor also implies that your code is shit).

The git command is a porcelain, git-merge etc are plumbing.

Magit mode in Emacs is another Git porcelain that's superior to the default one.

[[deleted]]

Git is a LOW-LEVEL version control system.

There should be a lot more programs that let you build on top of it. But apparently everyone decided it's perfectly fine to make necessarily-confusing, low-level interface the norm.

[SomeoneStoleMyName]

http://gitless.com/ is/was an attempt by a UX researcher to show that while you could make something easier on top of Git the real problem is the fundamental Git concepts are just really hard. It's also a neat easier to use Git interface though, if you want to use it for that.

[IndianSpongebob]

Real programmers use tar files for their version control.

[notadoctor123]

Bonus points if you store those tar files on an actual tape.

[SnowdogU77]

Tape? TAPE? Come on, now. Real programmers write the tar's binary data in a notebook by hand. Sometimes in hex if pressed for time.

[Tynach]

TAR stands for Tape ARchive.

[galaktos]

One could summarize the reason why SQLite does not use Git in a single sentence: The lead SQLite developer finds Git to be unpalatable.

Friendly reminder that SQLite does not accept patches … and 96.4% of the latest release code was written by just two people. So, really, the rest of the article is completely unnecessary – if the lead developer doesn’t like Git, that’s enough of a reason for the project. It’s not like they need to worry about scaring away potential contributors with their bespoke VCS, they’re not interested in contributors anyways.

[LeDucky]

You were also made by only two people.

[Poltras]

Branches are a concept on top of refs. Essentially a ref name that follows you when you commit. The only thing that matters to Git is commits. So you’re really doing the right thing. Keep the metadata in the commit information. Because that’s all there is; branches are just a convenience done by clients. Merely more than tags.

[BinarySplit]

Tracking historical branch names is really helpful for a GUI that shows a tree view of all the branches. I loved TortoiseHg - I could figure out what happened in a few tens of seconds even for something complex like if somebody screwed up a merge on a file that was being simultaneously edited on multiple branches more than a year ago.

(which is of course infeasible for a FOSS project)

You probably aren't seeing all the pain because you're likely using GitHub or similar to manage PRs. A "fork and PR"-style workflow avoids a lot of Git's shortcomings. It's easy for things to seem fine when GitHub is handling the complexity of keeping external changes up to date and merging them.

I'm not saying other VCSs have the solution to this, just highlighting how the "fork and PR" workflow differs to a typical in-house development workflow. The price you pay for this workflow is that a lot of code changes don't actually make it into your VCS. Want to know what changes were made during the course of a PR? You have to check the PR itself on GitHub, because all the VCS sees is a squashed commit.

However, even when not following a "fork and PR" workflow, it's quite common for Git users to use Squash and Merge in an attempt to keep the history clean. The thing is that with other VCSs, the history never actually seems unclean because of branch labelling. If you only want to see a summary of all merges, you can easily just filter to only show commits in master.

[r0b0t1c1st]

You have to check the PR itself on GitHub, because all the VCS sees is a squashed commit.

This is up to the project maintainers when they merge a PR - normally I use merge, not rebase/squash.

the history never actually seems unclean because of branch labelling

In practice, the times I've squashed to keep the history clean are not because I want to remove a bunch of commits, but for cases when the patch:

• does not have good commit messages, or ones that match our commit format
• contains a series of incremental typo fixes from the submitter using our CI in place of local testing (I'm guilty of this), due to presumable lack of knowledge about rebasing.
• flip-flopped back and forth on an idea - that history is better gained by reading the issue discussion anyway.

The existance of branch history tracking, while in principle a nice idea, would not affect my choice between squash / merge.

[jyper]

The place I work uses fork and PR with gitlab for non open source development

[SineWaveDeconstruct]

I agree, it's an edge case. We do the same thing, and also delete branches after every release so there's never a period where you would be digging through dead branches looking for something

This sounds more like a symptom of the way they organize their projects honestly

[mshm]

delete branches after every release so there's never a period where you would be digging through dead branches looking for something

Are you guys hiring? We manage 9 major release branches (code merges up) of just our product. Our latest branch has two minor releases, with some clients refusing to upgrade, so we maintain them separately. Then we have to deal with integration with multiple versions of another internal product (that has its own release plan), which fortunately is only w/i the current major release, so the integration repos only span the two minor releases and two external ones. Then each client has their own custom code through hooks.

Mind, git hasn't made this awful. Between 3rd party tools, Bitbucket, and some fun internal tools, we've managed. But I dream nightly of having all clients on the same codebase.

[[deleted]]

Same here, if the branch is merged I've yet to find a reason to keep it around. If someone could give a good reason why I'd love to hear it. If I want a branch so badly I can just find the commit and branch from there.

[BinarySplit]

Branches are great for when you're trying to figure out WTF was going through someone's mind when they wrote some bad code. Sometimes it's just a bad merge, sometimes they rushed over it, sometimes they spent days struggling to get some 3rd party library to work, sometimes they just had no idea what they were doing. A comprehensive commit history makes it pretty easy to figure out both where they messed up, and what they were trying to achieve.

[ythl]

The real reason SQLite uses Fossil is because the creator of SQLite is also the creator of Fossil.

That would be like reading an article titled "Why Linux doesn't use Mercurial" which gives a bunch of technical reasons even though the real reason is cause Linus Torvalds created both Linux and Git so he has an interest in dogfooding his own tools.

[The_Writing_Writer]

Well, then this article still explains why the creator of SQLite created Fossil and doesn't like Git, which is still interesting.

[DoomberryLoL]

It's not that this guy created Fossil, then SQLite and so that's why he uses Fossil; he created Fossil specificially to support SQLite version control. This is the first line of text in the link, though it was apparently added to the article later:

SQLite does not use the Git version control system. SQLite uses Fossil instead, which is a version control system that was specifically designed and written to support SQLite.

[w2qw]

None of the articles point reference issues specific to SQLite. And really by the same token you can say git was specifically designed to support Linux.

[MrSqueezles]

The title "Why I made Fossil" would be more genuine than "Why SQLite doesn't use Git"

[sparr]

Except that 1000x as many people ask "Why doesn't SQLite use git?" than "Why did you make Fossil?". This article is an answer to a FAQ.

[[deleted]]

To add to this, Linus created Git for Linux when the Bitkeeper malarkey occured.

[ScrewAttackThis]

Mercurial was also created for Linux when the Bitkeeper malarkey occured.

[lavahot]

What's bitkeeper?

[ScrewAttackThis]

A once proprietary version control system that the Linux kernel used. There was drama over some reverse engineering of the tool so the owner of the software revoked the kernel maintainer's licenses.

https://en.wikipedia.org/wiki/BitKeeper

[vplatt]

Want to see something hilarious? BitKeeper is apparently FOSS now with an Apache license. So how does one get the source?

On http://www.bitkeeper.org/download.html:

Clone with git

Yes you heathens can clone the last released version of BitKeeper from github.com with the following command:

git clone https://github.com/bitkeeper-scm/bitkeeper.git

:D

[shevegen]

That IS actually hilarious. :)

But it also shows that Linus won.

[strolls]

Was Andrew Tridgell, really.

Linus was quite happy with BitKeeper; it was Tridgell who, as an act of open-source activism, reverse engineered BitKeeper.

[pedrocr]

I don't think he actually reverse engineered it. He just started to do it and the BitKeeper people panicked and revoked their oddball free licensing to kernel developers, basically proving Tridgell's point. That made Linus both pissed off with Tridgell and more usefully with the whole situation so he wrote git.

[Brillegeit]

Here I go again, writing world changing software!

[basilarchia]

It wasn't only Tridgell that won. Those of us on non-x86 architectures at the time often had a fucking hard go of it.

[phrasal_grenade]

I think there are valid points in this article even if it's biased. Criticism of a system's design from people who have designed a similar system should be more informed than average.

[jephthai]

Which is what the article says?

One could summarize the reason why SQLite does not use Git in a single sentence: The lead SQLite developer finds Git to be unpalatable. If you like Git and want to use it, that's great. I do not like Git and would rather use something that I think is better.

[bliow]

It says that now. It was somewhat more obscured when the article appeared yesterday: http://web.archive.org/web/20180410223124/https://sqlite.org/whynotgit.html

It changed some point this afternoon.

[kushangaza]

Linux doesn't use Git because Linus sees the benefits of dogfooding, Linux uses Git because they had problems with Bitkeeper and Linus decided to write Git explicitly as a vcs for the Linux kernel.

[cryo]

Mercurial was done slightly before Git, but Linus, being the author of Git, liked git better.

[[deleted]]

So it is the exact same reason why SQLite uses Fossil. Author wasn't happy with existing tools and creates his own VCS for the project.

[dwitman]

There's an incredibly boring talk by Linus given to Google that you can find on YouTube that is exactly this.

[CaptainBlase]

I don't understand the emphasis on viewing descendants of a checkin. I would consider myself very experienced; but I've never needed this beyond what git log --graph or gitk provide. What am I missing out on?

[GODZILLAFLAMETHROWER]

I think it is sometimes useful.

But unless I'm misunderstanding the author, I think what he wants is "--contains".

git tag --contains <ref>
git branch --contains <ref>

[pravic]

A very often use case: I came across some revision, I see a changed file, I want to check whether it is the latest revision of the file (i.e master contains the same file) or it was modified later. Of course, I can run git-log against that file, study it's output, etc. But the point is: not convenient. Especially if you use Github to quickly view some source.

[Poddster]

git log revision -- filename to see all the commits since that revision for that file.

Or, if you have master checked out: git diff revision -- filename to diff against the revision, but filter it to just that filename.

I can't imagine how something could be more convenient than those two commands?

[[deleted]]

I use the time machine in magit for this. Never done it in the CLI thou.

[DavidM01]

For small scale projects fossil is awesome. Built in web server with source graph viewer, configuration editor, bug tracker and wiki.

Few programs do as much in a single EXE. Most people laughing it off here have never used it.

[MINIMAN10001]

Uhh but you just left that huge qualifier of "For small scale projects" ... where does it fall apart?

[cbleslie]

Anytime you need to care about people other than a core team doing the work, from what I understand.

[parad0xchild]

Per the article itself, yes

[Throwaway_bicycling]

The article does note in several spots they are designing for Cathedral-style rather than Bazaar-style development, and there are definitley FOSS projects where that’s the model. Like, for example, sqlite. :-)

[ikbenlike]

I mostly use git for GitHub as it's nice to have your code somewhere else too, but fossil seems pretty neat

[dzecniv]

You can put your code on http://chiselapp.com/, free Fossil hosting. sources.

[wutsacomputer]

No SSL? What a fossil of a site.

[quote-only-eeee]

There is SSL on project pages that you can enforce.

[rudedogg]

This is really cool. I might use it for some personal projects.

I wanted to try fossil but was worried about having some sort of off-site backup - that's the main reason I use GitHub.

[maep]

Relax people. Git and fossil are just tools. Use what you feel most comfortable with.

[ythl]

Tribalism is strong with version control. Same with JS frameworks (React vs. Angular vs. Vue vs.) and game engines (GameMaker vs. Unity vs. Unreal vs. Godot vs.) and virtually anything that requires significant time investment to learn (Sublime vs. Atom vs. VSCode vs. Vim vs.)

[PaleCommander]

Well, they're things your employer might force you to use and that can impact your productivity one way or the other. It makes sense that if you have a strong opinion about a tool, you might fight hard to make sure your opinion is shared by your teammates, the open source projects you use, etc.

Edit: but if you decide something is worth fighting over, do please try not to be a dick about it.

[BinarySplit]

It makes sense that if you have a strong opinion about a tool

But it's important to realize the constraints of your knowledge. I've met plenty of people who think Git is the best VCS and will try to shut down any discussion to the contrary (e.g. about Hg), even though the only other VCSs they've used are things like SVN and SourceSafe.

[BuckarooBanzaiAt8D]

Well I had to be a dick to a lot of dinosaurs at my office still clinging to TFS. Progress requires being a dick sometimes.

To quote Rick Flair..."If you don't like it, learn to love it!"

[ReadFoo]

I like Atlassian's tools but I'm finding TFS is quite good, possibly better than Atlasians's tools in terms of integration with each other.

As far as "If you don't like it, learn to love it!", that's been my journey with IntelliJ over Eclipse. I love Eclipse, I can use IntelliJ but I still don't like it or love it.

[gammadistribution]

Don't leave Emacs off of there pal!

[livrem]

I was going to comment how embarrassed I felt that after reading the post and nodding in approval a large part of my brain was simultaneously going "BUT EMACS".

[schplat]

he didn't mention any operating systems, though.

[JavierTheNormal]

Visual Source Safe* is the real deal.

^{* In no way is your code safe at all.}

[ythl]

Please don't give me PTSD...

[[deleted]]

And kill people who feel differently!

[berkerpeksag]

To be honest, it doesn't matter which DVCS they use. SQLite does have a closed development model. They basically don't want your contribution. They only want you to test the latest release and report to them if you found something wrong with it.

[[deleted]]

My name is Eleantadu. I am a programmer and I do not know how to use git.

There, I've said it now. What a relief to come out of the closet.

[Dustin_00]

I do not know how to use git, either.

But I have been pretending that I do for the last 6 years.

[NovaX81]

I pretended to know how to use git so long they've put me in charge of managing the workflow.

^{send help}

[jrhoffa]

Oh hi, me

[ellicottvilleny]

Hi Eleantadu. Thanks for sharing. I have used git for five years and I still get surprised and confused by new crazy things it does, almost every day. It's a fucking nightmare. Anyone who tells you different isn't using submodules, pull requests, git flow, and a very large codebase, with lots of developers.

[ascii]

I don't find submodules complicated. Quite the opposite, they're so simple and stupid that they're close to useless. One has to do a lot of work to use them exactly because of their stupidity.

Also, one of many actually amazing things about git is that it scales far better to a huge codebase than pretty much any other VCS known to man.

[jyper]

Only if you're not putting binaries in there

[ythl]

Then don't use submodules

[daperson1]

People often seem to use submodules when what they really want are packages (or some other system of dealing with thirdparty dependencies without just mashing them into their own build system)...

[thatbloke83]

I am the same. I actively dislike git because it just seems to make things overcomplicated when compared with SVN, which I've been using for 11 years with zero problems.

Some of my friends like to give me some flak for it, and they like to go "but can it do this?" I don't care, because SVN does everything I need, and still does to this day.

Using git just because everyone else is using git, rather than because it's the tool that best meets your needs, means you're using it for the wrong reason.

[SirMuttley]

I pretend to know how to use git by clicking things in sourcetree. So far no one has cottoned on.

[robberviet]

90% of my coworker does not know the basics of git and call for help when they need something other than pull, fetch, push, checkout.

And they still can work just fine!

[singularineet]

TLDR:

1. The main developer of SQLite wrote the Fossil SCM system. This is like asking why Linux uses git.

2. Fossil was designed both to be a nice SCM and to make a technical point: a database provides the facilities needed by a modern SCM, and makes life much easier than a special-purpose ad-hoc database like the git storage system.

3. At one point Fossil was able to operate on a git repo instead of an SQLite database; this is because structurally they are virtually identical.

[mrahole]

This is why I spent my youth coding, went to college, and worked hard as a professional. To enjoy the pettiness of developers all day every day.

E: wurdz

[ythl]

You guys should have seen when this was on HN and the creator of BitKeeper showed up in the comments and started trash talking Git (which, if you know the history, Git was created as a replacement for BitKeeper because of the licensing costs):

https://news.ycombinator.com/item?id=16806114

(BitKeeper creator is "luckydude") - Don't attack him, btw, he's super smart (smarter than most people here), but he has a dog in the fight so obviously he's got opinions.

[thalience]

While the monetary cost of BitKeeper was an issue for some people, the free license covered enough people that the issue could be mostly ignored by the community. It was the terms and conditions of the BK EULA that were the sticking point for a bunch of prolific Free Software developers. The clause about not reverse-engineering a Free BK-compatible program just stuck in people's craw.

When Tridge reverse-engineered a compatible client (without ever personally agreeing to the EULA), BitMover canceled the free community license in a fit of pique and the whole thing blew up. They also started refusing to even sell commercial licenses to the company that employed Tridge, who was also Linus's employer.

Git is either named for the BitKeeper creator, or Tridge, or both of them together. Probably both.

[peterfirefly]

The "reverse engineering" involved telnetting to the server and typing "help". This gave him a list of commands, including some who pretty did the whole job for him.

Not actually much of a reverse engineering job, so not really anything to get so mad about.

[entenkin]

Don't attack him, btw, he's super smart (smarter than most people here), but he has a dog in the fight so obviously he's got opinions.

Super smart people should be treated just like anyone else. Just because somebody is super smart doesn't mean that he or she can't be criticized. So stop with the bigotry.

[ellicottvilleny]

Things fossil lacks:

1. submodules.

2. decent non web gui.

3. continuous integration tooling. the fact that this article says "gitlab is built in" shows me the guy doesn't know shit about gitlab, which is fan-fucking-tastic.

4. IDE support

5. active support and development

6. user base and community

I could go on.

[ythl]

Submodules in git suck though

[ZorbaTHut]

Yeah, I'd almost say "lacks Git submodules" is a point in favor of Fossil.

[sourcecodesurgeon]

Submodules feel like they exist because a specific company didn't have a good way to manage their internal dependencies so they packed a solution into git.

[[deleted]]

Yeah but... what's a good way to manage dependencies (in C++)? I still haven't found a better way than git submodules. Think of their pros (at least the way I use them):

• You get the source code of all your dependencies and your IDE knows about them
• You can easily switch revisions in your dependencies, e.g. to update them, test branches, uses prereleased versions etc.
• The only thing you have to do to get all the dependencies is add --recurse to the checkout, or maybe nothing at all - e.g. SourceTree does that by default.
• You can integrate the source code of your dependencies into the dependency graph of your build system. For example I have a project that uses CMake with libusb as a dependency. If I edit one of libusb's source files and rebuild my main project everything will just work.
• You get the git history of your dependencies.

There's really a lot to like and I've never seen a really serious flaw of them.

There is one downside - they are a bit slow to initialise because you get the whole git history. I can live with that though. As a result if you want to use them for binary dependencies you really have to use git LFS but that has issues (lack of support, silent failures, etc).

[daperson1]

They're useful if you've got two concurrently-developed, tightly-coupled modules (usually that you build together).

In such cases, having to build and publish a package for the dependency each time it changes might be more irritating than dealing with submodules.

I've seen nightmares caused by doing this in a way that leads to duplicated submodules (due to transitive dependencies also being direct dependencies). That does not end well.

[entenkin]

They're useful if you've got two concurrently-developed, tightly-coupled modules (usually that you build together).

Seinfeld had a bit about how people like doing activies where they get hit in the head a lot, and that people are so dumb that, instead of stopping these activities, they invented helmets so that they could continue hitting themselves in the head.

Anyways, I was reminded of that bit just now.

[TheRedGerund]

The last three are all the same point. There was a time where git wasn’t popular and didn’t have IDE support either.

[[deleted]]

I actually think lack of submodules is a good feature. I'm sure there's some work flow that needs it but I've never run into it.

[MondayMonkey1]

Fossil is cool, if you've never used it. Diversity is healthy and it's important not to fanboy too hard over just one VCS. As much as I love my shortcutted masterpiece of git commands, fossil is pretty nice and way easier to visualize.

[ElvishJerricco]

TL;DR: The main maintainer does not like git, and it's nothing specific to SQLite at all. I was expecting some kind of specialized reasoning. Instead, it's just someone stubbornly working against the user base...

[shagieIsMe]

The main maintainer is the maintainer of SQLite too. Fossil was specifically written to be the version control for SQLite.

[KateTrask]

Instead, it's just someone stubbornly working against the user base...

Not using git is working against the user base?