22 ms·

Why SQLite does not use Git (2018)

252 points by pezzana 5y ago

1vuio0pswjnm7 5y ago
"The mental model for Git is needlessly complex" News flash: Many programmers love complexity. Complexity == popularity == profit Prove me wrong, please (I seek simpler stuff)
- strictfp 5y ago
  I think the mental model is "I can use this tool, since it's hard it will make me look smart"
  - loudthing 5y ago
    People who have stuff on their monitors specifically so others think "they must be really smart" are the scum of the earth.
- deleted 5y ago
  [deleted]
- throwawayboise 5y ago
  Many new/inexperienced programmers love complexity. I used to get into exploring every nook and cranny of every config file and endlessly tweaking settings. Now I strive to use everything with default settings if at all possible.
  - da_chicken 5y ago
    Yup. When I have to install it for the sixth time the last thing I want to do is remember what I had to configure the fifth time and what I had learned that I needed to stop configuring from the third and fourth times. Now I want my operating system and my tools to shut up and get out of my way because whatever irrelevant thing they think is important is not what I ever need to be working on.
  - hn_throwaway_99 5y ago
    > Many new/inexperienced programmers love complexity. Not sure if you're trying to argue that Linus was a "new/inexperienced" programmer when he first wrote git. I think the "it's too complex" argument against git is misplaced, or at least not complete. I don't find git "complicated for complexity's" sake (e.g. looking at Enterprise Java Beans back in the day), but it has a very specific workflow in mind for its conceptual model, and if you don't understand that conceptual model, you're just going to be confused. It took me a while to grok that model, but once I did it clicked and I understood it. Not saying it's optimal, but it also has a lot of benefits.
    - throwawayboise 5y ago
      OpenBSD uses CVS to develop an entire OS, kernel and userland. Git's complexity is not required.
    - da_chicken 5y ago
      Exposing the user to the totality of the complexity of the problem is, perhaps, the most complete and indefensible failure of an otherwise successful software design that I can imagine.
      - couchand 5y ago
        All abstractions are leaky, but an abstraction meant to never lose the work of a power user is maybe more defensibly leaky than average.
    - whynotmaybe 5y ago
      Whatever I read about Linus seems to imply that he is far smarter than me but git is a great tool for his personal purposes. This is an 18wheeler that can haul anything but for "basic" dev doing simple administrative apps, a bicycle VCS is more than enough. A lot of dev I've met don't even understand the deep ramifications of multiples branches with any VCS so understanding the complexity of git is way above what we require of them. Git has a lot of benefits but I'm not quite sure that it's really a good thing that it is slowly becoming the de facto standard. Wait and see...
- TheDudeMan 5y ago
  Wow. Maybe this is why most software sucks.
- geitir 5y ago
  I would say it's more like complexity == feels like I've accomplished something
  - sverhagen 5y ago
    Best feeling in the world, as a programmer: removing code! (My implication: removing complexity.)
    - kps 5y ago
      Removing code while maintaining or increasing functionality.
- LAC-Tech 5y ago
  I think you're right. And as much as I want to think I'm ruthlessly simple, I do notice this in myself as well. Everyone will agree with us of course, but suggest something minor like "hey maybe you don't need react" and here come the reservations. To paraphrase Alan Kay, everybody likes simplicity except for the simplicity part.
- Koshkin 5y ago
  Do you mean the UNIX way (cp, diff, patch)?
- manquer 5y ago
  You are right there is a correlation but not because programmers love complexity. It is easier to design complex systems and harder to simplify. Also complex systems have positive economic incentives like consulting training books or that if simple will not be sustainable.
- tshaddox 5y ago
  The entire job is managing complexity, either by developing good abstractions for adding and maintaining necessary complexity, or by removing unnecessary complexity. I love this process, so I guess you could in some sense say that I “love complexity,” but not in the sense that I increase complexity whenever I can.
- nijave 5y ago
  I think some of it also comes from treating symptoms instead of problems. "Git doesn't do X so I'll just make this tool to add the feature" One hundred tools and a few consolidations into toolkits later you have a massively complex tool chain scope creeped from some much smaller problem deep down in git
- yalok 5y ago
  My observation is that it all depends on scale. Huge projects (such as Linux code base) can’t survive with simple solutions (e.g. non-distributed VCS). Loving complexity for the sake of complexity or sake of job-security or competitive advantage covers only small subset of situations. There’re a lot more cases where seemingly simple problem has a lot of hidden complexity, and only complex enough solutions succeed at successfully solving it and staying competitive on the market…
- wyoung2 5y ago
  Complexity is fine in something like a programming language or a text editor where increasing mastery can mean better software and hopefully more money. How do I make more money by learning arcane Git commands? We don't use DVCSes for their own sake, we use them to accomplish something else. To the extent that the DVCS gets in the way, it's an opportunity cost.
- dreyfan 5y ago
  > Complexity == popularity == profit Entire node/js/ts ecosystem resonates strongly here. They reinvent the wheel, assign it a new name, thought-leaders market those inventions to every corner of the tech ecosystem, and then they add another few layers to their build chain.
strictfp 5y ago
I love git because it's fast, but the UX is trash
- db48x 5y ago
  Have you written your own UI yet? I recommend trying out Magit.
  - throwawayboise 5y ago
    Agreed. If you have to use git, Magit is a great tool.
    - db48x 5y ago
      And if you’re implementing a git ui, it’s a great place to steal ideas from too!
posharma 5y ago
A question I'd asked a few months ago: https://news.ycombinator.com/item?id=27586432 https://news.ycombinator.com/item?id=27586432.
qntty 5y ago
Git isn't perfect but for me it was a huge improvement over SVN. The complexity was worth the ability to do stuff I never did with SVN.
- strictfp 5y ago
  Agreed. Perforce has much better UX and tooling than git though.
  - dahart 5y ago
    P4 has better UI than git, but I’d argue the UX of command line p4, and of workflow issues like workspace mappings and connections and of course branching, are all dramatically inferior. (Caveat, I haven’t used p4 streams yet.) The one thing p4 has that I sorely miss and nothing in git-land comes close is the time-lapse view!
    - strictfp 5y ago
      I probably supressed my memories of connection issues :D I love DVCSes, hated not being able to work offline I agree with the time lapse view and p4merge. Maybe one should hack together a time lapse tool for git? :thonk:
      - dahart 5y ago
        Git gui blame tried, but lands very far short of time lapse view. Git’s underlying representation might make time lapse technically difficult. I think there might be some other UI attempts too, I just haven’t tried because I’m usually on the command line and using different OSes often.
- wyoung2 5y ago
  The thing is, Fossil is also a huge improvement over Subversion without losing its day-to-day simplicity.
cardosof 5y ago
git is one of those things that are so popular and accepted as the true way that questioning its use makes you look like an idiot but, in reality, many devs would benefit from a simpler version control system, one not intended to handle arguably the world's most popular source code.
- deleted 5y ago
  [deleted]
ankur9sri 5y ago
Online training on Git at Evision Technoserve pvt ltd Evision Technoserve is an ISO 9001:2015 certified Fast-Growing and Professionally Managed IT Consulting, Manpower Outsourcing and Staffing Recruitment Company with our operation based in Pune, Bengaluru, Chennai, Hyderabad, Kolkata, Lucknow, Delhi NCR, Noida, and Ahmedabad. Evision has successfully trained and placed 15,500+ IT Fresher's and Professionals in top IT MNCs like IBM, Wipro, Infosys, HCL Technology, TCS, Tech Mahindra and many other. We provide 100% job placement guarantee, whether a candidate is from IT Background or Non-IT background, with best Placement Record to Wipro, IBM and HCL Companies. Check Our success Story: - bit.ly/3uUGPtV Apply and Join Online: https://lnkd.in/g8s-3ZE https://lnkd.in/g8s-3ZE Mail :hr@evisions.co.in Web : www.evisions.co.in
judge2020 5y ago
Previously https://news.ycombinator.com/item?id=16806114 https://news.ycombinator.com/item?id=16806114
- dang 5y ago
  Thanks! Macroexpanded: Why SQLite Does Not Use Git - https://news.ycombinator.com/item?id=16806114 https://news.ycombinator.com/item?id=16806114 - April 2018 (608 comments) also this bit: Why SQLite Does Not Use Git? - https://news.ycombinator.com/item?id=26112802 https://news.ycombinator.com/item?id=26112802 - Feb 2021 (1 comment)
throwawayboise 5y ago
"The mental model for Git is needlessly complex" This, in a nutshell, sums up my feelings about git.
- emodendroket 5y ago
  I never feel this way. When I started to use it, I only had to understand a few concepts. And when it started to get more complex, it was because the things I wished to do were more complex in the first place.
  - strictfp 5y ago
    Did you ever use any other VCS?
    - emodendroket 5y ago
      I used mercurial a bit when I was starting out but I saw which way the wind was blowing and switched.
      - throwawayboise 5y ago
        Kind of similar. I went from Subversion to git, then tried mercurial. I found mercurial to be more natural, and still use it for my own projects. I have never seen it used in the workplace though.
        bluGill 5y ago
        My workplace switched from hg to git. Hg didn't get support for all the other tools we use. The Jenkins hg maintainers were all using git when we checked, and it showed. That is but one example of a tool that didn't work with hg.
    - throwawayboise 5y ago
      Subversion, and mercurial to a lesser extent. CVS and Visual Source Safe way back in the day.
emodendroket 5y ago
Well, whatever the article says, isn't the actual reason "we have this other one we built using SQLite"?
- eipipuz 5y ago
  I don't get that at all. To me the answer is "we want things out of the vcs that we don't get from git nor github/gitlab." The fundamental difference is: sqlite is a cathedral, git is for bazaars. That's kind of a big deal.
- ripley12 5y ago
  I can’t recall where, but I think I heard Richard Hipp say that developing Fossil helps the SQLite developers dogfood SQLite. There’s certainly some synergy between the projects.
- arghwhat 5y ago
  It does come off as excessively NIH, with the first point even just being a client UI complaint.
  - im3w1l 5y ago
    Well sqlite is more of a passion project than about doing things in the most capitalistically efficient way right? So "it makes me happy to invent things here that scratch my itches just so" is a valid reasoning.
    - rswail 5y ago
      SQLite is in every phone on the planet and the author has a company that makes money selling it to environments that require extensive validation (eg airplane software). It's not a "passion project" by any means. It's a highly developed, well engineered piece of software and there's lots of other non "passion projects" that would do well to learn from it.
      - SubjectToChange 5y ago
hn_throwaway_99 5y ago
> Git does not track historical branch names That's my biggest pet peeve on this list. Git branches are really just pointers to the HEAD of some commit history, but if you've had a bunch of merges in the past it can be very difficult to tell which commit belonged to a particular branch at some point in the past. Is there a good solution for this? Seems like it would be trivial to add a piece of metadata about which branch someone was on when a commit was made.
- db48x 5y ago
  Git _does_ keep track of historical branch names. It is called the reflog. For each ref there is a log of what commits it pointed to. See `git help reflog`.
  - jpitz 5y ago
    The reflog is 1. garbage collected 2. local only
    - temac 5y ago
      Also the branches are indicated at their positions at the moment you call reflog, not as they were for each operation of the log.
- aaaaaaaaaaab 5y ago
  If you keep your history linear by using rebase only, then this becomes a non-issue.
  - anonymoushn 5y ago
    This actually makes it much harder to answer the question "What happened with the branch of X name 2 years ago?"
    - clintonb 5y ago
      What is the value of that information? When I’ve looked at older commits, I either want to know about the resulting code or the context (e.g., motivations, discussions). A fixup commit, or some other intermediate commit isn’t useful.
loudthing 5y ago
"When I want to see what has been happening on SQLite, I visit the timeline and in a single screen I see a summary of the latest changes, on all branches. In a few clicks, I can drill down as much detail as I want. I can even do this from a phone. GitHub and GitLab offer nothing comparable. 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 mobile." This is a valid point. I've always wondered why it seems Github goes out of its way to hide the typical commit tree navigation that so many git clients support (Sourcetree, gitk, tortoisegit, etc).
- bullfightonmars 5y ago
  I have definitely felt this pain when navigating i to the past to investigate the origin and evolution of changes.
- monkeybutton 5y ago
  Yes! I find it odd. Maybe they just expect you to use one of those clients if that's what you want to see?
  - loudthing 5y ago
    That is a good point. I know now when I visit a project on Github that I am seeing the latest version of all files, but that is only because I'm already aware of how git works.
    - bostonvaulter2 5y ago
      Depending on what the default branch in GitHub is set to you might not be viewing the "latest" version of the files. i.e. the default branch is `main` but all development happens on a long-lived `dev` branch that is only merged into `main` once a month.
    - kazinator 5y ago
      Someone who doesn't know what version control is will also just assume they are seeing the one and only version of the files.
strictfp 5y ago
"How should I change to a different branch?" asked the programmer. "Use git checkout." "And how should I create a branch?" "Use git checkout." "And how should I update the contents of a single file in my working directory, without involving branches at all?" "Use git checkout." https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/
- chrisfosterelli 5y ago
  In fairness, git has improved on this and separated these into `git switch` / `git restore`
  - Izikiel43 5y ago
    First time I hear about this
    - krallja 5y ago
      `git status` will tell you about `git restore` if you have staged or uncommitted changes
      - Minor49er 5y ago
        `git status -s` also gives the shorthand version of this. I have it aliased to `gs` pretty much everywhere because it's really useful to me.
  - strictfp 5y ago
    Yeah, but they denied the problem for the longest time, so they deserve some flak for it :)
    - chrisfosterelli 5y ago
      Probably true. IMO the crime of checkout is that the command really is `git checkout <tree> -- <path>`, which updates that local path to match that git tree, but it implicitly fills `tree` with the current branch and `path` with all files. It actually makes sense if you learn the full command but makes zero sense when you google individual common operations and then they thought "this command should also have a shorthand to create branches" I suppose
dvt 5y ago
The funny thing is that the xkcd cartoon isn't even that much of an exaggeration. Countless times, I've literally copied files from a working branch, nuked the branch, then pasted them into a new branch because I couldn't get something to merge for some stupid reason that would've taken like half a day to figure out.
- throwawayboise 5y ago
  Seen it happen so often when people try to get fancy with branches and merges. Yes I'm sure there's always a way to recover using the tools, but if you are not a git guru and don't have one handy, deleting and cloning is usually the more pragmatic way.
  - strictfp 5y ago
    IMO conflict resolution is almost always harder than redoing the change by hand, especially while looking at the old diff and redoing it towards the new branch. Kind of ironic given how hard diff editors try to help.
    - stjohnswarts 5y ago
      When I get into a three way merge it's usually just too late in the day, so I will just save off my stuff and merge in manually :) like you said. Two things to compare against is plenty.
  - cormacrelf 5y ago
    I don't see the issue. This is how people fix everything else, it is what comes naturally, and it works every time. I would much prefer it this way, than what Fossil appears to do in section 3.3 of this article, having a single copy of the database per system. mkdir ~/fossils fossil clone https://sqlite.org/src ~/fossils/sqlite.fossil mkdir ~/sqlite; cd ~/sqlite fossil open ~/fossils/sqlite.fossil
- unclebucknasty 5y ago
  Yeah, probably just about every dev has had to do this when first learning git. One way to measure the over-complexity of software might be: 1. How easy it is to screw up 2. How hard it is to fix things once you've screwed up. Git doesn't score well by that test IMO. Back when I first learned Git, I thought it needed an undo, at least for the local repository. Not a revert commit or partial/piecemeal undo this or that, but an "I screwed up, take me back to x point in time or snapshot" level undo.
37ef_ced3 5y ago
What I still can't believe is that the world chose git over hg. Why would you use git if you could use Mercurial instead?
- TeeMassive 5y ago
  - Speed - The fact that it was Linus developing it - The fact that it was released just after Git - It's pretty much like Git and evolved to be usable like Git - Git had way more advanced tooling and still does to this day
  - quleap 5y ago
    > - It's pretty much like Git and evolved to be usable like Git > - Git had way more advanced tooling and still does to this day Very untrue. Mercurial has advanced concepts and features that Git cannot dream of, e.g. changeset evolution.
- arantius 5y ago
  For me: `git gui` and the stage. Incrementally building my commits line-by-line (often with other working directory changes I don't want) feels invaluable. Work forced me to go git->hg and it frustrates me every day.
- krallja 5y ago
  Basically, GitHub. GitHub would have won even if it were MercurialHub. It had a better user model of the problem to be solved than any other SaaS code forge, and it supported both open-source bazaar-style development and private enterprise. The gamification and social network features are KILLER. Also, the Mercurial developers never had the built-in fan base of Linus Torvalds. Anyone who wanted to work on Linux had to use Git, so that was another major reason to learn (and stick with) Git.
  - adamrezich 5y ago
    imagine "SubversionHub" instead...
nakovet 5y ago
I used fossil in the past for my personal projects, it worked great but it had too many features for a solo developer, getting others on board of using it is hard, given git is mainstream.
throwaway984393 5y ago
GIT - the stupid content tracker "git" can mean anything, depending on your mood. - random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant. - stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang. - "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room. - "goddamn idiotic truckload of sh*t": when it breaks This is a stupid (but extremely fast) directory content manager. It doesn't do a whole lot, but what it _does_ do is track directory contents efficiently. - README, Linus Torvalds, Git source code, April 7th 2005
encryptluks2 5y ago
I thought for a moment this would be why SQLite doesn't use Git to store its data structures, which I really wish it did. Still looking for a database that acts as a virtual file system, and automatically orders data into a file tree structure.
- kevin_thibedeau 5y ago
  Create a table of inodes and link them together with some blob fields. There's your filesystem.
deleted 5y ago
[deleted]
bluedino 5y ago
I HATE Git. It seems like every other over-complicated, over-engineered solution to problems that should be simple. I used svn for a long time. New developers got it right away. Git is treacherous waters for 7/10 of the developers I've worked with. That said, I LOVE GitHub and gitlab. Amazing tools for collaboration. But the Git part doesn't really do it for me. I'm waiting for something better to take its place.
- TeeMassive 5y ago
  > It seems like every other over-complicated A DAG is one of the simplest data structure out there. What is complicated is doing merges in non-DAG CVS and let's not even talk about more "complex" operations like putting all of your commits on top of a branch, only committing a single line and, god forbids, creating branches without asking for permission. > over-engineered solution to problems that should be simple I get it that you're unfamiliar with how not nice databases schemas are. A git repository from 2005 will still work in 2021. AFAIK all other CVS will fail at this because they rely the overly complicated data representation. Git's internal representation is very simple. Filesystem snapshots referred to by content and these snapshots that can reference other snapshots to form a DAG. Just because you didn't take one hour to understand this doesn't mean it's "complicated". > That said, I LOVE GitHub and gitlab. These would not have existed if not for Git's internal representation that allows the necessary flexibility for other tools and extensions to integrate directly.
- PufPufPuf 5y ago
  You may like GitLess, it uses git under the hood, but has a simplified CLI: https://gitless.com/ https://gitless.com/
aynyc 5y ago
I don’t care about GIT. Perforce is my favorite. Takes an hour to understand everything to be productive.
- mbfg 5y ago
  does perforce still just allow one branch per repo?
- nichos 5y ago
  It's been about 5 years since I used Perforce, but streams were a nightmare. Sharing files down 2 "levels" of streams was such a huge pain.
- dahart 5y ago
  When a programmer in the games company I worked in started rallying to switch from p4 to git and got momentum, I thought it was going to be a mistake. No doubt it took a lot of learning, but eventually I came to see it was worth it. One thing that’s not well appreciated even with most people who use git is how much safety net it can provide against losing changes accidentally. I know a lot of programmers who don’t care and will blow away and re-clone a repo before learning how to use git reflog. But, in git you can recover from almost anything if you know how. P4 is pretty terrible when you want to try something multiple ways, or when you want a small team to prototype a feature without affecting everyone. I’m actively using both git and p4, and I can’t tell you how many p4 shelves I’ve got stacked up. They keep collecting because there’s nowhere else to put them, and it’s the only (crappy) way to test parallel ideas. Using git for trying out things in different ways is so nice and so fast once you get fluent with it. Of course your stance is valid and perfectly fine, you don’t have to change away from p4, but I think you might be surprised how git changes your thinking about source control. BTW I haven’t used Fossil or hg or plastic or other new source control systems, but I would assume you could replace any of them with git in my above text.
Aperocky 5y ago
good for Sqlite to simplify on their tools. But: Git has a lot of weird stuff and fluff, but that doesn't mean you have to use all of them. For instance, I try to almost never branch and use deployment flags instead - then you can always rebase and maintain an extremely simple commit history. Simple >> Complex.
- rsj_hn 5y ago
  I think that's fine for solo development but as soon as you have a real collaborative project -- which, supposedly, is why you need a peer-to-peer vcs, then there comes a time when dev A is working on some feature for the future, and dev B is debugging on an existing release, and now you really need branches because B's fix is going to need to be pushed out ASAP but dev A's feature is still being worked on.
  - Aperocky 5y ago
    But that's what I'm describing (I do work for one of the FAANG), all feature work are either ready, or gated by feature flags. With practice, it becomes easier to divide feature work while not cause any existing impact, it also forces you to make your code logic cleanly separated. The biggest benefit of this approach imo is the drastically reduced chance of a bad feature going out because someone had worked on it for 5 months in isolation and it becomes virtually impossible to debug.
    - rsj_hn 5y ago
      Yeah, I'm familiar with feature flags, but that doesn't really solve the problem of needing well-defined releases and that these releases themselves need to be patched and possibly supported for a long period of time as determined by contract or support commitments. Also feature flags are not going to be able to cover all code changes. For example, it's hard to put code refactoring behind a feature flag. Finally, wide-spread use of feature flags as a type of in-code branch certainly seems like code-smell to me. It's fine for a while, but after 20 years you're going to have a difficult time maintaining that repo unless it's done with sufficient discipline that those feature flags are quickly removed once the feature hits production. It will also screw with your automated static analysis tooling.
boudin 5y ago
I'm far from convinced by this article. It's starts by saying that it's not comparing git and fossil but just keeps trying to throw generalities at your face how fossil is so much better and smarter than git. It sometimes compares git and all of a sudden compares github or gitlab, no reason given. So what is it about, comparing git, github or gitlab? Apparently git is to complex for developers, sorry but I have yet to see a developer not managing to work with git. Either I've always worked with geniuses or this is a non-problem.
- tiagod 5y ago
  The author is comparing with github/gitlab as fossil offers both VCS features, like git, but also features a Web interface with issues, wiki and forums, which you can only get with those third party products.
  - boudin 5y ago
    Then the comparison would be fair if it would go through all the different options. Picking the one that is quite heavy to host like gitlab (but does way more than what fossil does by the way) for the purpose of saying that git sucks is misleading. There's options like gitea that are lightweight and super easy to host.
- BoorishBears 5y ago
  >Apparently git is to complex for developers, sorry but I have yet to see a developer not managing to work with git. Either I've always worked with geniuses or this is a non-problem. You must work with geniuses. No one I know has never been at the place where you just accept the tree is fucked, delete .git and paste your changes back into a fresh checkout. Granted now I understand things like git reflog so it's been many years since then, but git is as far from approachable as tooling gets...
  - boudin 5y ago
    Thanks then, it means I must be managing my team right :) I've never seen a tree being broken, and needing this kind of action. Don't get me wrong, the git cli could definitely be improved, but as long as you have a clear workflow and map it to git actions it works well.
MBCook 5y ago
It’s 2021. How I wish we had moved past pointless git bashing by now. We get it. Many people don’t like it. They prefer to use $TOOL instead. It’s been 16 years. Can’t we resign this to emacs vs vi category of things we’ve largely accepted and stopped arguing about yet? I’m not mad at the article. They have preference and wrote down why they don’t use the more popular tool for when people ask. That’s fine. But I’m guessing it was posted to have the “discussion” we’re having right now (and every time got comes up). People bashing (or defending) git. And it’s exhausting. We’re half way to the age of vim. Can we let this one go too please?
- NoahTheDuke 5y ago
  If a tool attracts enough ire that such arguments arise frequently, then a non-zero number of people are dissatisfied and could be satisfied by other tools. That is worthy of discussion. Additionally, it is cathartic (and occasionally even productive) to complain about the warts and sharp edges of a popular tool, especially when the tool is the overwhelming the tool of choice in its domain.
- richie_adler 5y ago
  Your comment basically can be summarized as "Everybody stop discussing this topic that doesn't interest me!" To which I can only reply: No.
- casion 5y ago
  I agree that it's exhausting, however using git is even more exhausting... so the complaining and comparisons will continue.
dekhn 5y ago
"The mental model for Git is needlessly complex" that's it, right there. Why are you bothering me about a detached head?
- wyoung2 5y ago
  "Detached head" is Git's way of saying "I don't know how to find my children when you say something like 'git checkout abcd1234'". Fossil can do this, so you can point someone to a historical checkin and Fossil won't get lost should you later commit on top of it. Git's warning you that if you do that, you may end up with an orphaned commit.
  - rezonant 5y ago
    More like "I don't know what gitref to move (*well, change) if you commit". `git checkout` isn't relative to the current ref is it?
- rezonant 5y ago
  Agreed on this one. It should instead let you handle this when you commit, make you reckon with what to call this new gitref. That is when I care about whether I'm connected to HEAD or not Yeah, it would make you `git branch` to give it a name, or an override option to commit it without a name
- Spivak 5y ago
  I think it's actually the opposite. Git's model is really really simple and pushes all the complexity onto the tooling and the user.
  - patal 5y ago
    That's exactly the parent's complaint: Git's tooling and user interface is (unnecessary) complex.
- sershe 5y ago
  I dunno, git model always felt extremely intuitive to me... there are very few core concepts and ideas and all the complexity is layered on top of that and is easily decomposed. I feel like git concepts are very elegant while allowing a lot of complexity, like C/C++ pointers ;)
passerby1 5y ago
> Git does not provide good situational awareness > [...] > I can even do this from a phone. > [...] > GitHub and GitLab offer nothing comparable. Seems like git=(gitlab|github) for the author. I don't agree this is right, as these both are totally different products comparing to git and made with different purposes and aims. Phone access. Okay, probably we are in different culture contexts, but for me a need to use my phone to access source code (or tickets) always means things went very very wrong.
- rezonant 5y ago
  Maybe the wrong culture. I use GH to reference source code from my phone quite a lot. I spend half my time on the phone, and when I'm in a meeting, my phone is the obvious way to be in those meetings. Ensuring I have first class access to everything from my phone is a huge priority. The author may have a point about having better views of the source from GH/GL, but they are absolutely providing a decent experience for it already.
liveoneggs 5y ago
dr hipp also uses his own editor so that might be a clue
m0zg 5y ago
Does Fossil support some sort of a backend for large/binary files? This, more than anything else, is my gripe with Git. LFS is a pain in the ass, and it sometimes breaks, too. I want something that's baked in and doesn't need to be enabled on the side.
- wyoung2 5y ago
  I daresay there is no DVCS appropriate for many large files that change. You want something more like a classic non-distributed VCS so you're not cloning the entire history of huge files. Worst is when they're data-compressed so you're not only pulling all historical versions but also most every byte of each historical version. I wrote an article for the Fossil docs covering this, but the core experiment can be run against any VCS: https://fossil-scm.org/home/doc/trunk/www/image-format-vs-repo-size.md https://fossil-scm.org/home/doc/trunk/www/image-format-vs-re...
sieve 5y ago
I used Fossil for a bit a few years ago. A nice, self-contained tool that stores everything in a single file that can be easily backed up. Had to give up on it because using two different revision control systems became inconvenient after a while. But I regret the loss of Mercurial, after having used it for a decade or so, more than that of Fossil. It always bothered me how a user-hostile piece of software like git rapidly took over the world. But then I remembered sh and bash and realized that someone thought that these softwares should be designed the way they were decades after Pascal and Lisp and hundreds of other sensible languages came into being, and they took over the world too.
- crossroadsguy 5y ago
  > It always bothered me how a user-hostile piece of software like git rapidly took over the world. After almost 7 years on git I have given up on getting git and I stick to what that XKCD comic said - remember some commands and just keep syncing. It felt one has to make it into a masochistic exercise to understand it. I feel similar about Markdown (though I won't call it user hostile). Because there were and there are better and accessible/uncomplicated alternatives.
  - aidenn0 5y ago
    > I feel similar about Markdown (though I won't call it user hostile). Because there were and there are better and accessible/uncomplicated alternatives. I don't know; all of the lightweight markup formats are a mess. AsciiDoc/AsciiDoctor is almost great but they seem to have completely borked escaping of inline punctutation[1] Restructured Text is very "meh" but is better than markdown because directives at least make it more sanely extensible. The downside is it's missing lots of features in its core becase "you can just use a directive" Markdown was actually pretty good for its original purpose (write html with fewer html tags), but completely falls down for its current common use case (untrusted user input, where you won't allow the user to fallback on html). 1: https://github.com/asciidoctor/asciidoctor/issues/901 https://github.com/asciidoctor/asciidoctor/issues/901
  - ajkjk 5y ago
    I'm eh about Git but .. I love markdown. Sure it has some rough edges but it is such a good idea, and I'm so glad it caught on everywhere.
gravypod 5y ago
I recently (last few months) upstreamed changes to a project maintained by the SQLite owners. The process was fairly straight forward but the difficulty of creating the patch was much higher. I needed to learn a bunch of things that I didn't already know. I did this because I didn't want to maintain the divergence from our code (and wanted a more general fix which the devs could implement better than I could) so I put up with the pain. I don't think I'd do this at home if I was just bored. Maybe that makes me lazy (which I am) or a bad developer. It is a barrier though as, like it or not, we all know git.
- deleted 5y ago
  [deleted]
dlp211 5y ago
The best source control system I have used to date is Google's G4 with hg (mercurial) bindings, I think they called it Fig if memory serves me. I'm not sure if there is any product that is similar to it outside of Google.
- arxanas 5y ago
  You might be interested in my project https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless, which is intended to replicate such a workflow.
dikei 5y ago
I start out with Hg then move to Git because Hg felt too slow for my need at the time. Ironically, Google & Facebook choose Hg over Git because they can make Hg run much faster than Git at their scale: While both vanilla Git and Hg are too slow for their huge monorepo, they basically replaced most of the core of Hg with their own implementation to speed it up for internal use, keeping only the Hg cli.
ryanisnan 5y ago
I sure as hell don't want to learn another VCS, unless it's just better, and has any chance of becoming widely adopted. I think the short list of git grievances here are outweighed by the costs of not using git.
zzo38computer 5y ago
I don't like git. Fossil is good, but it isn't customizable enough. For example, I would prefer to implement a web interface without CSS and JavaScripts (and perhaps also to be able to expose with gopher and gemini too, and possibly also other protocols), and I would prefer to ensure all functions are available by command-line interface, and I would prefer to deal with and write raw artifacts directly (rather than only use the built-in commands) (maybe it is possible to do this with the sync protocol, but I haven't tried this).
oxplot 5y ago
Anyone using patch SCMs like pijul?
- euroderf 5y ago
  Installation on macOS is still broken, with no signs of progress. Quite discouraging.
beermonster 5y ago
"GitHub and GitLab offer nothing comparable. " This is true. But this is a criticism of Git**b not git.
clhodapp 5y ago
It seems strange to talk about reduced distraction and saved brain cycles as a justification for writing and maintaining an entire VCS (with a rich UI) and project management tooling
rkeene2 5y ago
What I miss from Fossil, some of which I've brought up on the Fossil Forum are: 1. Pull Requests ( https://fossil-scm.org/forum/forumpost/01d77b7259ea0b00?t=h https://fossil-scm.org/forum/forumpost/01d77b7259ea0b00?t=h ) 2. Code Reviews -- I spend atleast half my time doing code reviews these days and the tools just aren't there for Fossil, GitHub.com has good tools 3. "git add -p" -- I try to make commits a logical change, often figuring out what I'm doing involves making a set of physical transforms and then I like to commit them as logical transforms
krylon 5y ago
One thing I came to like very much about Fossil is that on Windows, the whole thing is just a single executable file, just drop it anywhere in your %PATH%, and you're good to go. The builtin web interface is very nice, too. I have since had to switch to git at work, and after discovering magit I don't think I'd want to go back. But Fossil has been very pleasant to use.
zoomablemind 5y ago
I always thought that Git and Fossil address different concerns of the respective underlying projects (Linux kernel work and SQLite corresp.) It's clear that both projects need a revision control to manage changes, yet the requirements seem to diverge. Linux kernel is a massive project with a lot of involved contributors. While SQLite is a tighter team, majority of commits are reasonably by 'drh'. And the codebase itself, of course, is not on the same span scale. As such, my understanding is that Git needed to allow slicing and dicing of various sources of patches so that they could be properly sequenced, tested, reviewed, and integrated (thus index/staging and rebase). On the other hand, SQLite needed an immutable history as part of its exhaustive approach to testing and documentation, and Fossil could also be an excellent testing ground for SQLite too ... and a more cohesive CLI (thus the repo-db, security model, persistent branch names, non-destructive delete etc.). So, just as great Masters do, they created the right tools for their project. AND they shared their tools with the rest of the world, that is us all, for which we are grateful indeed. Now, is Git or Fossil a right tool for your project depends on your needs and choices. Not all projects need the slicing and dicing of the patches, just as not all projects require immutability of the history. If anything, the current reality is that Git became a sort of C of the revision control, just it's possible to have a practical use of it without the need to learn it thoroughly. The requirement to rebase your changes for a PR is rather imposed by project conventions, not the tool. I like to think about Git as being a Swiss knife to carve the wooden blocks of patches, so they fit together. Meanwhile, Fossil is a kind of a handy set of chisels to etch the revisions into the stone tablets of the project.
Pokepokalypse 5y ago
actual timestamps (instead of "relative time"). . . what a concept.

252 points by pezzana 5y ago

"The mental model for Git is needlessly complex" News flash: Many programmers love complexity. Complexity == popularity == profit Prove me wrong, please (I seek simpler stuff)

strictfp 5y ago
I think the mental model is "I can use this tool, since it's hard it will make me look smart"
- loudthing 5y ago
  People who have stuff on their monitors specifically so others think "they must be really smart" are the scum of the earth.
deleted 5y ago
[deleted]
throwawayboise 5y ago
Many new/inexperienced programmers love complexity. I used to get into exploring every nook and cranny of every config file and endlessly tweaking settings. Now I strive to use everything with default settings if at all possible.
- da_chicken 5y ago
  Yup. When I have to install it for the sixth time the last thing I want to do is remember what I had to configure the fifth time and what I had learned that I needed to stop configuring from the third and fourth times. Now I want my operating system and my tools to shut up and get out of my way because whatever irrelevant thing they think is important is not what I ever need to be working on.
- hn_throwaway_99 5y ago
  > Many new/inexperienced programmers love complexity. Not sure if you're trying to argue that Linus was a "new/inexperienced" programmer when he first wrote git. I think the "it's too complex" argument against git is misplaced, or at least not complete. I don't find git "complicated for complexity's" sake (e.g. looking at Enterprise Java Beans back in the day), but it has a very specific workflow in mind for its conceptual model, and if you don't understand that conceptual model, you're just going to be confused. It took me a while to grok that model, but once I did it clicked and I understood it. Not saying it's optimal, but it also has a lot of benefits.
  - throwawayboise 5y ago
    OpenBSD uses CVS to develop an entire OS, kernel and userland. Git's complexity is not required.
  - da_chicken 5y ago
    Exposing the user to the totality of the complexity of the problem is, perhaps, the most complete and indefensible failure of an otherwise successful software design that I can imagine.
    - couchand 5y ago
      All abstractions are leaky, but an abstraction meant to never lose the work of a power user is maybe more defensibly leaky than average.
  - whynotmaybe 5y ago
    Whatever I read about Linus seems to imply that he is far smarter than me but git is a great tool for his personal purposes. This is an 18wheeler that can haul anything but for "basic" dev doing simple administrative apps, a bicycle VCS is more than enough. A lot of dev I've met don't even understand the deep ramifications of multiples branches with any VCS so understanding the complexity of git is way above what we require of them. Git has a lot of benefits but I'm not quite sure that it's really a good thing that it is slowly becoming the de facto standard. Wait and see...
TheDudeMan 5y ago
Wow. Maybe this is why most software sucks.
geitir 5y ago
I would say it's more like complexity == feels like I've accomplished something
- sverhagen 5y ago
  Best feeling in the world, as a programmer: removing code! (My implication: removing complexity.)
  - kps 5y ago
    Removing code while maintaining or increasing functionality.
LAC-Tech 5y ago
I think you're right. And as much as I want to think I'm ruthlessly simple, I do notice this in myself as well. Everyone will agree with us of course, but suggest something minor like "hey maybe you don't need react" and here come the reservations. To paraphrase Alan Kay, everybody likes simplicity except for the simplicity part.
Koshkin 5y ago
Do you mean the UNIX way (cp, diff, patch)?
manquer 5y ago
You are right there is a correlation but not because programmers love complexity. It is easier to design complex systems and harder to simplify. Also complex systems have positive economic incentives like consulting training books or that if simple will not be sustainable.
tshaddox 5y ago
The entire job is managing complexity, either by developing good abstractions for adding and maintaining necessary complexity, or by removing unnecessary complexity. I love this process, so I guess you could in some sense say that I “love complexity,” but not in the sense that I increase complexity whenever I can.
nijave 5y ago
I think some of it also comes from treating symptoms instead of problems. "Git doesn't do X so I'll just make this tool to add the feature" One hundred tools and a few consolidations into toolkits later you have a massively complex tool chain scope creeped from some much smaller problem deep down in git
yalok 5y ago
My observation is that it all depends on scale. Huge projects (such as Linux code base) can’t survive with simple solutions (e.g. non-distributed VCS). Loving complexity for the sake of complexity or sake of job-security or competitive advantage covers only small subset of situations. There’re a lot more cases where seemingly simple problem has a lot of hidden complexity, and only complex enough solutions succeed at successfully solving it and staying competitive on the market…
wyoung2 5y ago
Complexity is fine in something like a programming language or a text editor where increasing mastery can mean better software and hopefully more money. How do I make more money by learning arcane Git commands? We don't use DVCSes for their own sake, we use them to accomplish something else. To the extent that the DVCS gets in the way, it's an opportunity cost.
dreyfan 5y ago
> Complexity == popularity == profit Entire node/js/ts ecosystem resonates strongly here. They reinvent the wheel, assign it a new name, thought-leaders market those inventions to every corner of the tech ecosystem, and then they add another few layers to their build chain.

strictfp 5y ago

I love git because it's fast, but the UX is trash

db48x 5y ago
Have you written your own UI yet? I recommend trying out Magit.
- throwawayboise 5y ago
  Agreed. If you have to use git, Magit is a great tool.
  - db48x 5y ago
    And if you’re implementing a git ui, it’s a great place to steal ideas from too!

posharma 5y ago

A question I'd asked a few months ago: https://news.ycombinator.com/item?id=27586432 https://news.ycombinator.com/item?id=27586432.

qntty 5y ago

Git isn't perfect but for me it was a huge improvement over SVN. The complexity was worth the ability to do stuff I never did with SVN.

strictfp 5y ago
Agreed. Perforce has much better UX and tooling than git though.
- dahart 5y ago
  P4 has better UI than git, but I’d argue the UX of command line p4, and of workflow issues like workspace mappings and connections and of course branching, are all dramatically inferior. (Caveat, I haven’t used p4 streams yet.) The one thing p4 has that I sorely miss and nothing in git-land comes close is the time-lapse view!
  - strictfp 5y ago
    I probably supressed my memories of connection issues :D I love DVCSes, hated not being able to work offline I agree with the time lapse view and p4merge. Maybe one should hack together a time lapse tool for git? :thonk:
    - dahart 5y ago
      Git gui blame tried, but lands very far short of time lapse view. Git’s underlying representation might make time lapse technically difficult. I think there might be some other UI attempts too, I just haven’t tried because I’m usually on the command line and using different OSes often.
wyoung2 5y ago
The thing is, Fossil is also a huge improvement over Subversion without losing its day-to-day simplicity.

cardosof 5y ago

git is one of those things that are so popular and accepted as the true way that questioning its use makes you look like an idiot but, in reality, many devs would benefit from a simpler version control system, one not intended to handle arguably the world's most popular source code.

deleted 5y ago
[deleted]

ankur9sri 5y ago

Online training on Git at Evision Technoserve pvt ltd Evision Technoserve is an ISO 9001:2015 certified Fast-Growing and Professionally Managed IT Consulting, Manpower Outsourcing and Staffing Recruitment Company with our operation based in Pune, Bengaluru, Chennai, Hyderabad, Kolkata, Lucknow, Delhi NCR, Noida, and Ahmedabad. Evision has successfully trained and placed 15,500+ IT Fresher's and Professionals in top IT MNCs like IBM, Wipro, Infosys, HCL Technology, TCS, Tech Mahindra and many other. We provide 100% job placement guarantee, whether a candidate is from IT Background or Non-IT background, with best Placement Record to Wipro, IBM and HCL Companies. Check Our success Story: - bit.ly/3uUGPtV Apply and Join Online: https://lnkd.in/g8s-3ZE https://lnkd.in/g8s-3ZE Mail :hr@evisions.co.in Web : www.evisions.co.in

judge2020 5y ago

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

dang 5y ago
Thanks! Macroexpanded: Why SQLite Does Not Use Git - https://news.ycombinator.com/item?id=16806114 https://news.ycombinator.com/item?id=16806114 - April 2018 (608 comments) also this bit: Why SQLite Does Not Use Git? - https://news.ycombinator.com/item?id=26112802 https://news.ycombinator.com/item?id=26112802 - Feb 2021 (1 comment)

throwawayboise 5y ago

"The mental model for Git is needlessly complex" This, in a nutshell, sums up my feelings about git.

emodendroket 5y ago
I never feel this way. When I started to use it, I only had to understand a few concepts. And when it started to get more complex, it was because the things I wished to do were more complex in the first place.
- strictfp 5y ago
  Did you ever use any other VCS?
  - emodendroket 5y ago
    I used mercurial a bit when I was starting out but I saw which way the wind was blowing and switched.
    - throwawayboise 5y ago
      Kind of similar. I went from Subversion to git, then tried mercurial. I found mercurial to be more natural, and still use it for my own projects. I have never seen it used in the workplace though.
      - bluGill 5y ago
        My workplace switched from hg to git. Hg didn't get support for all the other tools we use. The Jenkins hg maintainers were all using git when we checked, and it showed. That is but one example of a tool that didn't work with hg.
  - throwawayboise 5y ago
    Subversion, and mercurial to a lesser extent. CVS and Visual Source Safe way back in the day.

emodendroket 5y ago

Well, whatever the article says, isn't the actual reason "we have this other one we built using SQLite"?

eipipuz 5y ago
I don't get that at all. To me the answer is "we want things out of the vcs that we don't get from git nor github/gitlab." The fundamental difference is: sqlite is a cathedral, git is for bazaars. That's kind of a big deal.
ripley12 5y ago
I can’t recall where, but I think I heard Richard Hipp say that developing Fossil helps the SQLite developers dogfood SQLite. There’s certainly some synergy between the projects.
arghwhat 5y ago
It does come off as excessively NIH, with the first point even just being a client UI complaint.
- im3w1l 5y ago
  Well sqlite is more of a passion project than about doing things in the most capitalistically efficient way right? So "it makes me happy to invent things here that scratch my itches just so" is a valid reasoning.
  - rswail 5y ago
    SQLite is in every phone on the planet and the author has a company that makes money selling it to environments that require extensive validation (eg airplane software). It's not a "passion project" by any means. It's a highly developed, well engineered piece of software and there's lots of other non "passion projects" that would do well to learn from it.
    - SubjectToChange 5y ago

hn_throwaway_99 5y ago

> Git does not track historical branch names That's my biggest pet peeve on this list. Git branches are really just pointers to the HEAD of some commit history, but if you've had a bunch of merges in the past it can be very difficult to tell which commit belonged to a particular branch at some point in the past. Is there a good solution for this? Seems like it would be trivial to add a piece of metadata about which branch someone was on when a commit was made.

db48x 5y ago
Git _does_ keep track of historical branch names. It is called the reflog. For each ref there is a log of what commits it pointed to. See `git help reflog`.
- jpitz 5y ago
  The reflog is 1. garbage collected 2. local only
  - temac 5y ago
    Also the branches are indicated at their positions at the moment you call reflog, not as they were for each operation of the log.
aaaaaaaaaaab 5y ago
If you keep your history linear by using rebase only, then this becomes a non-issue.
- anonymoushn 5y ago
  This actually makes it much harder to answer the question "What happened with the branch of X name 2 years ago?"
  - clintonb 5y ago
    What is the value of that information? When I’ve looked at older commits, I either want to know about the resulting code or the context (e.g., motivations, discussions). A fixup commit, or some other intermediate commit isn’t useful.

loudthing 5y ago

"When I want to see what has been happening on SQLite, I visit the timeline and in a single screen I see a summary of the latest changes, on all branches. In a few clicks, I can drill down as much detail as I want. I can even do this from a phone. GitHub and GitLab offer nothing comparable. 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 mobile." This is a valid point. I've always wondered why it seems Github goes out of its way to hide the typical commit tree navigation that so many git clients support (Sourcetree, gitk, tortoisegit, etc).

bullfightonmars 5y ago
I have definitely felt this pain when navigating i to the past to investigate the origin and evolution of changes.
monkeybutton 5y ago
Yes! I find it odd. Maybe they just expect you to use one of those clients if that's what you want to see?
- loudthing 5y ago
  That is a good point. I know now when I visit a project on Github that I am seeing the latest version of all files, but that is only because I'm already aware of how git works.
  - bostonvaulter2 5y ago
    Depending on what the default branch in GitHub is set to you might not be viewing the "latest" version of the files. i.e. the default branch is `main` but all development happens on a long-lived `dev` branch that is only merged into `main` once a month.
  - kazinator 5y ago
    Someone who doesn't know what version control is will also just assume they are seeing the one and only version of the files.

strictfp 5y ago

"How should I change to a different branch?" asked the programmer. "Use git checkout." "And how should I create a branch?" "Use git checkout." "And how should I update the contents of a single file in my working directory, without involving branches at all?" "Use git checkout." https://stevelosh.com/blog/2013/04/git-koans/ https://stevelosh.com/blog/2013/04/git-koans/

chrisfosterelli 5y ago
In fairness, git has improved on this and separated these into `git switch` / `git restore`
- Izikiel43 5y ago
  First time I hear about this
  - krallja 5y ago
    `git status` will tell you about `git restore` if you have staged or uncommitted changes
    - Minor49er 5y ago
      `git status -s` also gives the shorthand version of this. I have it aliased to `gs` pretty much everywhere because it's really useful to me.
- strictfp 5y ago
  Yeah, but they denied the problem for the longest time, so they deserve some flak for it :)
  - chrisfosterelli 5y ago
    Probably true. IMO the crime of checkout is that the command really is `git checkout <tree> -- <path>`, which updates that local path to match that git tree, but it implicitly fills `tree` with the current branch and `path` with all files. It actually makes sense if you learn the full command but makes zero sense when you google individual common operations and then they thought "this command should also have a shorthand to create branches" I suppose

dvt 5y ago

The funny thing is that the xkcd cartoon isn't even that much of an exaggeration. Countless times, I've literally copied files from a working branch, nuked the branch, then pasted them into a new branch because I couldn't get something to merge for some stupid reason that would've taken like half a day to figure out.

throwawayboise 5y ago
Seen it happen so often when people try to get fancy with branches and merges. Yes I'm sure there's always a way to recover using the tools, but if you are not a git guru and don't have one handy, deleting and cloning is usually the more pragmatic way.
- strictfp 5y ago
  IMO conflict resolution is almost always harder than redoing the change by hand, especially while looking at the old diff and redoing it towards the new branch. Kind of ironic given how hard diff editors try to help.
  - stjohnswarts 5y ago
    When I get into a three way merge it's usually just too late in the day, so I will just save off my stuff and merge in manually :) like you said. Two things to compare against is plenty.
- cormacrelf 5y ago
  I don't see the issue. This is how people fix everything else, it is what comes naturally, and it works every time. I would much prefer it this way, than what Fossil appears to do in section 3.3 of this article, having a single copy of the database per system. mkdir ~/fossils fossil clone https://sqlite.org/src ~/fossils/sqlite.fossil mkdir ~/sqlite; cd ~/sqlite fossil open ~/fossils/sqlite.fossil
unclebucknasty 5y ago
Yeah, probably just about every dev has had to do this when first learning git. One way to measure the over-complexity of software might be: 1. How easy it is to screw up 2. How hard it is to fix things once you've screwed up. Git doesn't score well by that test IMO. Back when I first learned Git, I thought it needed an undo, at least for the local repository. Not a revert commit or partial/piecemeal undo this or that, but an "I screwed up, take me back to x point in time or snapshot" level undo.

37ef_ced3 5y ago

What I still can't believe is that the world chose git over hg. Why would you use git if you could use Mercurial instead?

TeeMassive 5y ago
- Speed - The fact that it was Linus developing it - The fact that it was released just after Git - It's pretty much like Git and evolved to be usable like Git - Git had way more advanced tooling and still does to this day
- quleap 5y ago
  > - It's pretty much like Git and evolved to be usable like Git > - Git had way more advanced tooling and still does to this day Very untrue. Mercurial has advanced concepts and features that Git cannot dream of, e.g. changeset evolution.
arantius 5y ago
For me: `git gui` and the stage. Incrementally building my commits line-by-line (often with other working directory changes I don't want) feels invaluable. Work forced me to go git->hg and it frustrates me every day.
krallja 5y ago
Basically, GitHub. GitHub would have won even if it were MercurialHub. It had a better user model of the problem to be solved than any other SaaS code forge, and it supported both open-source bazaar-style development and private enterprise. The gamification and social network features are KILLER. Also, the Mercurial developers never had the built-in fan base of Linus Torvalds. Anyone who wanted to work on Linux had to use Git, so that was another major reason to learn (and stick with) Git.
- adamrezich 5y ago
  imagine "SubversionHub" instead...

nakovet 5y ago

I used fossil in the past for my personal projects, it worked great but it had too many features for a solo developer, getting others on board of using it is hard, given git is mainstream.

throwaway984393 5y ago

GIT - the stupid content tracker "git" can mean anything, depending on your mood. - random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant. - stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang. - "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room. - "goddamn idiotic truckload of sh*t": when it breaks This is a stupid (but extremely fast) directory content manager. It doesn't do a whole lot, but what it _does_ do is track directory contents efficiently. - README, Linus Torvalds, Git source code, April 7th 2005

encryptluks2 5y ago

I thought for a moment this would be why SQLite doesn't use Git to store its data structures, which I really wish it did. Still looking for a database that acts as a virtual file system, and automatically orders data into a file tree structure.

kevin_thibedeau 5y ago
Create a table of inodes and link them together with some blob fields. There's your filesystem.

deleted 5y ago

[deleted]

bluedino 5y ago

I HATE Git. It seems like every other over-complicated, over-engineered solution to problems that should be simple. I used svn for a long time. New developers got it right away. Git is treacherous waters for 7/10 of the developers I've worked with. That said, I LOVE GitHub and gitlab. Amazing tools for collaboration. But the Git part doesn't really do it for me. I'm waiting for something better to take its place.

TeeMassive 5y ago
> It seems like every other over-complicated A DAG is one of the simplest data structure out there. What is complicated is doing merges in non-DAG CVS and let's not even talk about more "complex" operations like putting all of your commits on top of a branch, only committing a single line and, god forbids, creating branches without asking for permission. > over-engineered solution to problems that should be simple I get it that you're unfamiliar with how not nice databases schemas are. A git repository from 2005 will still work in 2021. AFAIK all other CVS will fail at this because they rely the overly complicated data representation. Git's internal representation is very simple. Filesystem snapshots referred to by content and these snapshots that can reference other snapshots to form a DAG. Just because you didn't take one hour to understand this doesn't mean it's "complicated". > That said, I LOVE GitHub and gitlab. These would not have existed if not for Git's internal representation that allows the necessary flexibility for other tools and extensions to integrate directly.
PufPufPuf 5y ago
You may like GitLess, it uses git under the hood, but has a simplified CLI: https://gitless.com/ https://gitless.com/

aynyc 5y ago

I don’t care about GIT. Perforce is my favorite. Takes an hour to understand everything to be productive.

mbfg 5y ago
does perforce still just allow one branch per repo?
nichos 5y ago
It's been about 5 years since I used Perforce, but streams were a nightmare. Sharing files down 2 "levels" of streams was such a huge pain.
dahart 5y ago
When a programmer in the games company I worked in started rallying to switch from p4 to git and got momentum, I thought it was going to be a mistake. No doubt it took a lot of learning, but eventually I came to see it was worth it. One thing that’s not well appreciated even with most people who use git is how much safety net it can provide against losing changes accidentally. I know a lot of programmers who don’t care and will blow away and re-clone a repo before learning how to use git reflog. But, in git you can recover from almost anything if you know how. P4 is pretty terrible when you want to try something multiple ways, or when you want a small team to prototype a feature without affecting everyone. I’m actively using both git and p4, and I can’t tell you how many p4 shelves I’ve got stacked up. They keep collecting because there’s nowhere else to put them, and it’s the only (crappy) way to test parallel ideas. Using git for trying out things in different ways is so nice and so fast once you get fluent with it. Of course your stance is valid and perfectly fine, you don’t have to change away from p4, but I think you might be surprised how git changes your thinking about source control. BTW I haven’t used Fossil or hg or plastic or other new source control systems, but I would assume you could replace any of them with git in my above text.

Aperocky 5y ago

good for Sqlite to simplify on their tools. But: Git has a lot of weird stuff and fluff, but that doesn't mean you have to use all of them. For instance, I try to almost never branch and use deployment flags instead - then you can always rebase and maintain an extremely simple commit history. Simple >> Complex.

rsj_hn 5y ago
I think that's fine for solo development but as soon as you have a real collaborative project -- which, supposedly, is why you need a peer-to-peer vcs, then there comes a time when dev A is working on some feature for the future, and dev B is debugging on an existing release, and now you really need branches because B's fix is going to need to be pushed out ASAP but dev A's feature is still being worked on.
- Aperocky 5y ago
  But that's what I'm describing (I do work for one of the FAANG), all feature work are either ready, or gated by feature flags. With practice, it becomes easier to divide feature work while not cause any existing impact, it also forces you to make your code logic cleanly separated. The biggest benefit of this approach imo is the drastically reduced chance of a bad feature going out because someone had worked on it for 5 months in isolation and it becomes virtually impossible to debug.
  - rsj_hn 5y ago
    Yeah, I'm familiar with feature flags, but that doesn't really solve the problem of needing well-defined releases and that these releases themselves need to be patched and possibly supported for a long period of time as determined by contract or support commitments. Also feature flags are not going to be able to cover all code changes. For example, it's hard to put code refactoring behind a feature flag. Finally, wide-spread use of feature flags as a type of in-code branch certainly seems like code-smell to me. It's fine for a while, but after 20 years you're going to have a difficult time maintaining that repo unless it's done with sufficient discipline that those feature flags are quickly removed once the feature hits production. It will also screw with your automated static analysis tooling.

boudin 5y ago

I'm far from convinced by this article. It's starts by saying that it's not comparing git and fossil but just keeps trying to throw generalities at your face how fossil is so much better and smarter than git. It sometimes compares git and all of a sudden compares github or gitlab, no reason given. So what is it about, comparing git, github or gitlab? Apparently git is to complex for developers, sorry but I have yet to see a developer not managing to work with git. Either I've always worked with geniuses or this is a non-problem.

tiagod 5y ago
The author is comparing with github/gitlab as fossil offers both VCS features, like git, but also features a Web interface with issues, wiki and forums, which you can only get with those third party products.
- boudin 5y ago
  Then the comparison would be fair if it would go through all the different options. Picking the one that is quite heavy to host like gitlab (but does way more than what fossil does by the way) for the purpose of saying that git sucks is misleading. There's options like gitea that are lightweight and super easy to host.
BoorishBears 5y ago
>Apparently git is to complex for developers, sorry but I have yet to see a developer not managing to work with git. Either I've always worked with geniuses or this is a non-problem. You must work with geniuses. No one I know has never been at the place where you just accept the tree is fucked, delete .git and paste your changes back into a fresh checkout. Granted now I understand things like git reflog so it's been many years since then, but git is as far from approachable as tooling gets...
- boudin 5y ago
  Thanks then, it means I must be managing my team right :) I've never seen a tree being broken, and needing this kind of action. Don't get me wrong, the git cli could definitely be improved, but as long as you have a clear workflow and map it to git actions it works well.

MBCook 5y ago

It’s 2021. How I wish we had moved past pointless git bashing by now. We get it. Many people don’t like it. They prefer to use $TOOL instead. It’s been 16 years. Can’t we resign this to emacs vs vi category of things we’ve largely accepted and stopped arguing about yet? I’m not mad at the article. They have preference and wrote down why they don’t use the more popular tool for when people ask. That’s fine. But I’m guessing it was posted to have the “discussion” we’re having right now (and every time got comes up). People bashing (or defending) git. And it’s exhausting. We’re half way to the age of vim. Can we let this one go too please?

NoahTheDuke 5y ago
If a tool attracts enough ire that such arguments arise frequently, then a non-zero number of people are dissatisfied and could be satisfied by other tools. That is worthy of discussion. Additionally, it is cathartic (and occasionally even productive) to complain about the warts and sharp edges of a popular tool, especially when the tool is the overwhelming the tool of choice in its domain.
richie_adler 5y ago
Your comment basically can be summarized as "Everybody stop discussing this topic that doesn't interest me!" To which I can only reply: No.
casion 5y ago
I agree that it's exhausting, however using git is even more exhausting... so the complaining and comparisons will continue.

dekhn 5y ago

"The mental model for Git is needlessly complex" that's it, right there. Why are you bothering me about a detached head?

wyoung2 5y ago
"Detached head" is Git's way of saying "I don't know how to find my children when you say something like 'git checkout abcd1234'". Fossil can do this, so you can point someone to a historical checkin and Fossil won't get lost should you later commit on top of it. Git's warning you that if you do that, you may end up with an orphaned commit.
- rezonant 5y ago
  More like "I don't know what gitref to move (*well, change) if you commit". `git checkout` isn't relative to the current ref is it?
rezonant 5y ago
Agreed on this one. It should instead let you handle this when you commit, make you reckon with what to call this new gitref. That is when I care about whether I'm connected to HEAD or not Yeah, it would make you `git branch` to give it a name, or an override option to commit it without a name
Spivak 5y ago
I think it's actually the opposite. Git's model is really really simple and pushes all the complexity onto the tooling and the user.
- patal 5y ago
  That's exactly the parent's complaint: Git's tooling and user interface is (unnecessary) complex.
sershe 5y ago
I dunno, git model always felt extremely intuitive to me... there are very few core concepts and ideas and all the complexity is layered on top of that and is easily decomposed. I feel like git concepts are very elegant while allowing a lot of complexity, like C/C++ pointers ;)

passerby1 5y ago

> Git does not provide good situational awareness > [...] > I can even do this from a phone. > [...] > GitHub and GitLab offer nothing comparable. Seems like git=(gitlab|github) for the author. I don't agree this is right, as these both are totally different products comparing to git and made with different purposes and aims. Phone access. Okay, probably we are in different culture contexts, but for me a need to use my phone to access source code (or tickets) always means things went very very wrong.

rezonant 5y ago
Maybe the wrong culture. I use GH to reference source code from my phone quite a lot. I spend half my time on the phone, and when I'm in a meeting, my phone is the obvious way to be in those meetings. Ensuring I have first class access to everything from my phone is a huge priority. The author may have a point about having better views of the source from GH/GL, but they are absolutely providing a decent experience for it already.

liveoneggs 5y ago

dr hipp also uses his own editor so that might be a clue

m0zg 5y ago

Does Fossil support some sort of a backend for large/binary files? This, more than anything else, is my gripe with Git. LFS is a pain in the ass, and it sometimes breaks, too. I want something that's baked in and doesn't need to be enabled on the side.

wyoung2 5y ago
I daresay there is no DVCS appropriate for many large files that change. You want something more like a classic non-distributed VCS so you're not cloning the entire history of huge files. Worst is when they're data-compressed so you're not only pulling all historical versions but also most every byte of each historical version. I wrote an article for the Fossil docs covering this, but the core experiment can be run against any VCS: https://fossil-scm.org/home/doc/trunk/www/image-format-vs-repo-size.md https://fossil-scm.org/home/doc/trunk/www/image-format-vs-re...

sieve 5y ago

I used Fossil for a bit a few years ago. A nice, self-contained tool that stores everything in a single file that can be easily backed up. Had to give up on it because using two different revision control systems became inconvenient after a while. But I regret the loss of Mercurial, after having used it for a decade or so, more than that of Fossil. It always bothered me how a user-hostile piece of software like git rapidly took over the world. But then I remembered sh and bash and realized that someone thought that these softwares should be designed the way they were decades after Pascal and Lisp and hundreds of other sensible languages came into being, and they took over the world too.

crossroadsguy 5y ago
> It always bothered me how a user-hostile piece of software like git rapidly took over the world. After almost 7 years on git I have given up on getting git and I stick to what that XKCD comic said - remember some commands and just keep syncing. It felt one has to make it into a masochistic exercise to understand it. I feel similar about Markdown (though I won't call it user hostile). Because there were and there are better and accessible/uncomplicated alternatives.
- aidenn0 5y ago
  > I feel similar about Markdown (though I won't call it user hostile). Because there were and there are better and accessible/uncomplicated alternatives. I don't know; all of the lightweight markup formats are a mess. AsciiDoc/AsciiDoctor is almost great but they seem to have completely borked escaping of inline punctutation[1] Restructured Text is very "meh" but is better than markdown because directives at least make it more sanely extensible. The downside is it's missing lots of features in its core becase "you can just use a directive" Markdown was actually pretty good for its original purpose (write html with fewer html tags), but completely falls down for its current common use case (untrusted user input, where you won't allow the user to fallback on html). 1: https://github.com/asciidoctor/asciidoctor/issues/901 https://github.com/asciidoctor/asciidoctor/issues/901
- ajkjk 5y ago
  I'm eh about Git but .. I love markdown. Sure it has some rough edges but it is such a good idea, and I'm so glad it caught on everywhere.

gravypod 5y ago

I recently (last few months) upstreamed changes to a project maintained by the SQLite owners. The process was fairly straight forward but the difficulty of creating the patch was much higher. I needed to learn a bunch of things that I didn't already know. I did this because I didn't want to maintain the divergence from our code (and wanted a more general fix which the devs could implement better than I could) so I put up with the pain. I don't think I'd do this at home if I was just bored. Maybe that makes me lazy (which I am) or a bad developer. It is a barrier though as, like it or not, we all know git.

deleted 5y ago
[deleted]

dlp211 5y ago

The best source control system I have used to date is Google's G4 with hg (mercurial) bindings, I think they called it Fig if memory serves me. I'm not sure if there is any product that is similar to it outside of Google.

arxanas 5y ago
You might be interested in my project https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless, which is intended to replicate such a workflow.

dikei 5y ago

I start out with Hg then move to Git because Hg felt too slow for my need at the time. Ironically, Google & Facebook choose Hg over Git because they can make Hg run much faster than Git at their scale: While both vanilla Git and Hg are too slow for their huge monorepo, they basically replaced most of the core of Hg with their own implementation to speed it up for internal use, keeping only the Hg cli.

ryanisnan 5y ago

I sure as hell don't want to learn another VCS, unless it's just better, and has any chance of becoming widely adopted. I think the short list of git grievances here are outweighed by the costs of not using git.

zzo38computer 5y ago

I don't like git. Fossil is good, but it isn't customizable enough. For example, I would prefer to implement a web interface without CSS and JavaScripts (and perhaps also to be able to expose with gopher and gemini too, and possibly also other protocols), and I would prefer to ensure all functions are available by command-line interface, and I would prefer to deal with and write raw artifacts directly (rather than only use the built-in commands) (maybe it is possible to do this with the sync protocol, but I haven't tried this).

oxplot 5y ago

Anyone using patch SCMs like pijul?

euroderf 5y ago
Installation on macOS is still broken, with no signs of progress. Quite discouraging.

beermonster 5y ago

"GitHub and GitLab offer nothing comparable. " This is true. But this is a criticism of Git**b not git.

clhodapp 5y ago

It seems strange to talk about reduced distraction and saved brain cycles as a justification for writing and maintaining an entire VCS (with a rich UI) and project management tooling

rkeene2 5y ago

What I miss from Fossil, some of which I've brought up on the Fossil Forum are: 1. Pull Requests ( https://fossil-scm.org/forum/forumpost/01d77b7259ea0b00?t=h https://fossil-scm.org/forum/forumpost/01d77b7259ea0b00?t=h ) 2. Code Reviews -- I spend atleast half my time doing code reviews these days and the tools just aren't there for Fossil, GitHub.com has good tools 3. "git add -p" -- I try to make commits a logical change, often figuring out what I'm doing involves making a set of physical transforms and then I like to commit them as logical transforms

krylon 5y ago

One thing I came to like very much about Fossil is that on Windows, the whole thing is just a single executable file, just drop it anywhere in your %PATH%, and you're good to go. The builtin web interface is very nice, too. I have since had to switch to git at work, and after discovering magit I don't think I'd want to go back. But Fossil has been very pleasant to use.

zoomablemind 5y ago

I always thought that Git and Fossil address different concerns of the respective underlying projects (Linux kernel work and SQLite corresp.) It's clear that both projects need a revision control to manage changes, yet the requirements seem to diverge. Linux kernel is a massive project with a lot of involved contributors. While SQLite is a tighter team, majority of commits are reasonably by 'drh'. And the codebase itself, of course, is not on the same span scale. As such, my understanding is that Git needed to allow slicing and dicing of various sources of patches so that they could be properly sequenced, tested, reviewed, and integrated (thus index/staging and rebase). On the other hand, SQLite needed an immutable history as part of its exhaustive approach to testing and documentation, and Fossil could also be an excellent testing ground for SQLite too ... and a more cohesive CLI (thus the repo-db, security model, persistent branch names, non-destructive delete etc.). So, just as great Masters do, they created the right tools for their project. AND they shared their tools with the rest of the world, that is us all, for which we are grateful indeed. Now, is Git or Fossil a right tool for your project depends on your needs and choices. Not all projects need the slicing and dicing of the patches, just as not all projects require immutability of the history. If anything, the current reality is that Git became a sort of C of the revision control, just it's possible to have a practical use of it without the need to learn it thoroughly. The requirement to rebase your changes for a PR is rather imposed by project conventions, not the tool. I like to think about Git as being a Swiss knife to carve the wooden blocks of patches, so they fit together. Meanwhile, Fossil is a kind of a handy set of chisels to etch the revisions into the stone tablets of the project.

Pokepokalypse 5y ago

actual timestamps (instead of "relative time"). . . what a concept.