23 ms·

What comes after Git

227 points by rckrd 4y ago

zambal 4y ago
> I saw the pain points of git (and GitHub) firsthand working on Kubernetes open-source. The article could have been interesting if the author actually expanded on what these pain points are. I'm genuinely curious about those.
EdSchouten 4y ago
- A client side virtual file system (FUSE), so that you can work with large repos that exceed the size of your own system. Version control systems like Piper (Google internal) and Eden (Facebook), GitVFS (Microsoft) already do this, but adoption is marginal.
- Ericson2314 4y ago
  I really want a system-wide content addressable store that a lot of different things can use.
- skybrian 4y ago
  Having used Piper, I think the Go package manager's approach is better, actually, at least for a collection of packages maintained by independent teams. 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.
  - oivey 4y ago
    This is a good way to put it. I think the opposite is also true: going with many repos means you are committing to other teams being on their own to upgrade. It’s difficult to know if you’ve fixed all downstream code if everything isn’t in one repo. That model makes sense for OSS. Not so sure about within companies.
- WorldMaker 4y ago
  It's also interesting to note that at this point Microsoft seems to be pivoting away from GitVFS. They've put a lot of collective engineering work in git sparse clones and git partial clones and the intersection of the two ("sparse cones") and optimizations like git commit graph pushing git itself to better at virtualizing its object store, not touching objects it doesn't need, and better handling just-in-time scenarios for object retrieval when it really does need them.
leeoniya 4y ago
> Semantic diff – Can we figure out how to use version control to have more context-aware merges? Can you believe that we still rely on a text diffing algorithm from 1976 (and its shortcomings)? Git still has trouble with file renaming. GitHub Copilot, but for merge conflicts? Semantic diff has been tried before, but language-specific implementations will likely never work. in case anyone missed it: https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic
- crmrc114 4y ago
  git mv?
  - kadoban 4y ago
    That's just a convenience command. Git doesn't actually record moves as anything different from a delete and an add. Many of the querying commands (eg `git log`) use heuristics to show moved files, but they end up wrong fairly often, especially if you don't mess with the parameter(s) of the heuristics.
    - saxonww 4y ago
      In my experience they are correct all of the time for simple renames. It's when you move a file and make substantial edits that it gets confused. 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.
      - Akronymus 4y ago
        Would it make sense to make one commit for the move and one for the changes?
        bloak 4y ago
        Yes, in some cases, but it depends on your workflow. Some projects require each commit on the main branch to be fully working and pass all the tests.
stellalo 4y ago
> I saw the pain points of git 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
- PawBer 4y ago
  You can treat the points in the article as those.
- spencerchubb 4y ago
  that's what the whole rest of the article is about :)
- bergenty 4y ago
  I’m not qualified to go into specifics but I hate it. All version control needs to do is pull, push and branch. Version on branch is newer? You need to pull down before you can check in. 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.
  - oivey 4y ago
    I’m confused. You do have to pull before you check in (aka push new commits)? Those systems don’t exist for backups. They’re for collaboration.
  - samtheprogram 4y ago
    These are just different ways to handle the same problem, and the fact that git provides different methods is a good thing. 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.
kache_ 4y ago
Nothing. Keep it simple. There's a reason it has stuck around >inb4 it isn't simple it is
- fargle 4y ago
  agree. same question as "what comes after C ?" same answer.
  - tsimionescu 4y ago
    I'm sure some have written the same about various assembly languages, about COBOL, about FORTRAN, about LISP in AI. 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.
    - fargle 4y ago
      But those aren't good analogies for "C". I think the best analogy is the long-standing belief prior to "C" that assembly would "always" be the systems programming language. Yes, someday a new king will be born (I doubt a coup). 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.
- Akronymus 4y ago
  The beauty of git is in that it is a simple data structure, with simple functionality.
- 4y ago
torginus 4y ago
My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.
- deleted 4y ago
  [deleted]
- roganartu 4y ago
  Perhaps this is a byproduct of the UI (which I totally agree is bad), but this is not true. `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).
  - torginus 4y ago
    You learn something every day!
    - alexchamberlain 4y ago
      Another super simple technique is to create a branch where you start to go back to if you need to; ie if you are rebasing `foo`, start by running `git branch foo-back` and you can always reset back there if needed.
      - flurdy 4y ago
        Since I often play with razors by rebasing, resetting, cherry picking, etc locally - I created a `git tmp` alias so I can play without fear of needing to go reflog diving again. 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/functions/git-tmp.fish https://github.com/flurdy/dotfiles/blob/master/.config/fish/...
geenat 4y ago
Native large file support. Git annex functionality built in = gg every other source control system.
- WorldMaker 4y ago
  Git annex "competitor" Git LFS is bundled in many distros of git today and supported by most of the major hosting providers at this point (if you are willing to pay for LFS space).
pgt 4y ago
Implicit branching in Pijul is a killer feature (IMO): https://pijul.org/ https://pijul.org/
- japanuspus 4y ago
  Yes, came here to plug Pijul as well: for distributed version control, the "first-class conflicts" of Pijul seems to be a step in the right direction. For anyone who hasn't looked at Pijul, the theory part of the documentation [0] is well worth a read. [0]: https://pijul.org/manual/theory.html https://pijul.org/manual/theory.html
  - vagab0nd 4y ago
    How production-ready is Pijul? I heard about it some time ago and was super impressed. But apparently at the time it had issues, and was going to be re-written in a different language.
    - pmeunier 4y ago
      Wow, you heard about Pijul years ago then. 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.
      - vagab0nd 4y ago
        I did not expect to get an answer from you directly :) I will definitely try it out with my next project!
tedk-42 4y ago
Oh god this author again going after clicks for hit pieces on technology without providing any alternatives. If you think you can do it better then go ahead and try build the product and then pitch it.
- lloydatkinson 4y ago
  What’s wrong with the author?
  - enasterosophes 4y ago
    Well, you can look at the author's past HN submissions to see what was meant. 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.
    - viraptor 4y ago
      Some of us like to read ideas. The blog is more on the personal brand building side, sure. But I'm mainly coming to HN and comments to read what other people think about stuff.
    - vaughan 4y ago
      Why do they have to take responsibility? I can point to so many oss projects where someone else’s vision was implemented.
      - enasterosophes 4y ago
        Confuse "is" vs "ought" much? 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.
- enasterosophes 4y ago
gorgoiler 4y ago
The project management features don’t have to live inside VCS, but it would be nice to sync them there or derive some of the primitive data structures there — comment trees, approvals, CI red/green results at integration time. 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.
- sgbeal 4y ago
  > Which cat meme was deemed appropriate for the final approval of the change? FWIW, that wins my internet for today and i'll aim to make that a factor in any future code reviews/approvals.
madmax108 4y ago
I personally believe that making diffs more human friendly is the next step of evolution we need. I work with a team on a NodeJS+React project and nearly every other PR shows up as "Something changed in package.json, something changed in package-lock.json, some static assets added/modified, some JSON changed" etc and it makes reviewing code quite unwieldy (esp. since it forces folks to use Github UI interface to even see blob diffs. which is quite opinionated on when it collapses a file in the PR, and how it determines what changed in a file). I feel like git was perfect when "code" was nearly almost completely text and patches were sent over email, but there's a lot more boilerplate+blob data that goes into git today and git needs to evolve to support this. 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. [1] https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic
- alexchamberlain 4y ago
  I feel like you may be blaming the tool for a social problem there. We have a simple rule: no changes to package* in a feature PR. Adding a dependency? Cool, upgrade everything first, then add it fresh. (Be reasonable there- the idea is that the add should be clean, so if that can be done without doing a major upgrade, that is of course fine.)
  - bmitc 4y ago
    It sounds like you're just working around the limitations of the tools. 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.
rswail 4y ago
I'd really like issues porcelain that is built over git so that when I clone I get all of the project's history, as well as it being merged with pull requests etc. 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.
- efrecon 4y ago
  Maybe this? https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue. I've always wanted to give it a spin.
- bandie91 4y ago
  i worried about the issues/tickets are centralized, too. so i put them in the repo itself as files and asked contibutors to submit tickets by PR into dedicated subfolder. i'd be worth to standardize it.
- morelisp 4y ago
  For magit users, there's https://github.com/magit/forge https://github.com/magit/forge - ultimately the store of record is still centralized as it's GitHub/GitLab/etc., but it does integrate a local copy of it nicely with your other git operations.
- chriswarbo 4y ago
  I use https://mrzv.org/software/artemis https://mrzv.org/software/artemis 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).
- WorldMaker 4y ago
  On the PR side, I'm pretty strict about PRs requiring merge commits (no fast-forwards/squashes/rebases), because that's a useful in source control history of the PR no matter if you switch hosts. 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.
vaughan 4y ago
I’d love to move away from parent commit hash being included in a commit hash. It makes rewriting history so complex.
- DougWebb 4y ago
  That's kind of the point. The hash guarantees a chain of commits/changes. If you're rewriting history, you're creating a new chain, and all the changes along that chain need to be reverified.
silisili 4y ago
Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. 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.
- indy 4y ago
  I wonder how many centuries of developer time have been wasted trying to "unfuck what I did and go back to a branch"?
  - 8n4vidtmkvmk 4y ago
    hg up --clean i dont know why mercurial doesn't get more love.
    - geenat 4y ago
      It was loved. I blame all the platforms dropping support for it. Github really is git's best PR.
    - javajosh 4y ago
      hg is indeed the better tool. Just as microkernels are the better kernel design. By existing and working (which is no small feat), Linux obliterates both alternatives in the zeitgeist. This is, of course, the great downside to "worse is better".
    - tempest_ 4y ago
      We used hg when I started at my current position. From a developer stand point the experience was better but all the tooling and integrations are git based so we switched.
nathias 4y ago
for all complaining about UX, you can make your custom aliases and install extensions (eg. git undo) ...
- tsimionescu 4y ago
  For all those complaining that this tool box doesn't have any familiar useful tools, you can forge your own tools and use them instead.
irrational 4y ago
> Will a new version control system (or something that solves similar problems) spring up? 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.
- hackernewds 4y ago
  Especially given how primitive git still seems. I, for one, can't wait
aaron695 4y ago
dvh 4y ago
"Talk is cheap, show me the code"
- tsimionescu 4y ago
  Code is cheap, agreeing what problem to fix and how to fix it is the major cost of any software project.
nathants 4y ago
git is like cpp, you have to use a subset: - push - pull - checkout - checkout -b - merge —ff-only - stash - stash pop - reset —hard origin/master - reset —soft $hash - commit -m
- shikoba 4y ago
  > pull I find that command too dangerous. I only use git fetch and git merge --ff-only. You forgot git tag
  - nathants 4y ago
    accurate.
- kjeetgill 4y ago
  Interesting exercise. Mine looks more like: - 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.
  - nathants 4y ago
    lately i’ve been using stash, reset hard, stash pop. work on a single patch over main. use a backup branch prior to stash, just in case.
    - kjeetgill 4y ago
      That's reasonable, but I think a commit + a rebase -i of just that single commit gets you to the same place. And now your backup branch can preserve the code you would have stashed.
deleted 4y ago
[deleted]
pdmccormick 4y ago
Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several unrelated changes though. What's the lesson, that you can learn anything eventually, or that familiarity means you will lose the ability to accurately evaluate something?
- herbst 4y ago
  Same here. I am totally fine with git as it is. If I weren't I maybe would just try one of the hundreds git plugins / clients to see if it better fits my needs.
- krageon 4y ago
  > Am I the only one who thinks that Git's UX is fine [...] No, I think most people that use it are fine with it. But those are usually not the ones you hear :)
  - troppl 4y ago
    Are you really sure that is the case here? I think everyone that starts working with git is a bit hung up by its complexity at least for a year, if not more. 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.
    - throw-ru-938 4y ago
      Come on, getting comfortable with a couple of incantations takes people a whole _year_? Because you don't need much more when you're starting out.
fsiefken 4y ago
Project management and issue tracking can be done with for example an org-mode or taskjuggler file in or outside git.
alenmilk 4y ago
The thing is that git is not supposed to be smart when it comes to merging. https://wincent.com/blog/a-look-back-bram-cohen-vs-linus-torvalds https://wincent.com/blog/a-look-back-bram-cohen-vs-linus-tor... 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.
- tasuki 4y ago
  Yes, better conflict resolution is needed, but outside of scope for git. Do one thing well.
sriku 4y ago
I've been using fossil (https://fossil-scm.org https://fossil-scm.org) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are - 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.
- geenat 4y ago
  How is large file support? What strategy is employed for binary file handling? How does it compare to git LFS / annex / mercurial? Aside from that, Fossil is very intriguing.
  - sgbeal 4y ago
    > How is large file support? 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.)
oftenwrong 4y ago
With regard to repo composition, I have been following this project: https://github.com/josh-project/josh https://github.com/josh-project/josh
knighthack 4y ago
The only major problem I see with Git is that it's just a pain if you're working in a gigantic monorepo. 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.
- sirmarksalot 4y ago
  The large file problem is a major issue in games, and basically means that developers who would much rather use Git, don't have the option of using Git because it would be crushed under the weight of all the art assets. So instead everyone's forced to use Perforce or Subversion, with all the workflow impediments that involves.
  - WorldMaker 4y ago
    A lot of groups with large file problems seem to be converging on Git LFS at this point over Perforce/Subversion. Most of the major hosts (Github, Bitbucket, Gitlab) all have LFS hosting support, though it is not always cheap. (Arguably still cheaper than Perforce/Subversion, especially in accounting for those workflow impediments and the developer time they cost.) 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.)
chriswarbo 4y ago
I like the patch-based approach of Pijul and Darcs: rearranging patches seems less fragile than rebasing snapshots. 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.
- pmeunier 4y ago
  Pijul works quite differently from Darcs: the primary datastructure in Darcs is indeed a list of patches, and the main operation is rearrangement. 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.
ChrisMarshallNY 4y ago
Personally, I’m mostly fine with Git. 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/VersionControlAndTheDeveloper/index.html http://preserve.mactech.com/articles/mactech/Vol.14/14.06/Ve...
mpermar 4y ago
>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level. 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.
- skratlo 4y ago
  Came here to say this, I stopped reading after that, just skimmed the article, it's bunch of horsecrap.
  - emn13 4y ago
    To read this charitably, interpret that statement not to mean that kubernetes-the-software itself is the best gift to OSS collaboration ever, but rather that Kubernetes-the-project "brought open-source collaboration to a new level" in the context of working on kubernetes-the-software. I think that makes more sense, and certainly isn't as pompous.
    - jpgvm 4y ago
      OpenStack had similar levels of contribution at its peak and had much of the same solutions. I'm just guessing the author is newer to the game so might have missed out on 2010-2013 in the infrastructure space. One of the cool things to come out of it was Zuul, which is a merge queue system similar to Bors and friends.
  - damagednoob 4y ago
    I dunno, the points about UX, merge queue and LFS all ring true for me. All those things are solved outside of Git AFAIK.
Xenoamorphous 4y ago
> Kubernetes (the operating system of the cloud) 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!
t43562 4y ago
Version control as a way of distributing and versioning the built code and also of rebuilding it minimally. Goodbye to installers and package managers....and traditional build systems.
i_have_an_idea 4y ago
> Kubernetes (the operating system of the cloud) 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.
- GuB-42 4y ago
  Yes, and it matches the definition of an "operating system". 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.
  - i_have_an_idea 4y ago
    > Yes, and it matches the definition of an "operating system". 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. [1] https://www.britannica.com/technology/operating-system https://www.britannica.com/technology/operating-system [2] https://en.wikipedia.org/wiki/Operating_system https://en.wikipedia.org/wiki/Operating_system
    - 4y ago
polyrand 4y ago
Not related to the problems listed in the blog post, but most of my problems with git went away when I started using worktrees[0] (I do a `--bare` clone and add worktrees in there). 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. [0]: https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree
eternityforest 4y ago
I'm perfectly happy with Git. In the most basic uses, it's extremely easy, get git cola and you're done. The advanced uses are harder than they need to be, but not by that much. There's always google. 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.
ribit 4y ago
My main headache with git — which is absent from the list in the blog – is that it tracks snapshots instead of tracking changes. It's probably less of an issue for software developers where a "version" is what this all is about — after all, that's what you ship, but if you try to use version control in a context of academic writing or data analysis, it can become very difficult to track individual contributions. All git can do is to compare snapshots and allow you to impose a resemblance causal order onto them (which you can freely manipulate anyway with rebasing, squashing etc.). If your workflow consists of trying out many different ideas and then choosing which of them to keep and which to discard, git can be extremely painful — you either end up with a history that is a complete mess or waste a lot of time rebasing and reorganising the (fake anyway) order of snapshots. That's why I am exited for tools like Pijul that attempt to actually track changes.
- CuriousSkeptic 4y ago
  Snapshots do have the advantage of not having to know anything about the data. 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?
  - pmeunier 4y ago
    I'm one of the authors of Pijul, and I have plans to turn it into a synthesis of snapshots and patches, I've implemented the formats and initial steps, see https://pijul.org/posts/2022-01-07-compressed-sanakirja/ https://pijul.org/posts/2022-01-07-compressed-sanakirja/ 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.
lucideer 4y ago
A lot of people responding (in good faith) to the premise of the title but not really engaging with the absolute nonsense points made within it. 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.
- ghoward 4y ago
  > Git repos are as atomic as you make them. 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. :) [1]: https://news.ycombinator.com/item?id=31792303 https://news.ycombinator.com/item?id=31792303
bryanph_ 4y ago
I don't really want Git to change so much. What I do want however is for other tools to take over features from Git. Pretty much every app that I use in my daily life would be enhanced if it had git-like features. My notes on this: https://topictrails.com/app/d/ed47e12a-7cf9-4ec6-8f22-1c9717494fae https://topictrails.com/app/d/ed47e12a-7cf9-4ec6-8f22-1c9717...
jamesrom 4y ago
>GitHub Copilot, but for merge conflicts? Great idea. The corpus of data to train with would be incredible. Every merge commit across all of GitHub.
gigatexal 4y ago
I dunno. I’ve decided like with SystemD to just learn it and get on with life. Git is ubiquitous and so is SystemD. Learn them. Adapt. Move forward. 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.
ziml77 4y ago
The semantic diffing bullet point has me wondering what attempts there are at making open source semantic diff tools. I love the closed source tool SemanticMerge, but the company behind it decided to be shitwads and pull the product so they could add a selling point to their proprietary version control system.
- WorldMaker 4y ago
  Several threads here point to difftastic: https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic I know a lot of people who have a lot of hope for diffsitter (or something like it): https://github.com/afnanenayet/diffsitter 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 https://github.com/WorldMaker/tokdiff
HelloNurse 4y ago
It seems just a promotion for the worst past and future GitHub features of the Microsoft period, starting from intentional confusion between git and GitHub.
samgranieri 4y ago
I've used Git since 2007, and mastered some of the esoteric parts of it a few years ago. I think it's gonna be here to stay for the long haul. 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).
SulphurSmell 4y ago
I wish I could answer this. I have always had a penchant for any robust versioning system. Even the simple ones (CVS and the like) were amazeballs to me at the time. 20 odd years ago I spent a lot of time with ClearCase (initially Rational, now Rational IBM). I was amazed at what could be done. We had dozens of customers, maybe 3 major and 10-14 minor versions in the field, and probably dozens of "bug fix" or "special customer branches". Oh, and likely 2 or 3 on-going major version dev branches. Somehow, it all worked. If you could describe (by whiteboard or hand-waving) what you wanted to see as your working branch, it could be done. "Give me a view that is exactly what customer x has, but for this directory, give me latest, except for this file...I want that one from customer y" . And blam! The CC guys would make it happen. The magical config spec. I have had to dabble in many other SCMs.. SVN, Git, etc...and they all seemed to be a compromise. Or, just ran out of gas when the going got tough. In my mind, I wish I could argue that ClearCase was where it was at, and the patterns it supported would be wonderful to have today...especially over Git. But I don't know enough to defend the point. All I am saying is that even with enormously complex version scenarios, the damn thing didn't break and we all got our work done.
- Art_Wolf 4y ago
  One reason we moved off it was because it was a bandwidth hog! I believe they had two clients to try and help with this, a thin and think client. Even with the thin one, with the CC servers hosted in the states and some developers located in Europe, it would take a half hour for the client to refresh and pull down the latest changes.
  - SulphurSmell 4y ago
    Interesting. It was never an issue for us, as we were close to the CC servers. Some folks were not, so they ran their dev/build locally ("network close" to th CC servers) and VNC'd in from their actual location. In that case, only the stuff on the screen had to transit the "far away" network. Although, I think today, network issues would be less of a thing...as I tend to think that networks have scaled faster than code base size. I could be horribly wrong about that though. Any centralized repo is going to have this challenge though. It also depends on if you prefer snapshot or dynamic views. Snapshots were much easier on the network, at the expense of consistency. I also remember the CC team could work magic at optimizing things if you gave them time and a bit of flexibility. Crappy config specs were hard to read, and often slow to work off of. Any config spec that I had to scroll...I knew I was in for a shit week.
nailer 4y ago
> Semantic diff has been tried before, but language-specific implementations will likely never work. 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.
bvrmn 4y ago
Looks like author has a typo in the title and Git should be read as GitHub.
evouga 4y ago
Auto merge using a “semantic diff” sounds line a complete nightmare to me. 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…
he0001 4y ago
I developed a couple of tools on top of git for various reasons. The problem I found is that many many developers don’t understand how git actually works, so they can’t translate git and what it actually does. I have to explain how git works over and over again. I think git is extremely good compared to everything else and it’s extremely simple yet advanced. But people don’t seem to understand what it actually does. Trying to replace it with something else is going to be hard as I believe that anything more advanced will be hard.
coxley 4y ago
Mercurial solves a lot of the UX problems. Maybe if Meta open-sources the API-compliant rust rewrite, we'll have the scaling sorted too. 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.
brendoncarroll 4y ago
I've been working on a project "Got". Which deals with the LFS problem, mentioned in the post. https://github.com/gotvc/got https://github.com/gotvc/got 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.
ghoward 4y ago
Funnily enough, I'm working on the next Git. (I'm not the author of Pijul; it is another one.) 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. [1]: https://news.ycombinator.com/item?id=31792303 https://news.ycombinator.com/item?id=31792303

227 points by rckrd 4y ago

> I saw the pain points of git (and GitHub) firsthand working on Kubernetes open-source. The article could have been interesting if the author actually expanded on what these pain points are. I'm genuinely curious about those.

EdSchouten 4y ago

- A client side virtual file system (FUSE), so that you can work with large repos that exceed the size of your own system. Version control systems like Piper (Google internal) and Eden (Facebook), GitVFS (Microsoft) already do this, but adoption is marginal.

Ericson2314 4y ago
I really want a system-wide content addressable store that a lot of different things can use.
skybrian 4y ago
Having used Piper, I think the Go package manager's approach is better, actually, at least for a collection of packages maintained by independent teams. 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.
- oivey 4y ago
  This is a good way to put it. I think the opposite is also true: going with many repos means you are committing to other teams being on their own to upgrade. It’s difficult to know if you’ve fixed all downstream code if everything isn’t in one repo. That model makes sense for OSS. Not so sure about within companies.
WorldMaker 4y ago
It's also interesting to note that at this point Microsoft seems to be pivoting away from GitVFS. They've put a lot of collective engineering work in git sparse clones and git partial clones and the intersection of the two ("sparse cones") and optimizations like git commit graph pushing git itself to better at virtualizing its object store, not touching objects it doesn't need, and better handling just-in-time scenarios for object retrieval when it really does need them.

leeoniya 4y ago

> Semantic diff – Can we figure out how to use version control to have more context-aware merges? Can you believe that we still rely on a text diffing algorithm from 1976 (and its shortcomings)? Git still has trouble with file renaming. GitHub Copilot, but for merge conflicts? Semantic diff has been tried before, but language-specific implementations will likely never work. in case anyone missed it: https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic

crmrc114 4y ago
git mv?
- kadoban 4y ago
  That's just a convenience command. Git doesn't actually record moves as anything different from a delete and an add. Many of the querying commands (eg `git log`) use heuristics to show moved files, but they end up wrong fairly often, especially if you don't mess with the parameter(s) of the heuristics.
  - saxonww 4y ago
    In my experience they are correct all of the time for simple renames. It's when you move a file and make substantial edits that it gets confused. 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.
    - Akronymus 4y ago
      Would it make sense to make one commit for the move and one for the changes?
      - bloak 4y ago
        Yes, in some cases, but it depends on your workflow. Some projects require each commit on the main branch to be fully working and pass all the tests.

stellalo 4y ago

> I saw the pain points of git 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

PawBer 4y ago
You can treat the points in the article as those.
spencerchubb 4y ago
that's what the whole rest of the article is about :)
bergenty 4y ago
I’m not qualified to go into specifics but I hate it. All version control needs to do is pull, push and branch. Version on branch is newer? You need to pull down before you can check in. 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.
- oivey 4y ago
  I’m confused. You do have to pull before you check in (aka push new commits)? Those systems don’t exist for backups. They’re for collaboration.
- samtheprogram 4y ago
  These are just different ways to handle the same problem, and the fact that git provides different methods is a good thing. 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.

kache_ 4y ago

Nothing. Keep it simple. There's a reason it has stuck around >inb4 it isn't simple it is

fargle 4y ago
agree. same question as "what comes after C ?" same answer.
- tsimionescu 4y ago
  I'm sure some have written the same about various assembly languages, about COBOL, about FORTRAN, about LISP in AI. 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.
  - fargle 4y ago
    But those aren't good analogies for "C". I think the best analogy is the long-standing belief prior to "C" that assembly would "always" be the systems programming language. Yes, someday a new king will be born (I doubt a coup). 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.
Akronymus 4y ago
The beauty of git is in that it is a simple data structure, with simple functionality.
4y ago

torginus 4y ago

My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.

deleted 4y ago
[deleted]
roganartu 4y ago
Perhaps this is a byproduct of the UI (which I totally agree is bad), but this is not true. `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).
- torginus 4y ago
  You learn something every day!
  - alexchamberlain 4y ago
    Another super simple technique is to create a branch where you start to go back to if you need to; ie if you are rebasing `foo`, start by running `git branch foo-back` and you can always reset back there if needed.
    - flurdy 4y ago
      Since I often play with razors by rebasing, resetting, cherry picking, etc locally - I created a `git tmp` alias so I can play without fear of needing to go reflog diving again. 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/functions/git-tmp.fish https://github.com/flurdy/dotfiles/blob/master/.config/fish/...

geenat 4y ago

Native large file support. Git annex functionality built in = gg every other source control system.

WorldMaker 4y ago
Git annex "competitor" Git LFS is bundled in many distros of git today and supported by most of the major hosting providers at this point (if you are willing to pay for LFS space).

pgt 4y ago

Implicit branching in Pijul is a killer feature (IMO): https://pijul.org/ https://pijul.org/

japanuspus 4y ago
Yes, came here to plug Pijul as well: for distributed version control, the "first-class conflicts" of Pijul seems to be a step in the right direction. For anyone who hasn't looked at Pijul, the theory part of the documentation [0] is well worth a read. [0]: https://pijul.org/manual/theory.html https://pijul.org/manual/theory.html
- vagab0nd 4y ago
  How production-ready is Pijul? I heard about it some time ago and was super impressed. But apparently at the time it had issues, and was going to be re-written in a different language.
  - pmeunier 4y ago
    Wow, you heard about Pijul years ago then. 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.
    - vagab0nd 4y ago
      I did not expect to get an answer from you directly :) I will definitely try it out with my next project!

tedk-42 4y ago

Oh god this author again going after clicks for hit pieces on technology without providing any alternatives. If you think you can do it better then go ahead and try build the product and then pitch it.

lloydatkinson 4y ago
What’s wrong with the author?
- enasterosophes 4y ago
  Well, you can look at the author's past HN submissions to see what was meant. 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.
  - viraptor 4y ago
    Some of us like to read ideas. The blog is more on the personal brand building side, sure. But I'm mainly coming to HN and comments to read what other people think about stuff.
  - vaughan 4y ago
    Why do they have to take responsibility? I can point to so many oss projects where someone else’s vision was implemented.
    - enasterosophes 4y ago
      Confuse "is" vs "ought" much? 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.
enasterosophes 4y ago

gorgoiler 4y ago

The project management features don’t have to live inside VCS, but it would be nice to sync them there or derive some of the primitive data structures there — comment trees, approvals, CI red/green results at integration time. 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.

sgbeal 4y ago
> Which cat meme was deemed appropriate for the final approval of the change? FWIW, that wins my internet for today and i'll aim to make that a factor in any future code reviews/approvals.

madmax108 4y ago

I personally believe that making diffs more human friendly is the next step of evolution we need. I work with a team on a NodeJS+React project and nearly every other PR shows up as "Something changed in package.json, something changed in package-lock.json, some static assets added/modified, some JSON changed" etc and it makes reviewing code quite unwieldy (esp. since it forces folks to use Github UI interface to even see blob diffs. which is quite opinionated on when it collapses a file in the PR, and how it determines what changed in a file). I feel like git was perfect when "code" was nearly almost completely text and patches were sent over email, but there's a lot more boilerplate+blob data that goes into git today and git needs to evolve to support this. 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. [1] https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic

alexchamberlain 4y ago
I feel like you may be blaming the tool for a social problem there. We have a simple rule: no changes to package* in a feature PR. Adding a dependency? Cool, upgrade everything first, then add it fresh. (Be reasonable there- the idea is that the add should be clean, so if that can be done without doing a major upgrade, that is of course fine.)
- bmitc 4y ago
  It sounds like you're just working around the limitations of the tools. 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.

rswail 4y ago

I'd really like issues porcelain that is built over git so that when I clone I get all of the project's history, as well as it being merged with pull requests etc. 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.

efrecon 4y ago
Maybe this? https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue. I've always wanted to give it a spin.
bandie91 4y ago
i worried about the issues/tickets are centralized, too. so i put them in the repo itself as files and asked contibutors to submit tickets by PR into dedicated subfolder. i'd be worth to standardize it.
morelisp 4y ago
For magit users, there's https://github.com/magit/forge https://github.com/magit/forge - ultimately the store of record is still centralized as it's GitHub/GitLab/etc., but it does integrate a local copy of it nicely with your other git operations.
chriswarbo 4y ago
I use https://mrzv.org/software/artemis https://mrzv.org/software/artemis 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).
WorldMaker 4y ago
On the PR side, I'm pretty strict about PRs requiring merge commits (no fast-forwards/squashes/rebases), because that's a useful in source control history of the PR no matter if you switch hosts. 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.

vaughan 4y ago

I’d love to move away from parent commit hash being included in a commit hash. It makes rewriting history so complex.

DougWebb 4y ago
That's kind of the point. The hash guarantees a chain of commits/changes. If you're rewriting history, you're creating a new chain, and all the changes along that chain need to be reverified.

silisili 4y ago

Every time I use Git, I see how bad the UX is and marvel at how it ever became popular. 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.

indy 4y ago
I wonder how many centuries of developer time have been wasted trying to "unfuck what I did and go back to a branch"?
- 8n4vidtmkvmk 4y ago
  hg up --clean i dont know why mercurial doesn't get more love.
  - geenat 4y ago
    It was loved. I blame all the platforms dropping support for it. Github really is git's best PR.
  - javajosh 4y ago
    hg is indeed the better tool. Just as microkernels are the better kernel design. By existing and working (which is no small feat), Linux obliterates both alternatives in the zeitgeist. This is, of course, the great downside to "worse is better".
  - tempest_ 4y ago
    We used hg when I started at my current position. From a developer stand point the experience was better but all the tooling and integrations are git based so we switched.

nathias 4y ago

for all complaining about UX, you can make your custom aliases and install extensions (eg. git undo) ...

tsimionescu 4y ago
For all those complaining that this tool box doesn't have any familiar useful tools, you can forge your own tools and use them instead.

irrational 4y ago

> Will a new version control system (or something that solves similar problems) spring up? 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.

hackernewds 4y ago
Especially given how primitive git still seems. I, for one, can't wait

aaron695 4y ago

dvh 4y ago

"Talk is cheap, show me the code"

tsimionescu 4y ago
Code is cheap, agreeing what problem to fix and how to fix it is the major cost of any software project.

nathants 4y ago

git is like cpp, you have to use a subset: - push - pull - checkout - checkout -b - merge —ff-only - stash - stash pop - reset —hard origin/master - reset —soft $hash - commit -m

shikoba 4y ago
> pull I find that command too dangerous. I only use git fetch and git merge --ff-only. You forgot git tag
- nathants 4y ago
  accurate.
kjeetgill 4y ago
Interesting exercise. Mine looks more like: - 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.
- nathants 4y ago
  lately i’ve been using stash, reset hard, stash pop. work on a single patch over main. use a backup branch prior to stash, just in case.
  - kjeetgill 4y ago
    That's reasonable, but I think a commit + a rebase -i of just that single commit gets you to the same place. And now your backup branch can preserve the code you would have stashed.

deleted 4y ago

[deleted]

pdmccormick 4y ago

Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several unrelated changes though. What's the lesson, that you can learn anything eventually, or that familiarity means you will lose the ability to accurately evaluate something?

herbst 4y ago
Same here. I am totally fine with git as it is. If I weren't I maybe would just try one of the hundreds git plugins / clients to see if it better fits my needs.
krageon 4y ago
> Am I the only one who thinks that Git's UX is fine [...] No, I think most people that use it are fine with it. But those are usually not the ones you hear :)
- troppl 4y ago
  Are you really sure that is the case here? I think everyone that starts working with git is a bit hung up by its complexity at least for a year, if not more. 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.
  - throw-ru-938 4y ago
    Come on, getting comfortable with a couple of incantations takes people a whole _year_? Because you don't need much more when you're starting out.

fsiefken 4y ago

Project management and issue tracking can be done with for example an org-mode or taskjuggler file in or outside git.

alenmilk 4y ago

The thing is that git is not supposed to be smart when it comes to merging. https://wincent.com/blog/a-look-back-bram-cohen-vs-linus-torvalds https://wincent.com/blog/a-look-back-bram-cohen-vs-linus-tor... 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.

tasuki 4y ago
Yes, better conflict resolution is needed, but outside of scope for git. Do one thing well.

sriku 4y ago

I've been using fossil (https://fossil-scm.org https://fossil-scm.org) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are - 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.

geenat 4y ago
How is large file support? What strategy is employed for binary file handling? How does it compare to git LFS / annex / mercurial? Aside from that, Fossil is very intriguing.
- sgbeal 4y ago
  > How is large file support? 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.)

oftenwrong 4y ago

With regard to repo composition, I have been following this project: https://github.com/josh-project/josh https://github.com/josh-project/josh

knighthack 4y ago

The only major problem I see with Git is that it's just a pain if you're working in a gigantic monorepo. 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.

sirmarksalot 4y ago
The large file problem is a major issue in games, and basically means that developers who would much rather use Git, don't have the option of using Git because it would be crushed under the weight of all the art assets. So instead everyone's forced to use Perforce or Subversion, with all the workflow impediments that involves.
- WorldMaker 4y ago
  A lot of groups with large file problems seem to be converging on Git LFS at this point over Perforce/Subversion. Most of the major hosts (Github, Bitbucket, Gitlab) all have LFS hosting support, though it is not always cheap. (Arguably still cheaper than Perforce/Subversion, especially in accounting for those workflow impediments and the developer time they cost.) 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.)

chriswarbo 4y ago

I like the patch-based approach of Pijul and Darcs: rearranging patches seems less fragile than rebasing snapshots. 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.

pmeunier 4y ago
Pijul works quite differently from Darcs: the primary datastructure in Darcs is indeed a list of patches, and the main operation is rearrangement. 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.

ChrisMarshallNY 4y ago

Personally, I’m mostly fine with Git. 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/VersionControlAndTheDeveloper/index.html http://preserve.mactech.com/articles/mactech/Vol.14/14.06/Ve...

mpermar 4y ago

>Nearly a decade later, new problems arose when Kubernetes (the operating system of the cloud) brought open-source collaboration to a new level. 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.

skratlo 4y ago
Came here to say this, I stopped reading after that, just skimmed the article, it's bunch of horsecrap.
- emn13 4y ago
  To read this charitably, interpret that statement not to mean that kubernetes-the-software itself is the best gift to OSS collaboration ever, but rather that Kubernetes-the-project "brought open-source collaboration to a new level" in the context of working on kubernetes-the-software. I think that makes more sense, and certainly isn't as pompous.
  - jpgvm 4y ago
    OpenStack had similar levels of contribution at its peak and had much of the same solutions. I'm just guessing the author is newer to the game so might have missed out on 2010-2013 in the infrastructure space. One of the cool things to come out of it was Zuul, which is a merge queue system similar to Bors and friends.
- damagednoob 4y ago
  I dunno, the points about UX, merge queue and LFS all ring true for me. All those things are solved outside of Git AFAIK.

Xenoamorphous 4y ago

> Kubernetes (the operating system of the cloud) 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!

t43562 4y ago

Version control as a way of distributing and versioning the built code and also of rebuilding it minimally. Goodbye to installers and package managers....and traditional build systems.

i_have_an_idea 4y ago

> Kubernetes (the operating system of the cloud) 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.

GuB-42 4y ago
Yes, and it matches the definition of an "operating system". 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.
- i_have_an_idea 4y ago
  > Yes, and it matches the definition of an "operating system". 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. [1] https://www.britannica.com/technology/operating-system https://www.britannica.com/technology/operating-system [2] https://en.wikipedia.org/wiki/Operating_system https://en.wikipedia.org/wiki/Operating_system
  - 4y ago

polyrand 4y ago

Not related to the problems listed in the blog post, but most of my problems with git went away when I started using worktrees[0] (I do a `--bare` clone and add worktrees in there). 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. [0]: https://git-scm.com/docs/git-worktree https://git-scm.com/docs/git-worktree

eternityforest 4y ago

I'm perfectly happy with Git. In the most basic uses, it's extremely easy, get git cola and you're done. The advanced uses are harder than they need to be, but not by that much. There's always google. 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.

ribit 4y ago

My main headache with git — which is absent from the list in the blog – is that it tracks snapshots instead of tracking changes. It's probably less of an issue for software developers where a "version" is what this all is about — after all, that's what you ship, but if you try to use version control in a context of academic writing or data analysis, it can become very difficult to track individual contributions. All git can do is to compare snapshots and allow you to impose a resemblance causal order onto them (which you can freely manipulate anyway with rebasing, squashing etc.). If your workflow consists of trying out many different ideas and then choosing which of them to keep and which to discard, git can be extremely painful — you either end up with a history that is a complete mess or waste a lot of time rebasing and reorganising the (fake anyway) order of snapshots. That's why I am exited for tools like Pijul that attempt to actually track changes.

CuriousSkeptic 4y ago
Snapshots do have the advantage of not having to know anything about the data. 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?
- pmeunier 4y ago
  I'm one of the authors of Pijul, and I have plans to turn it into a synthesis of snapshots and patches, I've implemented the formats and initial steps, see https://pijul.org/posts/2022-01-07-compressed-sanakirja/ https://pijul.org/posts/2022-01-07-compressed-sanakirja/ 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.

lucideer 4y ago

A lot of people responding (in good faith) to the premise of the title but not really engaging with the absolute nonsense points made within it. 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.

ghoward 4y ago
> Git repos are as atomic as you make them. 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. :) [1]: https://news.ycombinator.com/item?id=31792303 https://news.ycombinator.com/item?id=31792303

bryanph_ 4y ago

I don't really want Git to change so much. What I do want however is for other tools to take over features from Git. Pretty much every app that I use in my daily life would be enhanced if it had git-like features. My notes on this: https://topictrails.com/app/d/ed47e12a-7cf9-4ec6-8f22-1c9717494fae https://topictrails.com/app/d/ed47e12a-7cf9-4ec6-8f22-1c9717...

jamesrom 4y ago

>GitHub Copilot, but for merge conflicts? Great idea. The corpus of data to train with would be incredible. Every merge commit across all of GitHub.

gigatexal 4y ago

I dunno. I’ve decided like with SystemD to just learn it and get on with life. Git is ubiquitous and so is SystemD. Learn them. Adapt. Move forward. 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.

ziml77 4y ago

The semantic diffing bullet point has me wondering what attempts there are at making open source semantic diff tools. I love the closed source tool SemanticMerge, but the company behind it decided to be shitwads and pull the product so they could add a selling point to their proprietary version control system.

WorldMaker 4y ago
Several threads here point to difftastic: https://github.com/Wilfred/difftastic https://github.com/Wilfred/difftastic I know a lot of people who have a lot of hope for diffsitter (or something like it): https://github.com/afnanenayet/diffsitter 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 https://github.com/WorldMaker/tokdiff

HelloNurse 4y ago

It seems just a promotion for the worst past and future GitHub features of the Microsoft period, starting from intentional confusion between git and GitHub.

samgranieri 4y ago

I've used Git since 2007, and mastered some of the esoteric parts of it a few years ago. I think it's gonna be here to stay for the long haul. 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).

SulphurSmell 4y ago

I wish I could answer this. I have always had a penchant for any robust versioning system. Even the simple ones (CVS and the like) were amazeballs to me at the time. 20 odd years ago I spent a lot of time with ClearCase (initially Rational, now Rational IBM). I was amazed at what could be done. We had dozens of customers, maybe 3 major and 10-14 minor versions in the field, and probably dozens of "bug fix" or "special customer branches". Oh, and likely 2 or 3 on-going major version dev branches. Somehow, it all worked. If you could describe (by whiteboard or hand-waving) what you wanted to see as your working branch, it could be done. "Give me a view that is exactly what customer x has, but for this directory, give me latest, except for this file...I want that one from customer y" . And blam! The CC guys would make it happen. The magical config spec. I have had to dabble in many other SCMs.. SVN, Git, etc...and they all seemed to be a compromise. Or, just ran out of gas when the going got tough. In my mind, I wish I could argue that ClearCase was where it was at, and the patterns it supported would be wonderful to have today...especially over Git. But I don't know enough to defend the point. All I am saying is that even with enormously complex version scenarios, the damn thing didn't break and we all got our work done.

Art_Wolf 4y ago
One reason we moved off it was because it was a bandwidth hog! I believe they had two clients to try and help with this, a thin and think client. Even with the thin one, with the CC servers hosted in the states and some developers located in Europe, it would take a half hour for the client to refresh and pull down the latest changes.
- SulphurSmell 4y ago
  Interesting. It was never an issue for us, as we were close to the CC servers. Some folks were not, so they ran their dev/build locally ("network close" to th CC servers) and VNC'd in from their actual location. In that case, only the stuff on the screen had to transit the "far away" network. Although, I think today, network issues would be less of a thing...as I tend to think that networks have scaled faster than code base size. I could be horribly wrong about that though. Any centralized repo is going to have this challenge though. It also depends on if you prefer snapshot or dynamic views. Snapshots were much easier on the network, at the expense of consistency. I also remember the CC team could work magic at optimizing things if you gave them time and a bit of flexibility. Crappy config specs were hard to read, and often slow to work off of. Any config spec that I had to scroll...I knew I was in for a shit week.

nailer 4y ago

> Semantic diff has been tried before, but language-specific implementations will likely never work. 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.

bvrmn 4y ago

Looks like author has a typo in the title and Git should be read as GitHub.

evouga 4y ago

Auto merge using a “semantic diff” sounds line a complete nightmare to me. 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…

he0001 4y ago

I developed a couple of tools on top of git for various reasons. The problem I found is that many many developers don’t understand how git actually works, so they can’t translate git and what it actually does. I have to explain how git works over and over again. I think git is extremely good compared to everything else and it’s extremely simple yet advanced. But people don’t seem to understand what it actually does. Trying to replace it with something else is going to be hard as I believe that anything more advanced will be hard.

coxley 4y ago

Mercurial solves a lot of the UX problems. Maybe if Meta open-sources the API-compliant rust rewrite, we'll have the scaling sorted too. 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.

brendoncarroll 4y ago

I've been working on a project "Got". Which deals with the LFS problem, mentioned in the post. https://github.com/gotvc/got https://github.com/gotvc/got 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.

ghoward 4y ago

Funnily enough, I'm working on the next Git. (I'm not the author of Pijul; it is another one.) 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. [1]: https://news.ycombinator.com/item?id=31792303 https://news.ycombinator.com/item?id=31792303