What comes after Git
matt-rickard.com
matt-rickard.com
Even a simple merge/rebase leaves one confused. Which should I use? What is incoming? Why does incoming change as you progress? I didn't change anything (on purpose) but Git won't let me change branches. What the hell does stashing do? How do I just unfuck what I did and go back to a branch? These are rather common use cases, and today people still just nuke a directory because they can't figure out the arcane arts. I am one of those people, at times. Because it's faster to do so than read heaps of manpages for a situation I may never hit again.
Git might have awesome tech underneath, I really don't know or care. But someone needs to really spend time in a typical dev's shoes to make it nicer to use.
i dont know why mercurial doesn't get more love.
Github really is git's best PR.
From a developer stand point the experience was better but all the tooling and integrations are git based so we switched.
Actually, wait. hg up doesn't require network access. Maybe you're thinking of hg pull -u or svn up
Don't get me wrong I appreciate mercurial devs did a tremendous work to hide DVCS under SVN-like ("simple" hah) interface. But every non-standard thing requires manual reading.
So it's like `git checkout` and doesn't cover all breakage cases.
My personal reasons for liking mercurial is some pretty amazing tooling (hg absorb, hg fa --deleted, revsets/filesets) combined with a friendly commandline with fairly sensible defaults.
I'm not saying it can't be better - clearly it can.
Just pointing out that one person spending a little time unfucking a branch is massively superior to everyone not being able to work because that same person fucked up everyone's branches.
There are also very few use cases that require its complex distributive model.
At least, that's how it went for me. It seemed horribly complicated, but once I started using it, it was no issue.
From experience, this is just straight up wrong. I came from an SVN enviornment which was all GUI tools.
Git's learning curve was steep but extremely short. Once you know what is happening, even those crazy states you can find yourself in really are not that hard.
I think we're saying the same thing. Once you know how Git works, it's easy. But can you figure out "how Git works" by using a handful of commands like git add, git commit and git push?
Once you can picture what's happening, absolutely. I can think of some other cases that require a lookup later like one I had to lookup after: 'rebase v merge' for example, after a 5 min documentation read, and with a picture in your head of how your state is it makes sense.
You're right if you're looking for 'how git works under the hood' that's a bit different. I might have misunderstood your sentiment.
The other thing is, like you say, git itself is a terrible way to learn these concepts. A command line interface is great for expressing operations, but the state, before and after, is basically invisible. I think this might be especially hard for more visual people. When I was learning data structures drawing them out and "seeing" the structure was vitally important and I know it's not just me because computer science books are filled with pictures.
I really want there to be a GUI I can recommend people to use for git, but I'm not aware of a good one. I use magit which helps a lot, but I can't recommend that to most people. All the other GUIs I've seen are just about doing command line stuff with a mouse.
Everywhere it'd bee seen as a flaw from ux standpoint, but git gets a "pass"
Imagine having to read excel's or windows code in order to use it consciously, lol.
>You can, however, learn Git by reading about its architecture: blobs, trees, commits, pointers to commits (refs), and index (staging area where new commits are prepared).
Impl details of e.g dbs, std libs, runtimes, compilers, etc are for advanced/expert cases, not for slighly above normal
It's like how for a word processor the domain is text, et. al., or for e.g. Inkscape the domain is SVG.
Git has two levels, called "plumbing" and "porcelain" (I think.)
The "plumbing" (blobs, trees, commits, refs, and index) is elegant and easy to understand and use.
The "porcelain" is where everybody gets bogged down. I'll omit my own opinion (low) and just say that most of the problems people have with git seem to be related to trying to do complicated things with the crummy UX porcelain.
And that seems to be because they learned the porcelain but not the plumbing.
So what you're hearing is people advising people to learn the plumbing (as a side effect the porcelain becomes less unbearable.) In fact, if you know the plumbing you can write your own porcelain, and it's not hard and the code is brief because git is actually elegant and easy to understand and use.
You have to have some mental model of what the program is doing. With SVN it's basically "the server has the latest version, you can download or update that". With git it's "You have commits (snapshots of the whole state of your directory) which are addressable by the hash of that commit and refer back to previous commits. Also, here's a bunch of tools to manipulate and share that". The gp list of terms you should know is pretty close to just covering that.
For me I like git because it doesn't guess what I want to do, it give me tools to do what I want and then does what I tell it.
I've seen teams evaluate multiple revision systems before starting projects and each one has decided on Mercurial based on its technical merits.
I'll take it on trust that git is a perfect solution for linux kernel development, but the number of teams who work the same way as them is a rounding error from zero. I see people on here complaining about cargo-culting from the cool kids (k8s, spotify's team structures, etc., ect.), but I see git as exactly the same.
I don't want to have to spend time understanding how my editor handles lines in memory in order to use it, why should I have to spend time understanding how my revision control system treats revisions?
Tech is hard enough without having to sink time in to unnecessarily complicated tools that can bite you in the bum really hard.
The big advantage of git is github and co, not git itself. By switching and using mercurial you lose all of the advantages of github too.
The irony is I use git for all my projects, too, due to the network effect. It's vastly easier to go with the flow rather than swim against the tide. But every time I have to wrestle with un-fucking git's state I find myself considering my life choices and how I got there :(
cough Fossil cough
I think you can pay as low as 2 dollars a month to use SourceHut.
I think this explains a lot of the initial popularity of git and github. Wanting to be like the cool kids, and git knowledge being seen as somehow "elite" back then.
But given that initial popularity, it seems likely to me that network effects mostly explain its growth in usage from there. Convergence on a single revision control tool/site/representation/api/etc is probably inevitable, in the same way that there is basically a single social network (ie Facebook).
Yeah, but saying that here a few years ago got you lynched.
It's a tool aimed at technical people, which at the time it was launched offered features and technical possibilities which was unmatched by most other popular source-control systems at the time.
I remember going from Microsoft's Team Foundation Version Control to Git, and everything just felt miles more flexible and capable.
Especially branching was enormously limited with Microsoft's offer, while Git literally allowed me to merge anything I wanted, across any base, and usually end up where I wanted to be.
In short: Git solved real world problems in a way which more than compensated for its somewhat clunky UX.
Similarly, for most things you don't ever have to touch Git on the command line. There are tons of great interfaces overlaying Git - e.g. Sublime Merge, which can visualize what you're doing, and makes Git significantly "nicer to use". You can still descend into the command line, but for whatever you've described above, you don't have to, and you don't have read manpages for common use cases.
Your problem with Git is not an insurmountable issue - it's about finding the right tool to use Git with, and which is the way moving forward anyway. Consider ffmpeg. It's extremely powerful, and about as arcane as git, and you'd needs just as many manpages or Google searches to understand it. Yet most people just use software that overlays all the magical conversions that ffmpeg enables - and no one has to see or blame ffmpeg per se. The scenario should be similar with Git, I hazard.
Did you see what came before? Git isn't popular because of its UI, it's popular despite its UI. It's considered worth it because of its distributed model and speed.
Having said that, I've used magit pretty much from the start and can't understand people who don't switch to a better UI eventually. I don't think a command line UI works well for it at all.
You obviously have not used the alternatives that were available before Git. After CVS and Subversion, Git was just a breeze of fresh air. But UX still has a lot of room for improvement.
For very large projects (eg Linux-scale or Windows-scale) I can totally see why it is the best versioning solution. But most software isn't like that: it's relatively small teams maintaining a legacy codebase and making fairly incremental enhancements. I struggle with what git brings to that vs the cognitive overhead of using it.
I've recently migrated a moderately large codebase from TFS to GitHub. A large part of what drove that was co-workers who were reluctant to use TFS - I suspect that they found it old-fashioned, and that kind of bothers me, even though git is clearly the future and TFS clearly isn't. I like diversity of tools, and tools that don't force me to think too hard about things that should be easy. The knowledge that git could turn into a foot-gun just when I most need to get things done, doesn't help.
<edit> After some consideration, I think what I'd like is a tool that gives me a simple SVN-style UX over a real git repo, with the option to drop down into actual git of necessary, and so that colleagues can use only git if they prefer. Github desktop partly achieves this, as does Visual Studio's git integration, but it's not quite what I want.</edit>
(Not a git hater. I've had a github account for over a decade and choose to use it a lot for personal projects. But mostly just simple, sequential check-ins over time.)
I won’t defend the git porcelain because it is incredibly baroque, but because it’s backed by a robust a simple data model underneath I see that as more of a rote memorization challenge than a fundamental flaw. This is far preferable to svn which conflates repos, directories, branches and tags, resulting in the possibility of nonsensical operations and unresolvable merge situations.
> Even a simple merge/rebase leaves one confused. Which should I use?
Merge merges two branches. You fork a branch off master, work on stuff until it's done, then merge it back into master. After that the branch can go away.
Rebase is for rewriting history. To get rid of the 20 embarrassing commits where you tweaked stuff at random hoping to get it to work, or to redo a bunch of changes in a more coherent and easier to review way. It can be used to transplant work from one branch to another. It also can be used to keep up with the changes in the branch you forked off from.
> What is incoming? Why does incoming change as you progress?
Not quite sure what you mean, could you provide more details?
> I didn't change anything (on purpose) but Git won't let me change branches.
Probably because changing branches would lose your current work. It can happen either mid-rebase, or because you modified a file that would be overwritten by a branch change.
> How do I just unfuck what I did and go back to a branch?
You can abort a rebase with `git rebase --abort`. This loses progress.
> Git might have awesome tech underneath, I really don't know or care. But someone needs to really spend time in a typical dev's shoes to make it nicer to use.
I agree the UI leaves a lot to be desired. But the main thing is that you need to understand what it is that you want to accomplish first, especially in the merge/rebase question.
It's worth going through old HN comment sections that have flamewars of SVN v git (or cvs vs hg or whatever) from 2006-2012 or so. The dvcs systems won because they changed a bad paradigm to one that's much much better - literally the way you think about version control these days is a radical departure from the previous way it was done. Merges are much much nicer in git then they ever were in those old systems - I've never spent more than an hour dealing with the results of git issues, but I've lost literal weeks to a single svn mishap.
Why did git win over other dvcs systems?
2 main reasons I see:
1. Linux uses it - literally, that means its the "cool one"
2. Linux uses it - and that means the people developing it work similar to the kernel, they are willing to try a lot of different ways to acheive the task resulting in both some amazing cool stuff and a lot of cruft left hanging out for various compatability and "accidentally super important structurally" reasons.
Being merely better isn't enough; see mercurial.
The use case actually has to be important to people in real life, too, not just be something that sounds cool or people might say is important but they don't actually exert any effort towards implementing; see fossil.
The problem is that it's not clear what that will be. It wasn't hard to tell branch merging was a huge weak spot of SVN even if you were close enough to it to not see the forest for the trees. What is git's weak spot? People might jump up to say "interface!" but the reality is, no, it's not; again see mercurial. Talk is cheap and complaints are cheaper but the reality is the community is not switching en masse because of that. Large binary files is certainly a weak spot and I understand there are some commercial solutions for that that edge out git, but that's not going to edge out git in general because the pain isn't enough for most projects, and while git-lfs isn't necessarily the slickest solution ever it's good enough for programming projects. Submodules are awful but it's not clear to me that there is enough pain there to make people switch even if you made that slick as can be. (Plus, if something did start eating git's lunch because of that, there are improvements git can make that would blunt the impact. Git's fundamental model means submodules are always going to be weird but it doesn't have to be as bad as it is. I think backwards compatibility prevents git from fixing the problems but if something was really a threat it could overcome that and they'd be improved.)
I expect to still be using git for many many years yet.
I strongly feel if someone could match the merging ability of Git with the ease of simple, well worded commands, it could win. And it doesn't even have to be a Git replacement, but a better frontend. Kind of how yay is to pacman. Or how most use something like Handbrake instead of ffmpeg.
In a lot of ways, it reminds me of Python and Perl. Perl was definitely more powerful as a language, but Python felt like natural writing in pseudocode. Enthusiasts rightly point to the power of inbuilt regex, but like Git, few actually could harness it well enough to make that unreadability worth it.
But we have that, and not only didn't it win, it shows no sign of winning. Mercurial isn't even growing in apparent mindshare.
"Easier" and "technically sound" is by observation, not by a long line of strained theorizing, not enough. Theories must take this fact into account or be useless in explaining the real world.
If you're going to collaborate in a decentralized way you ultimately need an accepted mainline source of truth.
From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments.
"Everyone" uses GitHub as a single source of truth, but I believe that git itself was not designed with this in mind. GitHub users use git as centralised version control with "local commits, rebases or whatever".
> Any time you create a branch locally, without needing to contact the central server you are using distributed vcs. Same when you do local commits, or rebases or whatever.
I think that it is possible to add local branches and commits to centralised version control. Will it make it decentralised? I don't think so.
> From the point of view of someone stuck on subversion, all of that is freaking magic. This is what I mean about "radical departure". By analogy, there's people who think of horses as slower cars and say things like "why can't we just start using horses again" without ever considering the horse issues that are no longer relevant like: having to feed them every day, having to not ride them too long without resting the horse, what do to with all the poop, and so on because cars don't even have analogous impediments.
It's not a topic of "horses vs cars" you know. Not even close. This analogy is a plain trolling IMO.
Well, you think wrong, because it's not. Centralized change control will contact the central server for every change.
If you can make local commits, it's decentralized source control. Prove me wrong: show in the SVN or p4 or CVS documentation where you can create local branches or commits while the central server isn't reachable over the network
But using GitHub as a single source of truth for git repositories makes git mostly centralised. Think of it as of SVN with local commits and a central repository on GitHub (with its UI). And with awkward git’s CLI.
I don’t think that SVN, p4 or CVS have support for local commits. What I want to say is that local commits could be added into centralised version control systems. Come on, SVN has a local working copy. Won’t it handle local commits?
The fact that you keep coming back to github to "prove" it's somehow centralized at the vcs level is clearly you just doing some contrarian trolling.
I assume the most trivial case when say I contribute to e.g. MS documentation, which source is now available exclusively on GitHub. Can I say that this MS docs repository is a canonical copy?
I think that the most common daily use workflows with git and GitHub are absolutely centralised regardless of the decentralised nature of git.
* I have a local git repository, its local version history and all the great features this provides. But I have to push to GitHub, you know. Can I somehow publish my changes if GitHub is down? So how is this different from centralised version control?
* GitHib provides extra features besides version control. It has a bug tracker, wiki, whatever. I'm tied to all these features, and they are not decentralised at all. I understand that this analogy is silly, but GitHub is a well done SourceForge with Git. But it's still SourceForge, and it's centralised.
When I use git with GitHub, I usually only clone, commit and push and check my project's issue tracker. All these actions except commit require access to GitHub. So I think that the workflow is absolutely centralised even if git is decentralised by design and has local version history.
I think that's what @evouga meant in his comment above when he said > But almost nobody actually uses git the way it was originally intended, eg. as decentralized version control? Instead there’s a canonical master repository (on GitHub) everyone pulls from/pushes to.
The company I work for has internal forks/clones of many projects hosted on GitHub.
I routinely interact with at least four different clones of a project: the upstream one on GitHub; the local one on my machine; my personal clone on GitHub for upstream contributions; and the company-internal clone hosted on some company-internal server.
So yes, we are using git in a decentralized fashion.
Linus Torvalds developed it after the spat with Bitkeeper, which was the main public proprietary dvcs.
In a short time it became the most popular one. Which means all these people must be wrong otherwise.
OpenBSD can use CVS cause they have a small, relatively static team.
And at that point, even the use of dvcs was in question, so you could use svn on google's forge, or sourceforge. Launchpad had bzr support too.
It wasn't clear github was going to win until it was clear that git was going to win.
Just let some junior developers to some rebases and squashes, and see what happens.
Definitely the best way to learn.
Makes life a lot easier
Mercurial is nice if you are a max middle-level and do not use anything besides checkout/commit/push. Any non-trivial stuff requires manual reading (the same as for git)
I know you have no time to know your tool. But I don't see any hurdles to allocate one evening and read https://jwiegley.github.io/git-from-the-bottom-up/. It gives a model that you can apply to other distributed VCS and may be make you a better engineer.
It helps that Mercurial has a really nice cross platform GUI: TortoiseHg. Version control is one of those things that really benefits from a GUI because you're manipulating small elements complex object - the commit graph. Using the command line is bit like using ed to edit a text file (i.e. with commands like "insert xyz between lines 12 and 13").
1. I want some changes in my repo to be persistent whenever I switch to a new branch, pull, or merge a remote.
2. They should not be shown in git status.
3. They should not be pushed.
From skimming the front page I haven't found whether something like this is supported.
I see that with stgit I can `stg pop` my "persistent changes" before pushing to the remote and then apply it again with `stg push` but that requires that I use stg commands to create patches instead of `git commit`.
I did, plus MS SourceSafe, Team Foundation Source Control and Bazaar.
I don't see the problem with SVN and Mercurial. If you have merge conflicts, no tool is going to solve that.
If you love git so much, try to do a squash merge to the main, then do some other changes in your branch, and try to merge again. Have fun solving all the merge conflicts that actually shouldn't be there.
Like I said, SVN and Mercurial are fine too. I don't see any reason why git would magically solve some merge conflict that SVN or Mercurial is not able to.
If you want Git to continue keeping track of your commits, don’t squash-merge them.
Squash merging loses valuable history in general and use of it is a sign that commits on source branches are being made carelessly.
(That said, if I had to do this, I’d rebase off of the squash before merging again and have no problems.)
For this situation, at the end just do:
git rebase -i main
And delete all of the commits that you included in your squashed commit. If you want to preserve your detailed history you can create a new branch for the rebase like so:
git checkout -b mybranch-rebase && git rebase -i main
Why I should want to do it? It feels unnatural. What problem you are trying to solve by this workflow?
I'm very curious how your favorite VCS handle this case.
>Even a simple merge/rebase leaves one confused.
I've never had this problem. Git always works exactly as its designed for me.
Though even knowing, Mercurial is still a better experience, but not by enough.
I'd love to get more context to that statement to understand it better because as it is, it sounds as such an arbitrary statement that undermines the credibility of all the content below.
Kubernetes didn't brought open-source collaboration to a new level. No matter how relevant Kubernetes is today, it's just a drop in the huge ocean of OSS. Maybe level in this context refers to 'gitops' which many of us where doing years before the term was coined and without K8s involved. Or perhaps the author refers to the fact that most gitops K8s frameworks will work via polling which is a fundamental scalability flaw.
One of the cool things to come out of it was Zuul, which is a merge queue system similar to Bors and friends.
Also GitHub is the defacto monorepo? Since when you can fork/clone code in a monorepo? The whole point of monorepo is to avoid that!
It references the effort and money wasted by people that wanted to build cloud providers despite not being in the business of being a cloud provider.
Kubernetes has it's roots in Omega which was a research project to explore improvements to Borg.
It was created/released as a direct response to increasing lock-in of AWS and Azure PaaS like services that were becoming an existential threat to GCP ever gaining any marketshare.
Unlike OpenStack it did actually manage to mostly achieve it's goal of preventing lock-in by creating a standardized API in which all distributions/managed-providers need to provide and actually certifying that they do. OpenStack failed in this regard because it was overrun by vendor interests too quickly and suffered poor governance. Additionally the leading vendors of the time simply ignored it because none of them offered a compatible API layer and none of them cared about any of the upstarts that did. Also it turned out very few people wanted to build their own IaaS if it would be incompatible with AWS and bursting would be awkward.
k8s successfully learnt from these mistakes.
So it's contributions are two-fold.
1) Single-handedly forced the other 2 major vendors to implement a standard API.
2) Created an infrastructure OSS ecosystem above this API layer that broadly has been successful with enterprise interests while abiding by the governance model set out by core k8s.
These alone make it a very successful project even if you disagree with the technical implementation/merits.
> 1) Single-handedly forced the other 2 major vendors to implement a standard API.
I (and I'm sure you too, you seem intelligent) would be surprised if say EKS is anywhere close to ECS usage. k8s is considered so complex/poor Amazon sell ECS-on-prem.
It's the epitome of resume driven development - nobody uses k8s for any other reason except to say they use k8s.
Same as most people, and as previously mentioned: I pay pay a cloud provider, unless my business is being a cloud provider.
Right now I'd use Pulumi, years ago I'd use Terraform, or the AWS API - I part of the first node AWS API client and part of App Engine before k8s existed. k8s didn't invent infra as code or auto provisioning capacity. The fact that it's advocates act like it did is why k8s is a DevOps meme.
> your instances are eventually going to scale down to 0 and not wake up if no HTTP requests are incoming
That's a good thing. I think you don't understand Serverless.
I stated several things it contributed -even if you think it's too complex-.
If you don't understand why people use k8s you don't understand the problems it solves. Especially if you think ECS is a substitute.
IMO the way Kubernetes is built and maintained serves as a model for sustainable, enterprise-grade open source.
In what way does the cncf do this that the Apache foundation does not?
What's the lesson, that you can learn anything eventually, or that familiarity means you will lose the ability to accurately evaluate something?
No, I think most people that use it are fine with it. But those are usually not the ones you hear :)
It seems to me that, as it should be, every professional SW dev has managed to work with git at some point in their life, then. Because git is simply what you will most likely use nowadays.
But still, everyone remembers how hard it was to start out. Which is why, I think, these blog posts about git are so popular all the time.
I sure don't. I learned the commands I needed (branch, checkout, clone, push, pull and commit) and didn't step out of those bounds until much later. It's really no different than learning any other skill or platform. Nobody starts out a master, but that's no excuse to never start.
I had enough SVN merging issues so when git appeared I forced transition to git in a 3 month-period including writing Git-plugin for Hudson (Jenkins).
The reset operations are also very inconvenient, due to the mix of: different types of reset (soft/hard); overlapping with the checkout command; different states of the files.
Pushing is also overloaded, due to handling both branches and tags (this is probably due to the fact that both have refs).
There are strange warts (e.g. adding with --patch doesn't include files not in the index; displaying the content a given stash entry requires typing the whole - unnecessarily complex - entry name), which I don't doubt make sense technically, but from a user perspective, they're odd.
There's probably a lot of stuff that one can find, depending on how wide their usage is. For example, I actually didn't realize how convenient patched (--patch) unstaging would be, since I typically perform a reset, then add (--patch) again.
I've personally never got past the feeeling that, not frequently but still with some frequence, git operations have a byzantine UX.
edit: find the merge commit of a given commit is something also very missed; it requires a non-trivial alias.
I guess that's why they split git checkout into git switch and git restore
Someone could probably make an argument that commands should be overloaded even more - clone, pull, and checkout could be merged for most of their common operations - as an example. Note: I am not necessarily for this but I'm not necessarily against it either.
agree --patch is weird.
It does (switch/restore) and I do.
git sync --from <local or remote ref, or .> --target <local or remote ref, or .>
The problematic kind of overloading are like how
git push origin master
git push origin master:master
git push origin :master
Something to be aware of when training junior devs. Do them a favour and learn switch/restore first!
So... there was 9+ years of learning certain commands/styles and... switch/restore weren't part of that.
And I've mostly switched to GUIs for day to day stuff - the Tower Mac client and sometimes the JetBrains git tools. They might even now be using 'switch' and 'restore' for some basic operations behind the scenes.
But I do in general agree that the cli leaves much to be desired. I really have to give credit to magit for making a git ui that is simultaneously easy to use, powerful, and has actually made me more proficient at using the regular cli (the commands that underlie the operations are echoed so whenever I do something new I take a peek at how it's done).
1. force push both the branch and the tags
2. force push only the tags
It's very ambiguous - both answers make sense. And that's a big UX problem!
I've been using git since 2008. I just learned a few weeks ago that I had the opposite understanding of what --theirs and --ours does on git-checkout during a rebase operation. (briefly: --ours is the branch you are rebasing onto, --theirs is the changes from the branch with the changes you are repeatedly cherry-picking into the new branch. see this answer for more detail [0])
I shudder to think how much I've screwed things up over my career as a result...
I don't even know how to check for mistakes here with my current employer (god speed to the code I wrote at my previous jobs). Unlike a merge, a rebase leaves no trace except in the reflog :(
Reminds me of the slightly facetious anecdote that UI/UX has actually already been perfected so the complaints and problems you hear are just UI/UX people making work for themselves.
I was a big proponent of Mercurial for a long time because I thought (and still think) that the UI and defaults were vastly superior for most projects which don't have the needs and workflow of the Linux kernel. I gave up a few years ago when it became clear that git was VHS to Hg's Betamax.
This way new users will find it better to learn and people familiar with it don't need to change it.
There is also `git branch --create`, although that doesn't switch you.
Thanks for the commands. They are useful.
I think for this reason there's a lot less pushback on its bad UX than there would be for any other program. It would render knowledge of its arcane guts less...special. The juniors will be forced to deal.
It makes me wonder though, if needlessly arcane knowledge is and always was a part of other apprentice relationships.
I see a lot of complaints about it, and agree that for all the porcelain, you do have to become familiar with the plumbing to solve issues.
But noones shown me a good alternate ux story, just different porcelain/fittings. I still have to reach under the sink because said new porcelain didn't stop/avoid a case sensitivity clash, or it barfed on a merge and left the repo still to merge.
Mercurial and Git have, for most purposes, functionally identical capabilities. Atlassian at one point allowed you to checkout a project as either a git or a mercurial repo painlessly.
Mercurial's porcelain makes sense: the command is exactly what you think it is, usually without any funky modifying flags. If there are flags, they're often obvious, and if they're not, hg help <command> will clear that right up.
Contrast to git, which is a mishmash of commands and esoteric flags, and the help isn't even inlined.
The underlying concepts are easy enough, but how you access them requires memorization of arbitrary command sets that are inconsistent and overloaded.
Fix the porcelain and IMO you fix most of the problems with Git.
I didn't know how to use a welder just by looking at it, but the UX is fine once you know the concepts behind welding.
I honestly can't see how git could be easier given the requirments of the tool. If you want to reduce its capabilities because it's too hard then go ahead, but please fork it or make something new instead of ruining a perfectly good developer tool.
I do find the division between git seems to be really concise. Either people don't get what the fuss is about or they think git is just the worst.
If you're curious how it can be done (IMO), take a look at https://github.com/martinvonz/jj. It's its own VCS but also compatible with Git so individual developers on a team can migrate to it.
In terms of the metaphors for the actual commands, I would agree. Reset and checkout basically make no sense for what they're actually used for. Switch makes things a bit better, but yeah, it would be nice if the entire Git CLI could be redesigned from scratch.
I sure wouldn't call that a _bad_ UX. As with any tool you have to adjust to the tool or make your own unless by some miracle someone shares your particular idiosyncrasies.
>"modifying tool makes it different from your co-workers tool"
Yes, but that is a big plus instead of a minus. If your co-workers asks how to do something you can just give them the content of the alias. I also alias `git` as `g` in my terminal. Is that going to cause problems for my co-workers? No.
Unless you are training a complete-fresh-out-of-school-junior the "new guy" should already know how git works and in either case that sounds like homework for them more than anything else.
Every tool has its modus operandi, incl. but not limited to every programming language. Extending our understanding is hardly a bad thing.
Git proposes a model for handling stuff, and I prefer it very much.
And yes, the UX is fine.
Perhaps it's what you want something easier than, but I have `uncommit` aliased to `reset HEAD^`, and use it often as `git uncommit -p` (then amend, then the 'uncommitted' changes are unstaged ready to go in a different commit if they were wanted just elsewhere, or removed if not).
Same here. Have been using git for over 10 years now though, so this might be an "experts view" kind of thing.
A decade of near daily use of it, as the 'git guy' on most teams I'm in, and I'm still spending time searching how to do specific things. To use a UX term, there's very few affordances telling me what I should expect, guiding my intuition.
Imagine a VCS where it was obvious and easy to figure out how to do anything that is possible. Along with all the power that git brings today.
I want a successor to git that provides as much or more power but with the intuitive usability.
Is that so much to ask? (I joke)
(I also believe the same thing about SQL and sets).
This distinction makes a difference in some cases, there are other VCSs that store diffs as a fundamental property.
About your naming suggestion: I'm not saying you're wrong, but consider that git is used by a very wide audience, and even a lot of the programmer crowd isn't familiar with the graph theory terms you're using.
So "branch", "tip" etc. is by no means perfect, but I think it's probably better.
(Maybe you're right and I'm being a bit ivory tower here).
So, I think it's an interesting thought experiment, but practically speaking a non-starter.
You'd never be able to fully migrate over, instead it would be another case of that xkcd about N standards.
A concrete example: Accidentally pushing a merge you didn't want to push and now you're stuck staring git-revert(1) which has the sentence below, scratching your head like "uh, what's a parent number?"
-m parent-number, --mainline parent-number
Usually you cannot revert a merge because you do
not know which side of the merge should be
considered the mainline. This option specifies
the parent number (starting from 1) of the
mainline and allows revert to reverse the change
relative to the specified parent.
But you still can't find information about what a "parent number" is. It turns out, the parent number is the order they show up in within 'git show HASH'. Combining that clue with Linus Torvalds email above may let you undo the merge, if you can make sense of his Feynman diagrams. Maybe.
> I do wish I had an easier way to split up a commit that accidentally included several unrelated changes though.
IMHO this one of the cases when GUI is better. I use `tig`.
1. Make a new commit to revert what you to come last
2. Make a new commit to revert what you want to come first
3. Make a new commit to restore/revert line 2 above
4. Make a new commit to restore/revert line 1 above
5. Squash original into lines 1 & 2 above
Alternatively you can use interactive rebase, 1. set edit on the commit you want to split
2. When the rebase stops, `git reset --soft HEAD~1` (I think)
3. `git add` and commit as necessary then follow up with git rebase --continue
Actually I think you might be misunderstanding what people think is bad. Nobody dislikes the model of Git. It's great. That's partly why it's so popular.
It's the CLI and terminology that are the issue. Some things are very badly named (e.g. the "index"; anyone sane would call that the "draft") and the CLI is a complete mess. Remind me how you list submodules? Or delete a remote branch?
I feel that once tools like Difftastic [1] and similar get more mainstream, and ideally more firmly entrenched within git itself, it will make code reviewing much smoother process rather than having to depend on Github or any other proprietary service.
Edit: I think it's possible that I misunderstood, given the downvotes. I thought they meant that a dependency should be added in one PR, and then the feature needing that dependency in a separate PR. What I think they actually meant is that if adding a dependency requires upgrades of other dependencies, then upgrade the existing dependencies in one PR and then add the new dependency and feature in another single PR. That seems to make sense but not be necessarily a hard rule.
As I said below though, I still think the tooling in this space is terrible. Even for dependencies, I don't want line and text changes in config and lock files. I want something that summarizes what dependencies were added or upgraded.
I still agree with the original comment in that diffing technology feels decades behind, and that a lot of what we do as software engineers are working around things the tooling should be doing better on.
If you jam too many unrelated changes into one diff, people stop paying attention, because now reviewing it requires many minutes and note-taking.
Since hundreds of line changes can have little or no effect, but a single line change somewhere else can have drastic effects, it is essential to separate the unimportant from the important.
Changes in dependencies is a not unimportant change, but they tend to get treated like noise because those changes are associated with automated tooling, like the package tool. Updating dependencies separately solves a social problem, not a technical one.
It can be hard to recognize, esp. since it has so much cultural inertia and approval, but doing things like splitting things into packages, recording the links in package.json (whether by hand or by tool-assist), and then introducing something like `npm install` into the workflow as a way to lazily fetch parts of a application's codebase is nothing but one massive (and massively fragile) scheme to circumvent the version control system as an consequence of unacknowledged limitations of the relevant tool.
With NodeJS in particular, the issue of binaries is sort of dodged by exploding the files out instead of reading them from archives like Java does. However version conflicts can easily result in many versions of the same files in your repository, so you're still in a bit of trouble where bloat is concerned. While you should start by putting your dependencies on a diet, a different organizational structure for files than what git uses, where copies and moves are tracked better would help a lot.
Admittedly, narrative problems are hard to solve in general. It's a lot easier to "build a new tool" than to train a junior developer to always explain why/how in commit messages, to order their commits to "tell a story" of what the branch accomplishes, to avoid unrelated changes in digressions and asides along the way (moving those into their own branches/narratives), to tell that story in a PR description in a way that is useful to understanding the whys/hows of the branch (especially if the commits themselves lack some of the narrative or aren't ordered well for proper storytelling). I often settle for one or two of those at a time from a given junior developer.
I don't think we can automate ourselves out of narrative problems. I think narrative problems are one of the unsung creative problems of our industry and something that separates good programmers from great programmers. It's a human skill that takes practice.
> I feel like git was perfect when "code" was nearly almost completely text and patches were sent over email
That "perfect" never existed. Even codebases like the Linux kernel that work entirely in email still have their random binary blobs (often from outside vendors) and auto-generated files from tools. What the email flow focuses, arguably to some (such as many of the folks at Sourcehut) better than most other PR tools, is that conversation around the narrative and they why/hows. You expect a lengthy narrative discussion in a mailing list. Sometimes people see those comment fields in a Github PR and expect then to be less about narrative and more about nitpicking specific lines than having narrative discussions. (Nitpicking happens in mailing list discussions, too. It's mostly unavoidable. But to nitpick on a mailing list you have to do a lot more copying and pasting by hand.) There is something of a different story telling "pressure" when you are staring at an empty email with a file auto-attached than when you click the PR button in Github and get pages full of diffs and all the commit logs laid out before you before you ever start writing. (Sometimes people do see that and think their job is "done" and what they would write in the PR description would be redundant, because it is not a "blank email" that needs a greetings and salutation and maybe a description of the attachment.)
1. Single file executable. No dependencies to "install". Just the executable and you're good. 2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc. 3. You cannot rewrite history unlike git. Hence the name. Folks using git have no idea what kind of a peace of mind this gives me. 4. Integrated issue tracker stored in the same repo. Complete with cross references to commits. 5. Allows repeated use of same tag name. This is so convenient in personal projects I miss it in git. You can mark a commit as "published" and later look at the whole history of all previous commits tagged as "published".
Other niceties -
1. Integrated wiki - I've occasionally used it, but usually prefer to write documentation in separate files. 2. Integrated webserver - `fossil ui` runs on the same thing so I do use it. The webserver comes complete with user account management and permissioning. 3. Can export and import to/from git.
What strategy is employed for binary file handling? How does it compare to git LFS / annex / mercurial?
Aside from that, Fossil is very intriguing.
Fossil is, because of its sqlite dependency, limited to blobs no larger than 2GB each. Some of its algorithms require keeping two versions of a file in memory at once, so "stupidly huge" blobs are not something it's ideal for. Fossil is designed for SCM'ing source code, and source code never gets anywhere near 2GB per file. The only projects which use such files seem to be (based on fossil forum traffic) high-end games and similar media-heavy/media-centric projects which fossil is not designed for.
> What strategy is employed for binary file handling?
That's a vague question, so here's a vague answer: it handles binaries just fine and can delta them just fine. It cannot do automatic merging of binary files which have been edited concurrently by 2+ users because doing so requires file-format-specific logic. (AFAIK _no_ SCM can merge (as opposed to delta) binaries of any sort.)
I do hope someday git and others employ either a git annex or mercurial-style scheme where if it's a large binary file: 1. no diff is performed, and 2. only the latest version is kept within the history.
This would blow wide open the possibilities for using Fossil in binary-heavy projects such as machine learning, games, simulation.
I could see the SQLite limitation worked around by just splitting up binary data into multiple pieces.
That will never happen in fossil: one of fossil's core-most design features and goals is that it remembers _everything_, not just the latest copy of a file. The way it records checkins, as a list of files and their hashes, is fundamentally incompatible with the notion of tossing out files. It is capable of permanently removing content, but that's a feature best reserved for removal of content which should never have been checked in (e.g. passwords, legally problematic checkins, etc.). Removing content from a fossil repo punches holes in the DAG/blockchain and is always to be considered a measure of last resort. In my 14+ years in the fossil community, i can count on 2 fingers the number of times i've recommended that a user use that capability.
> I could see the SQLite limitation worked around by just splitting up binary data into multiple pieces.
There's no need to work around that "limitation" because "source code" trees don't deal with files of anywhere _near_ that size. Fossil is, first and foremost, designed to support the sqlite project itself: it was literally designed and written to be sqlite's SCM. Projects with scales of 1000x that project's are nowhere near fossil's radar.
Sharding large files over multiple blobs doesn't solve some of the underlying limitations, e.g. performing deltas. Fossil's delta algorithm requires that both the "v1" and "v2" versions of a given piece of content be in memory at once (along with the delta itself), and rewriting it to account for sharded blobs would be an undertaking in and of itself. That's almost certain to never happen until/unless the sqlite project needs such a feature (which, i'm confident in saying, it never will).
TL;DR: fossil is, plain and simple, not the SCM for projects which need massive blobs.
2: Fair enough. Although a multi-file backup doesn't sound hard to me either.
3: That would give me the opposite of peace of mind. I can't clean up my messy WIP commits?
4: Sounds like a nice feature.
5: This just uses the term "tag" to mean something else that git tags. But I agree that it would be nice to be able to label several commits (distinct from tags).
_Freedom_. Fossil is trivial to build on all modern platforms and we (in the fossil project) always recommend that folks use the trunk version, building it for themselves. Depending on an OS'es package manager just means that one is stuck with whatever version that package repo's volunteer package maintainers post.
> I can't clean up my messy WIP commits?
Nope. Fossil remembers what happened, not what "should have" happened. We (on the fossil project) consider that a feature, and fossil's own history is littered with "oopsies" (no small percentage of them from yours truly).
Fossil supports amending checkins at any time after committing, as often as you like - change the checkin commit, re-attribute to a different user, change the timestamp, or similar. What it doesn't support is _modifying_ them.
> And then there's this: what if I accidentally commit a private key or database?
Then you "shun" (to use fossil's term) that artifact. Fossil isn't 100% merciless when it comes to removing content, it just makes doing so a 4th-class sub-citizen of a feature and recommends against doing so in every case except for the one of content which should never have been checked in. Removing content inherently punches holes in the project history, so it's not something we (in the fossil project) recommend doing unless it's absolutely necessary for reasons of security or legality.
Fossil flat-out does not support, with the exception of "shunning" (forcibly removing content), the modification of any history. It supports the "amending" of any history, however.
For example, you can "change" the timestamp of a commit retroactively. It doesn't change the timestamp on the actual checkin (as that's cryptographically baked into the commit), but it changes how the checkin is displayed to the user in fossil's "timeline" view. Fossil also, however, makes it easy to see, in the details for that checkin, that the timestamp was modified later (and who did it, as well as when they did it).
So you can say git never removes anything either.
The biggest issues with data loss in git is before you have done a commit. There, many actions can nuke your changes because you mixed up two flags, trying to rebase before commiting, etc. As long as you have a commit though, the reflog will save you from failed rebases.
So if someone new on the team accidentally commits "node_modules" it's there in the history forever? Doesn't sound like a great feature...
The choice to discard history gives freedom to developers
Then the 120k+ files in node_modules is in there forever, far outliving that team member's career as a software developer.
If the user has not yet synced those changes to a central repository, they can still delete their copy, re-clone, and re-do their checkin to be "less encompassing." Once they push, however, all of their coworkers will hate them. The fact that pushing would take noticeably longer than it should for that case would be the first hint that tapping ctrl-c would be in order (that is, cancelling the sync with the upstream repo).
> ... it's there in the history forever?
Until/unless it's "shunned" (which would take extraordinarily long to do for 120k files, as shunning requires the artifact IDs of every file to be shunned, and if a single one of those hashes is the same as a file which should not be shunned (e.g. all empty files have the same hash) then tough luck).
It seems likely, however, that new developer's colleagues would have long since added `node_modules/*` to the repository's `ignore-glob` setting so that the new colleague wouldn't accidentally add that.
Sidebar: in my 14+ years of being active in the fossil community, nobody's yet posted saying they've accidentally checked in a node_modules directory and asked for advice on how to deal with it. Presumably node folks primarily exist in Enterprise environments, and Enterprise environments all use git because that's where the tooling is.
Re. integrated wiki: when i first saw fossil (Christmas break of 2007) two features made it a killer app for me: wiki and hosting as a CGI. The wiki aspect has long since taken a back seat to the so-called "embedded docs" feature, where the docs live in the source tree and become first-class SCM citizens. However fossil is, to the best of my knowledge, still the only SCM which is absolutely trivial to host as a CGI, which means it can be hosted on cheap shared hosters just as easily as it can on one's standalone VPS.
As far as "what comes after git," though: git is the SCM needed by the 0.1% (or fewer) of the largest, most-active FOSS projects. Imagine the Linux kernel source tree if its SCM could not remove dead branches - it would quickly become uncloneable under all of that weight. Fossil is not designed to scale to projects of that size. Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium.
I wonder why so few developers consider the scenario you describe. Git fits the development of Linux. But, a question rarely raised: why is Git considered suitable for small or medium projects?
Quite frankly, _it's not_. There's _absolutely nothing_ ideal about git except for its ability to super-scale to that _exceedingly small_ percentage of projects which need that level of scaling. That's its _one and only_ killer feature. If it weren't for github and its ilk, git would be just another second-tier tool like the rest of the SCMs. Unlike every(?) other SCM, fossil doesn't require 3rd-party tools to host over CGI: that's built right in to it and CGI works on even the cheapest of shared-hosting platforms, so no equivalent of github is required in order to host one's own repositories.
Granted, as a long-time fossil dev and advocate, i'm _severely_ biased in this regard, but there's are _reasons_ i prefer fossil over git, why i use it for _all_ of my own projects (fossil.wanderinghorse.net), and why i support and advocate for it (just not for that small tier of "uncommonly large" projects, as fossil has, quite frankly, no business being used there).
I actually love git (even for small projects) but it's because I've been using it for so long now; I suspect if I learned another DVCS I'd be using it in isolation, and git works just fine for me
3. You cannot rewrite history unlike git. Hence the name.
First, you use that as a "teaching opportunity" to educate that someone about why doing so is Bad for Business. Secondly, you "shun" the artifact(s) in question. Since shunning burns holes in the project history (DAG and blockchain), we (in the fossil project) invariably advise against going so unless it's absolutely necessary (publishing custom data being an example of "necessary"). There's a major semantic difference between deleting content "just to cleanup the history" vs. "to eliminate legal liability."
> , just burn down the whole company and start over?
If you prefer that approach then have at it.
If you think you can do it better then go ahead and try build the product and then pitch it.
It's basically click-bait for hackers. "How to do X technology better" with a few paragraphs of ideas, and taking no responsibility for actually doing something about it, aside from hoping that their vision might inspire someone else to put in the hard work.
I didn't say they have to do anything. I did observe a pattern.
There is a difference between saying everyone should take responsibility for fixing all their criticisms and noticing that a particular person never takes responsibility for any of their criticisms.
Without making an attempt at implementation, you (the generic you, not the person I'm replying to) have no idea what the real issues are. Even failed or partial implementations are more instructive than armchair criticisms, or thought experiments where you can just handwave away all the competing constraints that need to be considered, whether in Git or in any erstwhile successor.
The list goes on
While git is good and powerful in many ways, git frankly has many deficiencies, yet everybody treats it as the holy grail of version control. Just because Linux uses it, GitHub exists or something else, I don’t know. The author lists many valid points that are not all sci-fi and that would multiply the usefulness of the vcs sevenfold.
Someone has to point out the elephant in the room.
It could spark the idea for someone to invest in something new and better or for someone to contribute improvements into git.
And your pain is distributed systems. Not just of source control, but bug tracking. And general process-manager-y stuff.
At the end of the article: This is a clearly ambiguous merge and it simply wouldn’t be right for your version control system to try "resolving" it for you.
So the strategy is that if there is any doubt you have to manually fix conflicts. This is by design.
Aside from it all being very vague, it struck me these are high level concepts and keywords the author seemed to have gleaned from experience working with knowledgeable peers but never quite grokked themselves. So it surprised me to read their open-source maintainer experience about page (though the professional experience being in Google does fit my original assumption).
> Atomicity accross projects
Git repos are as atomic as you make them. Github is not a defacto monorepo. The only people likely to use it as such are monorepo aficionados (Googlers?) who are deliberately avoiding atomicity. Also, Github isn't Git.
> Package management
Package managers already use checksums. This entire point is just wrong and ignorant. Reproducible builds would be nice here, sure, but outside of a few weird exceptions in dynamic builds we already have what the author wants here.
> Semantic diff
This would be great but... the author is an engineer right. How much have they thought about this? This would be a gargantuan undertaking. An awesome feature no doubt, but the maintenance effort...
> Merge queue data structure
The body of this bullet doesn't relate to the heading. I guess they're talking about how in-progress merges are stored on the FS but how would that impact testing (which the author rightfully points out is unrelated to VCS). What? This is just mashing unrelated jargon keywords together.
> Fan-out pull requests
Github is not Git.
> git should be fully decoupled from the pull request and merge workflow
Oh dear. Where is Drew Devault...
> lfs
The first good point they've made
> fossil
Yes fossil is cool. If the title of the post was "we should all use fossil" it would be more realistic.
Not with submodules, apparently. [1]
> Package managers already use checksums. This entire point is just wrong and ignorant. Reproducible builds would be nice here, sure, but outside of a few weird exceptions in dynamic builds we already have what the author wants here.
I agree with this point, but maybe using the cryptographic hashes from a VCS is better than a checksum? Other than that, I don't think there's any reason to tie the two together.
> This would be great but... the author is an engineer right. How much have they thought about this? This would be a gargantuan undertaking. An awesome feature no doubt, but the maintenance effort...
Actually, not really a gargantuan undertaking. Large, yes, but that's only to tell the VCS about the semantics of each language. The actual algorithms to do so are pretty small, and the semantics needed for each language consists of a lexer and some dumb knowledge about the structure, i.e., what a function looks like, what a type definition looks like, etc. Source: I am designing those algorithms right now.
Other than that, I agree with your points, except that I'm now making a competitor to fossil. :)
in case anyone missed it: https://github.com/Wilfred/difftastic
I think it's reasonable to argue that git shouldn't get confused in this scenario, but you could also do your renames in one commit and your changes in another.
I think git can be configured on how hard it tries to find renames from similarity between a deleted file and an added file.
You can find more information on how Git now does it at https://blog.palantir.com/optimizing-gits-merge-machinery-1-... . I think this first started to be released in v2.31.0, and completed in v2.33.0. v2.34.0 switched the default merge strategy to the new 'ort' strategy mentioned in that blog.
I think there are unfortunately still cases where what the GP is suggesting improves the UX, i.e. I think some shortcuts are taken when following a file if the content doesn't change.
IIRC this matters particularly for very large renames, at some point during revision walking we'll give up trying to match your A.txt to B.txt, but if they're the same...
It's your POV that it's the same file. One could argue that it's a new file and the content of the old one embed in the file. That's the huge problem with git users, people cling desperately to the idea of changes, when git is just about snapshots.
It also happens that one is much, much more common in software development than the other, so it's a much better mental model of what SEs do.
So you're clinging to your mental model. Thanks for proving my point.
I could contort my mental model to make it match how Git works, but it is a contortion that some tool imposes on me.
We work in computing, I would expect everyone's mental models to be computational, not equational - different algorithms with the same result are still different. QuickSort is not the same as Merge sort just because they have the same inputs and outputs.
You may be aluding to git's underlying storage being snapshot based, but it actually also has diffs in pack files.
Storage optimization, absolutely unrelated to the diff between two snapshots.
To me this looks like integrating it with tools of actual conflict resolution during merges will be a bit harder than one would like. I'd be glad to be wrong.
Outside of this, I think it's achieved it's ultimate form and tradeoffs for what it was originally intended to do - and the majority of projects fall under that category, meaning that while Git can be improved, but it doesn't need to 'change' architecturally or philosophically to accommodate other things.
Separate version control software can be designed for solving a specific problem - but I don't think Git should need to evolve beyond the problems it's designed to take on.
LFS is a plugin to install, but that's maybe a strong indicator in favor of the git model that there are common plugins to solve some things like this. (And many distributions of git now also bundle LFS.)
A project should encapsulate the code, how we got there, what we changed, and why we changed it.
The code is your HEAD, available as a working copy. How we got there is the stack of diffs that, when applied to an empty repository, accumulate to being the current HEAD. What we changed is more nuanced that just the diffs: It’s the commit messages explaining the diffs and adding context. If the diff changes an algorithm from n^2 to n then what we changed is the runtime complexity of x, which is good for reasons y and z.
Why we changed it is the bit that’s missing. Was this work originally from a bug report? Did real-life-n stay small for our first six months and has all of a sudden become much bigger? Who was involved in deciding this was the right thing to do, what did they say, and what other approaches did we think about? Which cat meme was deemed appropriate for the final approval of the change?
Right now, that stuff is all linked to from git but it’s not really a part of the workflow unless you remain inside GitHub’s or GitLab’s ecosystems. Seeing that in the underlying tool would be really cool.
FWIW, that wins my internet for today and i'll aim to make that a factor in any future code reviews/approvals.
Commits are automatically "branches" off trunk. You typically do 1:1, commit:PR. As you make new changes to the same PR, you `hg amend` instead of another commit. Those commits get merged into trunk.
That's why I am exited for tools like Pijul that attempt to actually track changes.
Tracking changes necessarily needs to define a way to describe how things may change.
Perhaps another take on the issue is that changing data should be structured to be more snapshot friendly?
The formats are ready for the next steps, but since this is only useful for really massive repos, I want to wait a little bit before spending the time on these features. If more people start using it, it may provide the motivation needed.
The post just loses credibility after this statement. Yes, Kubernetes is important, but "operating system" is a clearly defined technical term. Using it arbitrary on something that is clearly not an OS to achieve some sort of an off-topic emphasis effect undermines the credibility of the content.
Originally, an "operating system" is a system that takes the role of an operator. In the early days, operators were people who loaded programs, feed them data, fetched the results, etc... for the users. Matching the modern definition of an interface between the user and hardware.
Kubernetes allocate servers (hardware) to containers just like a typical OS allocate CPU and memory to processes. And it stands between the user (here, the sysadmin) and the hardware (the servers). "Operating system of the cloud" is, I think, a good description of Kubernetes.
No, it does not. An operating system (OS) is system software that manages computer hardware, software resources, and provides common services for computer programs. [1][2]
You cannot just arbitrarily take long-established technical terms and redefine them to suit your needs or your rough intuition. If you look in the authoritative sources below, there are over 100+ mentions of Linux and Windows, as well as several mentions of esoteric and defunct OS like Haiku, BeOS and others. Not a single mention of Kubernetes.
This is because Kubernetes is not an operating system and it does not fit the technical definition of an OS. It is container orchestration software.
It is important to call things using their real names, otherwise, eventually, communication breaks down and no one knows what we're talking about.
"Operating systems" in a much narrow sense were invented in the 1950s. I cannot tell you what people meant by the term back then. Then it seems that they accreted features. And then they accreted more features, like a gigantic snowball or avalanche. Ultimately, this all happened because people were lazy and didn't want to repeat themselves -- and there were lots of things to be lazy about. Also, branding and marketing became important. And now an operating system is defined by its user interface guidelines, the artwork in its GUI, what web browser it comes with, and what other software it does/does not ship with. Some people gerrymander the meaning of the word to justify the architectural choices of their favoured operating system.
By the way, being able to parrot the dictionary's definition of a term doesn't mean you know what it means. And knowing what something "means" (that is, knowing how to use it) does not mean you know its dictionary definition. The education system often forces people to remember these things and regurgitate them, which serves only to help you sound convincing in debates.
As for the rest of your argument, I feel ambivalent on whether it is worth responding. But here's my two cents:
1) Random userland software bundled with the OS does not constitute part of the OS. And that's not just my opinion, that's the legal ruling in the 2001 United States v. Microsoft Corp case, where Microsoft tried that argument.
2) I think it is a bit disingenuous to try to present Kubernetes as some sort of a natural evolution of the term, when it is pretty clear the intent behind calling something "THE operating system of the cloud" is marketing and to try to drive up the hype.
As for the "being able to parrot" bit, please spare your personal attacks. They don't make your argument any stronger, they just make me think it is not worth talking to you.
Sorry. I wasn't trying to attack you. But I can definitely see that it comes across that way, so I'll bear that in mind in the future. I might have been arguing for the sake of arguing too.
What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious
Instead what we get is over complicated nonsense with commits and stashes, rebases and heads, reparenting etc. I get it you don’t want to store your code on your local machine but that’s what backups are for, that’s not what the version control system should be doing.
You can choose which one to use in your project, and someone could enforce or write a wrapper if they wanted to to enforce/encourage a certain method.
Learning one of the above methods, especially stashing and/or pull conflicts, isn’t that difficult or hard to grasp. Git even recommends this if you try to push to a more up to date upstream.
And do you seriously not see the need of rebasing?
Furthermore, you seem to mistake git's distributed nature for some sort of backup scheme. That's not the case. The idea that every repo is equal is tremendously useful.
> And do you seriously not see the need of rebasing?
I don't see any real problem that rebase solves, but I do see that it mangles history and makes troubleshooting e.g. git bisect much more difficult.
How does rebasing break bisect?
Some projects prefer rebasing onto master instead of merging onto master or squashing onto master.
If you rebase onto master but don't clean up the commits at the end of the PR, this litters master with a bunch of "top level" commits that don't build and cause git-bisect's test to fail due to those commits not working in the first place.
If you rebase onto master but you do clean up your commits such that each commit onto master represents a fully functional version of the project, this isn't a problem however it can make a bisect take way longer than if just merge commits are tested.
If you are rebasing to this degree, I don't really understand the purpose of the rebase for a feature or issue branch (as to this degree, the last commit is the only "completed" commit of this type of branch and you are effectively squashing). It makes sense for say a release branch so you can integrate hotfixes/patches but that workflow can be just as if not more effectively handled via a merge or a squash as well.
The whole beauty of bisect is that is a binary search where if you double the number of commits you only need to do ~1 additional check. So no, it can't take "way" longer.
And it's not like you'd call it a day after finding the merge commit that breaks things - you then need to find the actual problem with that branch and the fastest way to do that is bisecting down to the individual commit so you are actually doing the same work but artificially restricting git bisect from evenly dividing the search space by restricting it to merge commits first.
add
upd
fix
upd
fix
Of course that should still be rebased down to a reasonable history.
That's like 9 out of 10 people in my experience and none of them are juniors. It's pretty hard to get developers more disciplined.
At the least, if you're dev refuses to give you a nice commit, you could merge-squash his branch.
I've also managed other projects/branches like you have, merging the changes into my work.
I also use the cherry picking feature (which rebase builds on) a lot. That is for things like creating hot fixes, pulling in some upstream patches to my local fixes, reordering a branch, etc.
Rebasing isn't actually necessary, and there's a good argument to be made that you should never rebase. Fossil (the version control system used by the sqlite team) doesn't have any rebasing mechanism: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
(there are of course also very good arguments in favour of rebasing, but my point is simply that it isn't strictly necessary in a "complete" version control system)
Well....but you literally said above that there's a need for it. In a somewhat condescending tone. And now it's suddenly obvious that it's not necessary? Okay.
"Oh man, I really need a nice dinner right now" is impossible for you unless that dinner consists of the absolutely strictly minimum necessaries of nutrients in a gray tasteless slurry? Come on.
To me, rebases are the work of the devil and I never use them. To each their own I guess.
Huh. For me, they were one of the most intuitive parts of git. Altough, it was a long time before I ever used more than 1 layer of stash at once. (And even then, I rarely do so nowadays)
Of course, just making an IDE multi-player would introduce chaos. What if the tool solved that chaos?
- Git is slow on large repos, even on an SSD.
- Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral.
- Git's submodules are unergonomic at best.
- Git's CLI is a mess.
Deeper:
- Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pijul.
- Git is line-oriented and has no notion of semantic diffs and semantic merges. This makes it a raw tool when working with, ironically, source code.
Don't get me wrong: the data structures and ideas on which git is based are beautiful and reliable. But something (even) better can be built on these ideas.
Maybe on Windows, but then everything is slow on Windows. On my 2015-era machine `git pull` on the Linux kernel source tree is nearly instantaneous after the remote objects are downloaded. Same with `git status`, `git diff`, etc. I mean, that's what it was developed for, because everything else was slow.
The first SSD I bought back in 2008 was to put a large git repo on it; it helped. With much larger repos, like those I had to work with at Facebook, even an NVMe drive becomes a bit uncomfortable, and one has to use something like Watchman [1] to track changes without a rather noticeable delay.
Git is a content addressable snapshot system, with bolted on code to make it retrospectively appear to be a line-oriented system.
It's worse than you thought.
But it's easier to complain about git and throw out pie-in-the-sky ideas about "modernizing our tools" than to try the actually-existing AST-based diff/merge tools and realize it's 100x more complex for no workflow gain.
I think this is an example of induced demand[0]. One of git's main advantages compared to other options is its speed. Git was so fast it completely changed the way you could work. It went from reluctantly interacting with version control when you needed to check in work, to integrating it tightly into your workflow. But, like with many things, people always find a way to "use up" the resource and make it slow again.
Compare this with Pijul as well!
I've been working on legit.pijul.com (you can try it, but nothing is ready!), which leverages byte-level storage to get higher-level diffs (I know this sounds counter-intuitive, but finare storage granularity gives you more flexibility to compute diffs).
That said, Git isn't actually line-oriented, 3-way merge is. But then even a byte-oriented 3-way merge would give the same shitty merges as Git.
With Java, checking in your dependencies was always complicated by the trouble handling binaries efficiently. With NodeJS that's not a problem, but conflict resolution often ends up with duplicate files, so checking them in is still challenging.
I'd like to see git's content-based more integrated into projects like IPFS (and for IPFS to get their resource-usage down, so it can be run as a background task on my laptop!)
As for package management, Git and Nix work really well together: e.g. we can use `builtins.fetchGit` to fetch particular commits; and we can `import` Nix definitions from those git commits; and those definitions can fetch other repos, etc. so we get a Merkle tree of the exact code used by all of our dependencies. I also like to write commit IDs as default function arguments, which makes it easy to override any of these dependencies to use another commit.
Pijul is instead a CRDT, meaning that independent patches can be applied in any order without changing the result, which makes rearrangement unnecessary, and the system much faster.
For anyone who hasn't looked at Pijul, the theory part of the documentation [0] is well worth a read.
I believe it is production-ready, in the sense that there hasn't been any real bug in months. I'll remove the "beta" label when more people use it.
One thing that isn't production-ready is nest.pijul.com, but mostly for lack of funding: that platform uses the CRDT nature of Pijul to replicate all the repositories in different datacenters, but the machines it runs on are somewhat undersized, and the PostgreSQL databases don't like that very much.
But you don't need that to use Pijul, a simple SSH server works fine.
Never seen it described like that.
> Previously, I was a software engineer working on open-source Kubernetes at Google, building and maintaining Kubernetes developer tools such as minikube and skaffold
Ah!
You better get it right, or otherwise you get to nuke the whole repository.
`git reflog` contains a full history of all refs you’ve been on in chronological order. Unless you explicitly delete them, dangling refs are not cleaned up immediately. If you rewrite history and realise you made a mistake, you can likely recover by simply resetting the mutated branch to something from the reflog, even days or weeks afterwards (the default reflog retention is 30 days).
The `tmp` command creates a commit of all changes, branches it, then rolls back the commit.
[1] https://github.com/flurdy/dotfiles/blob/master/.config/fish/...
IMO "easy to break but easy to fix" is better than "hard to break but impossible to fix", and there ain't no such thing as "hard to break" after enough time passes.
If you do a big force push on a remote repository you could keep the old stuff in a tag or a branch.
You can find the "old" commits using "git reflog".
I've fixed a lot of botched rebases with that :)
Start another branch at the point where you want to rewrite history; don't switch to it: `git branch original-history-branch`.
Now `git rebase` your branch to your heart's content. This branch will have the new, rewritten history.
The original-history-branch still has your old history, refers to your old commits and prevents them from being garbage-collected, just in case you'd like to reset your target branch to that state.
That is to say - sure, it can work, but automated history tracking is far superior.
Though, git does at least have reflog, so if you accidentally delete or overwrite a branch, you should be able to get it back. That’s far better than the equivalent situation with files on a filesystem. But it’s still not real history tracking.
Git keeps a version for you while you are doing a rebase, so you can say `git rebase --abort` and get back to the preserved state. But it does not keep a log of these, and, more importantly, does not ask you whether you are glad with the end result: you cannot --abort right after a rebase completed without conflicts. One would say that you should explicitly do something like `git rebase commit` (or `git merge commit`) after you have reviewed the result.
Another approach (which might not be git anymore, but close enough to talk about in git nomenclature) might be some kind of facade layer for the history where you fix wrong comments, bundle up old commits to linear groups and so on. A commit hash would still reference a code state, but the repository state (code and its revised history presentation) would be something like "g123abc as seen by g345fed", usually "g123abc as seen by branch/HEAD", perhaps width some clever defaults like "head of whatever branch has the most recent commit on top of g123abc"
I say stuff it!
It takes so much of the guess-work out of build tools, CI, etc.
The article could have been interesting if the author actually expanded on what these pain points are. I'm genuinely curious about those.
I wish it had native zip and sqlite support, I'd love to see issues and PRs more integrated, but that's about it.
It would be nice to have an unversioned sync directory in a repo, that could be updated without a commit and had no history, for implementing fast-changing stuff where history isn't critical, like stashing log files right on an internal config repo. But that's not exactly necessary.
I'm sure better things could be done. But would they be usable over ssh, no certs needed, as well as HTTP? Or would you need a domain name? Would they have decent GUIs? Would they still be decentralized? Would they have an equivalent to LFS? What features would they drop?
Would half the features be plugins so that every repo relied on a unique set of optional features?
I'm... not sure I'd like the kind of VCS that the current FOSS culture would like to make....
If people really tried to replace Git, could see multiple VCSes getting big at once. Git is pretty unique in how it is so popular, you probably don't need to know any others.
We can do better than git, but it's pretty unique. It's already a base primitive for so many things like package managers and notetaking. It's so deeply engrained in dev culture, it's almost like UTF-8, and I would hope whatever replaces it has that same property.
I think the easy solution would just be if the git devs themselves made a new first party front-end and added a few features.
There are lots of git frontends, that everyone ignores because you might as well just learn git, it's everywhere, but if some new git2 command was included and just as common, we could have a very smooth transition.
I hate that the github/lab hosting solutions end up with a central database to keep track of issues, CI, etc. It breaks the whole "distributed" model.
Issues are kept in the repo, inside a .issues folder, so they can be cloned, merged, etc. Each issue is just a maildir, with metadata stored as headers on the top-level message, and comments stored as reply messages.
I really like this approach, since there's no need for an always-on server; it's decentralised; I can use any mail client to browse and update the issues (there's also a simple CLI for listing and printing issues/comments); etc. For example, I write artemis issues using the standard message-mode in Emacs, and I render issues to a Web site using MHonArc (a program originally designed to render mailing lists).
If everything is PRed and all PRs make merge commits `git log --first-parent` in your main branch is your PR history. If PRs are also your unit of CI `git bisect --first-parent` is a bisect on your (PR) integration log.
The only thing missing from your "central database" at that point is comments inside the PRs that aren't accounted for in your final merge message in the merge commit.
But I started off with MPW Projector[0], so it's all sunshine, after that...
The “UX” doesn’t bother me, as it’s a fairly classic CLI application. Any “UI” is provided by apps that are written over the CLI. That’s a common pattern in development.
I use SourceTree, for the most part, with occasional drops into CLI, for specialized tasks.
Not perfect, but adequate. I do not use the Git integration in Xcode. I find it to be inconsistent and buggy (like many Xcode features).
I have found that submodules are all but worthless, which sucks, because I feel that they really are the best way to tag aggregate codebases. From what I understand, this is because of the author’s workflow. If submodules worked like package managers, that would be wonderful.
In my experience, I find sparse checkouts to be a bit “kludgy.” I find it annoying to have to check out an entire repo, for a single file (my testing code usually dwarfs the implementation code, in my packages).
Perforce used to be good at specifying “only what is needed” workspaces.
One aspect of VSS (dating myself —no one else will) that was very cool, was the ability to specify “artificial” workspaces.
You could create a workspace that aliased files from multiple workspaces into a new aggregate. When you modified and checked in work, it could be doled out to several different repos.
That’s pretty hairy. It would be difficult to implement safely.
Git has changed the way I work. As time has gone on, I have moved away from using feature and release branches, to using tags on a single mainline.
I think forks and PRs are great things, but they aren’t actually native Git features.
[0] http://preserve.mactech.com/articles/mactech/Vol.14/14.06/Ve...
Version control systems like Piper (Google internal) and Eden (Facebook), GitVFS (Microsoft) already do this, but adoption is marginal.
If you're not going to commit to fixing downstream packages for other teams when you change something, it doesn't make a lot of sense to have a monorepo. Instead, let people upgrade at their own pace.
How many people actually check that git has merged code correctly? When there are no conflicts and the merge passes CI? Exactly.
Now imagine the git automatically fixes conflicts by rewriting code Copilot-style. It will work perfectly 95% of the time—--so that new feature is too useful to ignore and everyone uses it. 5% of the time git resolves the conflict by riddling your code with subtle bugs and vulnerabilities…
My notes on this: https://topictrails.com/app/d/ed47e12a-7cf9-4ec6-8f22-1c9717...
Git annex functionality built in = gg every other source control system.
Of course. There is no way Git is the be all and end all of version control. Anyone who has been around long enough has seen lots of version control systems and knows that we will see lots more as time goes on.
This is not to say they’re perfect but they’re open source so if I felt strongly I could offer code to change it.
Working on a new feature: new worktree Doing a code review: new worktree Testing random changes: new worktree (usually in detached mode) Need to debug some code from the current production branch: new worktree
All the problems with `checkout`, `stash` and switching between branches disappeared.
Granted, the learning curve can be a little steep, but once you learn it you're good to go. There's a rich ecosystem of documentation, helper tools and shell aliases you can find that can help you master the tool to get your job done.
Some of my favorite paid tools for working with git are Tower and Kaleidoscope (I'm a huge fan of native mac apps).
Got isn't really trying to do software version control better than Git. It's trying to make general purpose file versioning practical, with a workflow similar to Git's.
I know a lot of people who have a lot of hope for diffsitter (or something like it): https://github.com/afnanenayet/diffsitter
Personally, I think the reason most "good" semantic diff tools are proprietary is that they are huge amounts of effort that are mostly "hacks" and "heuristics" bandaged together in ways that people don't want to let out how the sausage was made.
But I also think "general, language agnostic AST-based semantic diff" is a mountain peak we cannot reach (probably ever), and I believe my experiments found an interesting local maxima that people are maybe passing by on the way to that ideal mountain (lexer-based diffs rather than parser-based diffs): https://github.com/WorldMaker/tokdiff
Why not? Storing code as code (ie storing an AST not text) and treating all changes as a CRDT, allowing your refactor to use a variable I just renamed without merge conflicts, seems completely reasonable.
>inb4 it isn't simple
it is
same answer.
No king rules forever. C has become a much more niche language than it was 20-30 years ago, and the trend continues. C++ has slowly eroded most of its niches, and there's a slew of new languages gunning for its throne - Rust being the most likely to succeed (especially once we will have some popular Linux modules in Rust).
Will there still be a niche for C programmers 50 years from now? Absolutely. Just like there is a niche for COBOL maintainers today.
In a similar grain, git is a beautifully designed and conceived simple content-addressable object store. With a complex and challenging UI (I don't have any problem with it, but still).
Neither of these tools are perfect; in fact they can sometimes be objectively be more imperfect than many of their competitors. But they are special.
> some have written the same about various assembly languages, about COBOL, about FORTRAN, about LISP in AI
It's not what people write about - it's what they use. C, UNIX(/Linux), Git are all very similar - and Pervasive.
I feel the same way when I hear griping about vim or Java. Like sure, there's surface stuff to cry about... Until you start to hear people's ideas. Then you're glad people have managed to mostly leave it alone!
I also thing there's just this class of tools that only make sense when you get to a certain level with them. Learning curves are just steep on some things. That's not the same as bad design.
> Do you use GitHub?
Just a bit, it's nothing I look forward to. I mainly use Gitlab due to work, but it's not that much better.
> Do you work with a team?
Yes.
> Did you really review other alternatives and try them out?
Only SVN some years ago and I hated it.
It wasn't my intention to say that Git is the best VCS we'll ever get, but I enjoy using it and (besides the sometimes a bit baroque command line syntax) have nothing to complain about. So, whenever there's the need for version control, I choose Git without second thought and so I never even felt the urge to try something else. I'm sure that this will change at some point, but not yet.
Git is popular because it is free, fast, works well enough, and was popular in some major projects.
Its major advantage for most orgs (those who actually use it in a centralized manner, with a corporate repo that everyone syncs with every day, unlike the Linux kernel team) as compared to Subversion is that it makes branches cheap and easy. The ability to work with history offline is also nice in niche situations, but definitely not the major selling point.
Its major advantage compared to Hg is that it is more popular.
IMHO branching itself isn't expensive in Subversion, the problems arise when you merge (feature)branches back. If you branch off (for release branches) and then just selectively merge certain commits to that branch only if needed (the info being stored in svn:mergeinfo), I think its not that bad. I prefer branch-by-abstraction and trunk-based dev anyway, so here you go ;)
Goodbye to installers and package managers....and traditional build systems.
Great idea. The corpus of data to train with would be incredible. Every merge commit across all of GitHub.
So here's what I think of these points, as well as how my VCS will address them.
1. Atomicity across projects: this is a good point, a necessary one. When I asked people why Git submodules are so bad [1], that was the biggest point. My VCS will have this, even though I haven't quite figured out how to do it yet. I'm almost there.
2. Native package management: my VCS will have this, sort of. The thing is that I hate CMake, so I'm building a build system, and while doing the design of it, I realized people are doing build systems and package managers wrong. So I'm working on that too. Needless to say, my package manager/build system will be well-integrated into my VCS. (My package manager will also have another shtick: you can set security policies for individual packages, which means that situations like where npm packages become malware should not cause damage.)
3. Semantic diff: I have figured this one out. It will exist. It will be language-specific, but all that it needs is a lexer for the language and a dumb understanding of the structure. This same system will also be used for diffing and merging binary files, such as Blender files, PNG's, executables, PDF's, files for Microsoft Office, files for LibreOffice, etc.
4. Merge queue data structure: my VCS will have something that will serve this purpose and could probably implement a high-level interface to it, like Git has porcelain over low-level operations. However, what I have actually designed is so powerful, it will also be capable of real-time collaboration and of implementing full undo/redo.
5. Fan-out pull requests: this is currently not in my plans (I think better package management would handle most or all of this), but it would be trivial to implement if people want it.
6. Terrible UX of Git: I'm going to spend the time on this upfront. In fact, I want to do user testing with non-programmers until they find it easy. I will take inspiration from Mercurial for sure, but the user testing results will be the most important.
7. Large file storage: my VCS would be completely inductive at binary files if I didn't have a plan for this. I do have a plan, and I will be testing on large files, including up to multiple terabytes, from the start.
8. Project management hooks, but not features: there will be built-in features for things that should always be there (issues is one, I believe), but there will also be a way to set up your own. They won't be hooks, per se, but it will be possible to create the project management "flavor of the month."
Comments on these are welcome.
- push
- pull
- checkout
- checkout -b
- merge —ff-only
- stash
- stash pop
- reset —hard origin/master
- reset —soft $hash
- commit -m
I find that command too dangerous. I only use git fetch and git merge --ff-only.
You forgot git tag
- push/fetch: I personally never liked pull, it's sugar over fetch and merge/rebase.
- checkout -b: haven't looked into all the switch stuff yet
- rebase -i: my bread and butter. I rarely use merge aside from PRs where rebase bugs people.
- add/commit -am: obviously required
- cherry-pick/reset: pretty much replaces stash without introducing a whole new set of tools
- diff/log/status: if you get comfortable with these, you're not going to wedge yourself ever again
- brach: very much an unsung hero. If you get comfortable with commiting often and using brach. You can't ever lose your place doing anything ever again.
use a backup branch prior to stash, just in case.