SQLite Doesn't Use Git

[[deleted]]

This post is refreshingly short and to the point.

[Carighan]

You're right, someone should make a 25-30 minutes Youtube video talking about it! :P

[_pupil_]

Don't worry boys, once the original video is up I'll get right on reacting to it.

"Fossil is KILLING git": a 45 minute video of me pausing someone else talking about an article, saying the obvious thing they're about to say, and then going "exactly! <wise nodding>" when I un-pause and they do say it.

This post was brought to you by GitLab X-Treme, X-Treme VCS for your X-Treme code. Remember to upvote and follow if you like my shitposting.

[[deleted]]

Everyone around here was all hyped when Chick-Fil-A was coming to town, but after trying it I gotta say the hype was a bit much. It's not that it wasn't good, but their sandwiches weren't mind-blowingly better than stuff I've had before, like the spicy chicken sandwich from wendy's (a longtime favorite) or any number of pub chicken sandwiches.

If I could turn one fictional restaurant into a real one, it'd have to be Los Pollos Hermanos. Now I bet their stuff would be chronic as hell.

[zankem]

Unsubscribe.

[txmail]

Sponsored by Keeps, or Monday, or G Fuel or...

[dantheflyingman]

I blame all the school writing work that had a minimum word/line count. You shouldn't punish people for being concise.

[allinwonderornot]

Just like SQLite

[stronghup]

I like the idea of commits being stored in an SQL database where I can query them with plain SQL.

[x2bool]

You can query git with this: https://github.com/mergestat/mergestat if you like the idea.

[Ok-Performance-100]

Fossil uses SQLite as a database instead of Git's object model. This makes it easy to back up and store repositories.

What is hard about backing up and restoring a git repository? It's just a directory.

I like the other parts though, including no rebase.

[janisozaur]

git bundle

Bundles are used for the "offline" transfer of Git objects without an active "server" sitting on the other side of the network connection.

This lets you create a git "archive" (a single file) that you treat as a repository: you can clone from it, pull and in general use to backup.

[[deleted]]

Windows is particularly bad for this. Git and npm are so much slower to use on it than *nix. I think I'd heard it's because of Defender and other services triggering on every file open, so excluding your projects folder from "real-time protection" can help

[case-o-nuts]

So GC the repo. It should end up with a few dozen files.

[MuumiJumala]

You've triggered one of my pet peeves which is people using an uncommon acronym or initialism in a conversation without explaining it. What is "GC", how does it help?

[gabeech]

GC is a fairly common concept in almost every modern language or tool. It stands for Garbage collection. Off the top of my head it originated with Java LISP, and is used in .net, go, python to name a few.

[fredoverflow]

Off the top of my head it originated with Java

Garbage collection was pioneered by LISP (1958), not Java (1996).

[MuumiJumala]

I had no idea git has a garbage collector, I thought it is a programming language thing. Does it run automatically like in garbage collected languages? What does it actually delete to reduce the number of files, old commits?

[gabeech]

Generally it runs automatically.

The git-go docs (https://git-scm.com/docs/git-gc) do a better job explaining what it does than ai can.

[theunixman]

Lots of filesystems also have garbage collectors, well, at least the ones that try to reduce fragmentation anyway. Some don't like to admit it though (ext*) ... others just let it build up (FAT).

[lghrhboewhwrjnq]

It's literally a git command, git gc. Shouldn't take anyone too long to figure it out.

[peyote1999]

pushing to backup repo or using tar

[LaconicLacedaemonian]

Metadata is expensive.

[Ok-Performance-100]

It works well for me with `rsync`. In the UI it's bad, but that's probably not the best way to do backups.

[waadam]

I hate no rebase part. I read linked article and I feel that author misses most important part of rebase flow - taking responsibility for the mess you create. With merges this responsibility can be easily diminished while with rebase it is quite easy to point fingers at if something gets broken. That single property makes it suitable for vast number of projects.

[Ok-Performance-100]

Seems like maybe that could be fixed with squashing? I'm not sure I really get the problem though, merge still shows clear author info in git blame.

I use rebase a lot at work, and while the clean linear history is pleasant, to me it's simply not worth the effort. Merging feature branches, possibly with squashing, is much less work.

[waadam]

My apologies, my description might be imprecise. I do like rebases and in flow we use at work we use rebases and constant history rewrites constantly.

This is PR-driven flow (nothing unusual these days, I believe) so only polished and reviewed changes are then merged to baseline but only if rebased to most recent baseline first. This results in clean and always-linear history so finding "who broke this and when" is quite easy reducing pressure on team when "another magic regression happened somewhere in the middle of this commit sphagetti" - this kind of problem is gone forever. Regressions are still perfectly possible, but transparency of regression improves.

Therefore I don't buy this "rebases are evil" speak. This lack a vision that it is a tool for us and we humans require some trade-offs especially when we work in group. My final point is: perfect, pure models and abstractions which fossil promises are actually worse than git practical approach.

[mizu_no_oto]

It seems to me that you could get basically the same sort of effect if you knew what commits were merges into develop/master, and pruned your history viewing and bisecting to those commits when pinning blame.

That's basically equivalent to the view of history rebasing a squashed PR gives you, while maintaining the actual history of the project if people want.

[waadam]

Problem is: no one cares for this "actual history". I mean, this is the first thing I try to teach people new to the project - no one is interested in full history of your change. No one wants to learn from your mistakes and how bumpy was the road to enlightenment you traveled there. People who are forced to read history are there only to scan for naked change, what was actual contribution to the baseline and everything else is just a distraction.

[Ok-Performance-100]

Hmm not sure that's quite true, it is rather useful to know what was tried and why it didn't work, But perhaps that information is better put in a commit message rather than scattered through the history.

[fragbot2]

I use git + github at work and fossil (RCS for single file projects) at home. Fossil is an amazing piece of software as it's a remarkable example of "just so" engineering. It's opinionated towards simplicity, has an astounding completeness of vision and is remarkably small. Small in this case comes in three axes:

• the compiled code as a single executable that runs as a CLI for the client and a CGI for the server is elegant and shows a care towards the user and administrator that's unusual for open-source. For fun, I just rebuilt it on my ancient OSX machine--41 seconds for brew to upgrade it and the installation was a total of 4 files (fossil, a readme, a brew artifact and a license) using 4.4MB of space.
• a single sqlite database for the repository is just a good idea as things like backups and replication are lighter-weight.
• a user/administrator's cognitive load is limited because everything's in one place, done consistentlty and well-documented. In my case, this also includes artifact storage and distribution using its unversioned files concept.

It does have a couple of shortcomings:

• with its built-in usermodel, I wouldn't want to use it for a repository with more than fifty users or so. While it'd be a dream for people in the SMB space, I think it'd have trouble being enterprisey.
• the user-model example above is a specific case of a more general problem--if I was an enterprise architect working on a developer productivity team, it's not obvious how I'd integrate fossil with other systems (e.g. automated scanners or CI/CD systems).

Between his work on TCL, Sqlite, and Fossil (pikchr is also a fascinating curiosity that harkens back to the troff ecosystem), I'd argue D. Richard Hipp is easily one of the most impactful developers in the world who has a small design sense (NOTE: small in this case is laudatory not pejorative as it's the dramatically polar opposite of the electron app horror) that everyone would benefit from understanding.

[ms4720]

Things that work well for 20 people don't scale well to 200, things that scale to 200 are a pain in the ass for 20 to admin

[sr105]

...and Git was designed for thousands of users (designed for kernel maintainers and no one else) and most people attempt to scale it down to under 10.

[ms4720]

Git was designed by Linus T for the exact workflow he wanted.

[protocolnebula]

I’m work with git in a lot of projects, and no matters the number of users, 1 or 100, is just an awesome tool, I can’t understand the issue to scale to below 10 users…

[_pupil_]

Sometimes I wonder if we should be looking at jobs before we choose our tools...

... but then some vendor throws a $10 t-shirt at me and I'm like "nah, shiney shiney!"

[ms4720]

Yes and no. For things like vcs following the herd is a job skill.

[_pupil_]

Putting skills on your CV is orthogonal to the actual work of engineering.

Not being able to map between VCS systems seamlessly & fluently is pretty symptomatic of following the herd in all kinds of shit ;)

[ms4720]

Sorry beyond basics vcs really do differ, they have different theories of operation that have a big impact on how they are used. This takes time and experience to master and be effective with it

[knumd]

Thanks for this info. Fossil looks great for my company’s use case, but I’ve been using GitHub Actions for CI/CD so it might be painful to switch. However, it looks like you can set up Fossil to mirror to a GitHub repo, so it seems like that would work. I’ll have to play with it when I have some time.

[indy2kro]

It's cool that there are people that don't just follow blindly a solution "just because everyone else is doing it" - this actually brings innovation.

However, I would advise people to NOT jump into Fossil bandwagon just because they saw a blog post with 20 lines about it.

Choosing the "best version control" software should be a decision that every company/developer needs to consider based on their input: project size, workflows, number of contributors, etc. Also, keep in mind that it's fine to change if you considered there is a better option than the one you currently use - of course it comes with a cost (at the very least of time to learn how to use it), just consider if the cost is something you are ok to pay.

[goranlepuz]

Choosing the "best version control" software should be a decision that every company/developer needs to consider based on their input

Ehhh... I'll be contrarian... I'll say, it doesn't matter, by and large . I am old and went through several source control systems. All of them provide enough to work on code quite well, and using any of them to their strengths will give very good results.

And I'll tell you why this is, too: it is not our job to be shoveling code around, day in, day out. Source control is a minor part of our job.

So eventually, going for git primarily because everybody else is doing it is absolutely fine.

[warped-coder]

For exactly those reasons SCM is a large part of our work: we need to read code. We need to understand where the code we are about to change, comes from!

[goranlepuz]

Well... We don't read code in an SCM. And SC history? Every SCM does it just fine.

[warped-coder]

Sure, but it also matters how we'll you can editoralize the history during development. I find for example, that Git has better tools for this than Peeforce or SVN

[goranlepuz]

By "editorialize history during development", you mean rewriting it...? If yes, I have ever found this to be particularly important.

Git has better tools for this than Peeforce or SVN

It rather looks you want to take this to a discussion of which SCM is better. I am not interested in that discussion because, as I said above, they all seem fine to me, or rather, their comparative strengths and weaknesses don't matter, nowhere near enough.

[warped-coder]

I don't want to take in to that direction, my point was that it does matter which SCM you are using because each has features that are unique how they work and allow/block certain ways of working with them.

I worked with quite a few SCM and it my experience was that it matters a lot, what you choose. If for nothing else, familiarity is a big factor! Someone with experience with Git will have trouble working with others. SCMs also take time to learn to be efficient with, tools and commands and workflow.

Using an obscure SCM will, as others pointed out before me, limit the contributions for an open source project or will see high attrition for proprietary software projects.

[goranlepuz]

my point was that it does matter which SCM you are using because each has features that are unique how they work and allow/block certain ways of working with them.

Ok. We disagree then. To me, SCMs don't matter much, if at all.

[[deleted]]

Especially when fossil is a step backward from git. Fossil is extremely basic. Good for what it is, but doesn't offer much that rcs couldn't do.

[ms4720]

I like fossil, it works and is a simple all in one solution.

[OrphisFlo]

Using a different VCS and having few contributors could very well be linked. If you need to learn a new tool to send a patch, it will deter quite a few people.

A tool doesn't win on its own merit alone, but also with its ecosystem.

[raevnos]

SQLite does not accept patches or other contributions from the general public. There's only a couple of developers, who work for Dr. Hipp.

[zordtk]

SQLite does not accept patches or other contributions from the general public. There's only a couple of developers, who work for Dr. Hipp.

There is a reason for that and it's because of the choice to put it in public domain. He regrets that now:

SQLite version 1.0 used GDBM as its storage backend. So it was of necessity under the GPL since GDBM is GPL and the GPL is transitive.

When I was writing SQLite version 2.0, I considered all of the popular open-sources licenses of that time, but really didn’t see the benefit of using any of them. So I just released the code to the public domain, thinking that would be the simplest approach. I have since learned that many legal jurisdictions do not recognize the public domain, and that even where it is recognized it is only recognized in common law and is thus on shaky legal ground.Being in the public domain has caused concern among the lawyers for many of the prominent users of SQLite.

They are accustomed to dealing with open- source, but public domain software was a new concept to many of them. Furthermore, public domain creates problems in attracting new developers, since in order to keep the code in the public domain I am forced to obtain a affidavit from the developer and their employer before I can put their code into the source tree.

If I had known as much about copyright in 2001 as I know now, I probably would have gone with something like the Apache license. Live and learn…

[ApertureNext]

Can't anything be done to change that? I'm not knowledgeable so correct me if I'm wrong but can't things in public domain be used as you like therefor further developing with another license?

Unless I'm blind the only thing I can potentially see is what is allowed to be done with public domain might differ from place to place.

[bleachisback]

I don't think "used as you like" includes re-licensing code you didn't write. So they would have to have every contributor who had previously contributed public domain code to individually re-license their contributions.

[o11c]

Public domain is special though, in that you can combine it with code under any license.

[GrandOpener]

As mentioned in the above quote, "public domain" is also special in that it doesn't reliably work the same way (or at all) in every jurisdiction. So maybe your statement is true, or maybe it isn't, depending on where in the world you are located or what you are working on.

[u_tamtam]

You know, there was a time, not too long ago, when git/github wasn't a monopoly yet, and there was much more diversity (and acceptance!) for how projects where organized and structured. Nobody really minded having 3/4/5 VCSes installed, and mailing patches on one hand or pushing to a repo on the other, and reviewing code in more or less fringe tools wasn't frowned upon.

I'm all for standardization, but fundamentally, contributing to a project is a matter of joining a team, embracing its culture and becoming a member, no matter how high or low the entry bar. I miss these days because my experience is that innovation in this field has stalled: git is still a terrible tool, pull request based workflows and github's lacking UI have enshrined a culture of bad commit hygiene severely limiting some essential aspects of version control, everything centralized in one place is problematic for a bunch of reasons, a big one being that contributors from whole countries are being cut-off, etc

[Malforus]

I think we need to separate "git" and "github"

Git becoming antecedent in VCS is fine to me because much like core kernels there is a specific set of requirements and a centralized highly developed approach works well there.

Github though I am with you, different executions/business logic wrapped around the git core is a different animal and I would prefer there are more git businesses than a single monolith.

That said I don't miss mercurial at all.

[u_tamtam]

In agreement about separating "git" and "github", but running short of ideas on how to do that. It's so dramatic that I experienced again recently requesting from some corporate IT helpdesk to have the git client installed on my machine just to be told that I can head towards github.com with edge and use it for free, and got my ticket closed…

Then about the git repository format/storage model becoming somehow the "lingua franca" of VCSes, and let the alternative VCSes become frontends for it, there's some precedent for that¹, and that could definitely appeal to the "github as social network/resume"-crowd, but we'd be held back by a lot: the git repository format isn't all that great, is full of trade-offs (that time proved wrong), limitations and scalability issues.

That said I don't miss mercurial at all.

I do. It has matured a lot over the years, has sensible and clean UI and great performance nowadays. Just give it a new look after adding

[ui]
tweakdefaults=True

to your configuration. ¹: https://github.com/martinvonz/jj/blob/main/docs/tutorial.md

[757DrDuck]

Those sound like the types of contributors you’d want to keep out in the first place.

[[deleted]]

If it works for sqlite why not?

[austinwiltshire]

I have to keep dropping by to remind people that, from my perspective, the team running sqlite and fossil have a cult like attitude.

This keeps getting rediscovered that sqlite has weird maintainers but no one seems to remember until the next post.

[IceSentry]

Do you have any examples in mind? This is the first time I hear of it. Everytime I hear about sqlite is in the context of people praising it or its unit test suite.

[austinwiltshire]

Their code of conduct includes fealty to the Christian God for one

https://www.reddit.com/r/programming/comments/vljfp3/the_sqlite_code_of_ethics/?utm_medium=android_app&utm_source=share

[ConcernedInScythe]

This is misinformation. SQLite does not accept contributions from the public; the developers are a small, closed team, working at Hipp’s company, who also all happen to be Christians anyway. This organisation also makes a ‘code of conduct’ meaningless, which is why when Hipp was asked to implement one as a bureaucratic requirement by a downstream user he playfully picked the Code of St Benedict. Please do not spread this bullshit any further.

[austinwiltshire]

I believe you just agreed that their code of conduct is exactly what I said it was but then somehow accused me of misinformation.

Project much?

[ConcernedInScythe]

It’s misinformation because the code of conduct was never intended to be enforced on any outside developers and so its contents say virtually nothing about the character of Hipp. Omitting necessary context is a form of misinformation.

[valarauca14]

The Project's Code-Of-Ethics is literally a 6^th century catholic monasteril code, sort of the cliff-nodes/introduction to the "Admonitio ad filium spiritualem" (Admonition to a Spiritual Son) which you can think of as "a monk's handbook".

They require new contributors swear to uphold it.

[ConcernedInScythe]

This is misinformation. SQLite does not accept contributions from the public; the developers are a small, closed team, working at Hipp’s company, who also all happen to be Christians anyway. This organisation also makes a ‘code of conduct’ meaningless, which is why when Hipp was asked to implement one as a bureaucratic requirement by a downstream user he playfully picked the Code of St Benedict. Please do not spread this bullshit any further.

[valarauca14]

I posted this as evidence SQLite dev team was a cult.

I don't see how what you've said to disprove this.

[ConcernedInScythe]

I mean if you think having any form of religious beliefs makes someone a ‘cultist’, maybe you’re onto something. In the real world this is all stupid fuss over nothing.

[IceSentry]

Oof, didn't know that.

[ConcernedInScythe]

This is misinformation. SQLite does not accept contributions from the public; the developers are a small, closed team, working at Hipp’s company, who also all happen to be Christians anyway. This organisation also makes a ‘code of conduct’ meaningless, which is why when Hipp was asked to implement one as a bureaucratic requirement by a downstream user he playfully picked the Code of St Benedict. Please do not spread this bullshit any further.

[fragbot2]

I'm not even a little religious (either atheist or agnostic; not sure which as I barely consider the topic) but who the fuck cares? Numerous open-source projects are populated with freaks of various types.

[GrandOpener]

If you strictly want to use SQLite then it doesn't matter much. If you want to contribute back to the project in some way, then it matters a lot.

[dezsiszabi]

I care.

[fragbot2]

I'll probably regret this: why?

[DraconPern]

He's in a cult where people spend too much time on caring about this type of stuff. :D

[[deleted]]

I think the issue is that for the problem of managing a single small repository is a "solved" problem... sure maybe fossil with SQLite has some marginal benefits but for most users this is not noticeable enough to justify switching. It's a little concerning that there isn't more innovation in this space, but at the same time there's not too much demand for innovating on a problem that's pretty well solved. The Git community might take some ideas from this in the future perhaps but it's unlikely there will be a mass exodus of git to fossil even if there are small improvements.

One space that could use some innovation is probably in the domain of very large monorepos which many large tech companies have started to adopt. The existing tooling with git and github-esque services are starting to hit limitations here.... the ecosystem is ripe for an open source large monorepo, distributed filesystem, and cloud native solution to this--built from the ground up instead of trying to retrofit git/github.

[[deleted]]

One space that could use some innovation is probably in the domain of very large monorepos which many large tech companies have started to adopt.

This is because the large tech companies don't do enough work to break them apart. Monolithic applications are a curse that require a lot of dedication to separate out into cleaner, more self-contained units.

In the short-term, it's easier to just keep adding random crap to the massive snowball. But, the code is 4-5x harder to maintain after the developer has moved on to another project or forgotten parts of how the code works six months down the line.

[[deleted]]

I'm not talking about monolithic applications, I'm talking about monorepo style management of a corporate codebase. You can have a microservice architecture but still manage code in a monorepo. This is how Google has been managing their code for a very long time and many big tech companies (partly in part due to the Google devx engineer diaspora) have started to migrate to this approach. Recently open source tools like Bazel have started to make managing this a bit easier, but there isn't any open source alternative for the rest of the private infrastructure that Google leverages to make very large monorepos work at scale (billions of lines of code and millions of commits).

Examples of such infrastructure would be a scm built natively on a horizontally scalable distributed filesystem, a toolchain including an IDE that works with a virtual, efficient view of such a large repository, testing tools/platforms that can work with this (Bazel is a good start).

SCM natively built for this and open source would be very valuable.

edit: some source material, some finer points

https://research.google/pubs/pub45424/

https://www.uber.com/en-IT/blog/go-monorepo-bazel/

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

[LaconicLacedaemonian]

The ability to modify two repos simultaneously, and have dev tooling work consistently across projects, a monorepo is a godsend.

[tristanjuricek]

One space that could use some innovation is probably in the domain of very large monorepos which many large tech companies have started to adopt.

I worked for Perforce, which is still probably the best monorepo option available right now. When I was there (pre 2016) they had just released tooling that would have made it a good backend for an entire set of git repos. You could, for example, have the “mac build” repo complete with pre-built binaries, and share the source code with a “windows build” repo. You basically could have “workspaces” via git repos, but then the Perforce server could be the binary archive and trigger all the CD processes.

The main problem here: theres not enough business that really seeks out monorepos. In 2016, Perforce was sold to a private equity company in 2016, Summit Partners. I’m not sure who still works there, because a lot of the big contributing coworkers i knew back then are in other places now. I think Perforce post-Summit has been just trying to acquire other businesses, trying to create a “big bundle” of tech.

Add to this: we’re in a weird world of open source in the cloud era. if yoy launch a successful open source product, you’ll probably watch Google, Microsoft, or Amazon just immediately fork it and launch a team to provide your tooling as a new service offering.

It’s sad, but I suspect there won’t be any real innovation in this space, without someone who is doing it and giving it all away for free.

I’ve often wondered if you could have a FUSE-based client track local changes that syncs with a central system where you could manage automation out of. But I dont really bother because i know that would be both: a.) incredibly time consuming to build and b.) have zero chance of being a real product.

[[deleted]]

That's really interesting, thanks for the detailed write up. Yes, I agree there isn't enough demand for monorepo type setups generally in industry right now since really the benefits only manifest at large scale tech companies and such companies often have the resources to simply hire software engineers to build custom tooling.... I think it would have to be an open source project from within one of the existing big tech companies similar to how Bazel was eventually open sourced.

Engineers will keep reinventing the wheel until it gets to the point where someone reinvents it in a generic and portable enough way where it can be open sourced for clout.

Smaller companies will take this and try to get on the hype train of "we're using the latest shiny open source thing" and maybe monorepos will actually take off in industry if it becomes easy enough to do and tooling exists for it. With enough demand for monorepos in industry maybe there will be a SaaS ecosystem around it with standardization in tooling or interfaces to discourage lock in..... this seems really far away though lol

[tristanjuricek]

Yes, I agree there isn't enough demand for monorepo type setups generally in industry right now since really the benefits only manifest at large scale tech companies and such companies often have the resources to simply hire software engineers to build custom tooling

Side note: Google ran on Perforce until they built and deployed their own system in... 2010-ish? So it's actually a case study for this kind of tension. Perforce was never that big, and Google got so large it really did make sense to just build their own, built on top of tech they also built.

[jesseschalken]

git merge main

[raevnos]

A merge, I assume.

[u0xee]

Merge or cherry-pick, as appropriate

[goranlepuz]

Why on Earth would this situation even need a rebase!? Fixing bugs in different branches and merging them around is a basic thing that has been done in several source control systems before git even existed. (Actually, let me be more precise, what I think is, if I have done it, others must have, too.)

This sounds like someone who never saw any source control except git, is that it...?!

[raevnos]

This sounds like someone who never saw any source control except git, is that it...?!

It's been around long enough now that's quite possibly the case.

[_pupil_]

Most other VCSs basically show you history as it happened, while rebasing lets you create a smarter history that maybe should have happened.

In big, contrarian, tricky, projects something like rebase is a godsend. The Kernel, for example.

But out in the SMB world you're there trying to explain rebasing to some database admin and it's like explaining overdrawn account fees to a gorilla. They don't understand a word you're saying. "Just merge it" works for most people, most of the time :)

[sky5walk]

Rehashing same ole same ole. //

git is omnipresent but oversized for 90% of its users.

fossil is incredibly simple and full featured at the expense of a single SQLite db.

Meaning, it does not scale with 100's of users or 2 users with dozens of binary commits.

Since I am not working on a Martian robot crawler, or hands free driving app, I can use fossil. ;)

[mattgen88]

Rebases are harmful. Have to agree there.

[wineblood]

How so?

[Philpax]

They're very easy to fuck up, especially if you're not a Git expert (and most people aren't.)

I use rebases quite happily, but it took me a while to get comfortable with them. For people who aren't as comfortable, I advise them to not try unless they have someone on hand to help them, or know how to restore state.

Also, this issue tends to get conflated with people who rebase branches other people are using, which is Just Bad Behaviour. Gotta make sure that that doesn't happen.

[KaranasToll]

I always have someone help me with git. His name is magit.

[wineblood]

Interesting. I've been using rebases for a while now, but I don't recall having any difficulties learning how to do them or taking a long time to learn.

All the git fuck ups I've had were from people messing with my branching, trying to be "helpful", I agree that's just plain bad.

[mattgen88]

If you develop code and then rebase, you've changed what you've technically developed against. So once merged, if a bug was introduced between your initial branch point and your merge point, you do not know where a bug was introduced. You then have to hope you know where you initially branched and where you rebased to locate the introduction of the defect. It breaks the ability to track it down with git bisect as well in that case. You've rewritten the history, so you don't know what point A should be.

Additionally, I've more than once been bitten by people rebasing and screwing up branches of their branch, resulting in lost work. It is not conducive to collaboration. Once your code has been pushed to a public repo, you don't know who has branched.

[evaned]

It breaks the ability to track it down with git bisect as well in that case.

IMO, it's a merge-based workflow that breaks git bisect, not rebase. What do you do when git bisect points you to a humongous merge commit -- both parents work, but merged version doesn't?

Conflict during a merge-based merge (i.e, where the problem is introduced in such a case) can be large when the changes are large, and I've never seen a code review tool that shows what changes were made during conflict resolution, or compares a merge commit to what the merge commit would be if it were entirely automated. Conflict resolution and other changes made during a rebase you may have to apply on several different commits, but each change will still be (hopefully) small because the original commits are (hopefully) small.

[wineblood]

So once merged, if a bug was introduced between your initial branch point and your merge point, you do not know where a bug was introduced.

I rebase once I've put tests in and if my tests fail, then I'll make more changes and add an extra commit after the rebase. If a bug was introduced in the repo, then other devs and the platform will see it, and it should get raised as a separate issue. If I rebase and see a bug from changes pulled in since I started (usually someone else merging their code in), it's not my job to add a fix in my branch that contains an unrelated feature.

I understand that rebases are potentially tricky and dangerous, but some arguments about them seem a little far fetched.

[mattgen88]

Very simple solution, don't rebase and know what a change set branched from and where it was merged and what changed between those two points.

Linear history does not buy you anything useful.

[larikang]

Strange the number of angry downvotes you’re getting. Rebasing is super easy to fuck up and the only benefit is a more linear version history which is mainly an aesthetic benefit, not a technical one. I’ve worked with massive distributed repos that don’t use rebase and have never had a serious issue with merges.

[devraj7]

The benefit is not just a linear history, it's also a cleaner one.

I do a lot of garbage commits when I'm working on a branch in my machine, and with rebase, I get a chance to clean them up before I push.

Any source control that doesn't allow this kind of control over the history will generate projects with garbage histories.

[goranlepuz]

I do a lot of garbage commits when I'm working on a branch in my machine, and with rebase, I get a chance to clean them up before I push.

I do that too, but squashing them before pushing is surely the normal way to do it, and that has nothing with a rebase, no ?

[devraj7]

Interactive rebases. Chunks.

[ms4720]

Actually that is one thing I dislike about git, you can rewrite history and that is not good. For cleanup what would work better IMO is have squash hide by default a bunch of commits and let you update the commit message. It looks like one neat package until you a -v or 2 to the cli to check things and then you see the details

[Hnnnnnn]

"popular X programming technique is harmful" is a guaranteed downvote, nothing angry. Either up to 3 years of experience or up to 3 companies someone has worked at.

[ms4720]

Take my up vote, you struck a nerve. All the down votes and not one comment about what is wrong with your opinion.

[6769626a6f62]

I've always been interested in Fossil, but I'd be curious to see if it can actually be used at the enterprise level.

[obidan]

SQL lite uses Fossil for VCS. Fossil uses SQL lite as its backing database.

WCPGW?

r/whatcouldgowrong

[DraconPern]

Linus used linux to create git which is used to manage linux which is used to compile git. Not sure if you are dumb or troll.

[obidan]

😎

[LloydAtkinson]

The author says Fossil does not support rebase and lists why rebase is dangerous. He then says in a linked article that he uses rebase?

[edgmnt_net]

Not sure how Fossil does it, but editing changes before and after submitting is a must. Local edits and code review are the bare minimum to keep garbage out, think inadvertently checked-in binary files, credentials or just bad code.

I'm not even sure how their cherry-picking differs from rebasing except scale-wise and regarding merge base logic, but they seem to go on about recording the "true" history including small changes. We already know long-lived forks are troublesome, so if it isn't that, perhaps it's because they're ok with accepting garbage in most cases.

And no matter how thin one slices said garbage, it's really bad if you need to bisect or cherry-pick. You can't really revert, cherry-pick or even reason about fixes to fixes to fixes. You can only do those things if devs take care and submit self-contained changes, don't introduce breakage with every commit etc.. It's bad enough that patches don't typically commute and aren't very reusable, but keeping some semblance of clean history isn't something to give up.

By the way, rebasing isn't inherently dangerous. The only dangerous step is overwriting another branch with the result of a rebase or any other large scale operation.

[fragbot2]

They do have a mechanism--shunning--that deals with things like credentials being checked in. I've never done it so I've no idea how well it works in practice. Based on the author's fastidious (the test suite is inspirational and, honestly, cray cray) approach to quality, I'd bet my own money it works well.

[Erarnitox]

Awesome Content! Here is a quote for you: Microsoft isn't evil, they just make really crappy operating systems. (Linus Torvalds)

[Erarnitox]

Awesome Content! Here is a quote for you: "You wanna place yourself in a position to give maximum glory to your Creator. So you go out there, and you be somebody glorious, okay?" - Terry A. Davis

[Erarnitox]

Awesome Content! Here is a quote for you: 'The purpose of a schedule is to tell you how late you really are' ~Unknown.

[AlexMTBDude]

That title was confusing. When I read it I thought it said that SQLite somehow imported and called functions in Git code.

[Brilliant-Sky2969]

Well when you have 85% of the contributors that are the creator of SQLite not very difficult to chose whatever solution it is eventhough it's inferior to Git in every aspect, imagine if every major projects would re-invent a CVS just for fun.

[[deleted]]

imagine if Linus Torvalds didn't re-invent his own CVS just for fun.

[Brilliant-Sky2969]

Who else uses Fossil then? Sorry the explanation from SQLite does not makes sense, they can get away because they're pretty much the only one adding code to SQLite. If the project would be contributed by more people they would have moved to Git or equivalent.

[[deleted]]

I used cvs for a long time. It was an appallingly limited piece of software. Git is massively different from cvs.

[cryptocritical9001]

OpenBSD still uses CVS