4 ms·

the world if filled with "good enough" tools and I don't foresee that ever changing tbh. You'd have to offer something really substantially better than the stat

the world if filled with "good enough" tools and I don't foresee that ever changing tbh. You'd have to offer something really substantially better than the status quo to gain critical mass. That being said, I think the only thing about git that doesn't make reasonable sense are the damn command line flags and subcommand names. The actual semantics of git are pretty much exactly what you want for source control.

stevage 2y ago
Nah, git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. There is a lot of state that is not recorded anywhere - history lost forever. The rebase vs merge disaster. Etc etc.
- pc86 2y ago
  This will sound flippant but it's an honest question: who cares? I use git all day, every day. Sometimes CLI, sometimes a dedicated UI (e.g. GH desktop but have also used Tower and other dedicated tools), sometimes a UI in something else a la VSCode. I write code every day. Why should I care at all about rebase vs. merge, whether the internals of git are optimal, whether index needs to exist at all or what it even is? I think this is sort of what the other comment is getting at about a replacement needing to be much better and that git is good enough. I can count on one hand the number times I've ever needed to glean information out of old commit messages and when something got merged into something else. Arguing about git workflows and whether you should rebase, merge, squash merge, trunk deployment, gitflow, etc. all seems like ultimate bikeshedding to me. If you're shipping code and making money your git workflow is irrelevant. If your project is so convoluted and broken and you're gaining actual useful information from a 2-year old commit message that you couldn't get just by looking at the code it feels like something else is fundamentally broken that better git internals are not going to address.
  - rob74 2y ago
    I would care if a new VCS would make my life easier. This quote from the linked article: > very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more. ...pretty much describes me TBH. I know enough of git to get by day to day, but if I need to do more than that, I have to rely on StackOverflow et al. Which is always frustrating and feels like a waste of time.
    - stevage 2y ago
      I have used git for many years, have over 250 repos on GitHub and have written several blog posts about it. This is definitely me. I will never understand it.
    - pc86 2y ago
      I would try a new VCS if it made my life easier too, but I think my point is just that the quote you posted is not only accurate for most developers, but that there's nothing wrong with that. Having a perfect mental model of how git works is going to be a waste of time for anyone who doesn't want to actually work on git itself.
  - steveklabnik 2y ago
    I mean, you can use this logic to favor the status quo in any given circumstance. Some people are of course happy with that, but some folks want to try and improve. Not everyone has to care, but not everyone has to not care, either. I swapped to jj because it’s both easier to use and more powerful than git. To me, anyway. And I was a “you can take git from my cold dead fingers” type person. A “the git cli is fine” type of person.
  - stevage 2y ago
    That's all well and good if a) you almost always work in the same repo; or B) you are in charge of the repos you work in. Often these are not true for me. I have no deal with other people's repos, dealing with merge or rebase depending on their conventions etc.
- packetlost 2y ago
  > git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. The index is a useful tool. You can opt out with `git commit -a` > There is a lot of state that is not recorded anywhere Examples? > The rebase vs merge disaster ??? How is this a disaster? They serve different purposes and have entirely different semantics. You can use rebase to force fast-forward merges (which do not create merge commits), but I fail to see how this is a disaster.
  - steveklabnik 2y ago
    (Not your original parent, my take) > The index is a useful tool To be clear, jj retains the full power of the git index, without having one. To use git terms, the index is just a normal commit like any other. The index is one of my favorite features of git. I don’t miss it in jj. > Examples? For one… the index! It’s not part of your history. The working directory can contain dirty state that’s not tracked anywhere. Those are the big two off the top of my head. > how is this a disaster? I’m on your side with this one, and jj supports both just fine.
  - CJefferson 2y ago
    My main issues with git are all about version control of branches. Which branches were commits originally created on. What commit was branch X on 2 weeks in the past? (My personal biggest issue) -- there is no way to delete a branch in a version-controlled way (that is, let me un-delete it later). 'reflogs' don't count, I want to be able to version-control my branch deletions. And if people (I'm not accusing you, person I'm replying to, but I get this a lot) say "git isn't for that", well then it's really annoying that git has become "the version control system for everything".
  - sunshowers 2y ago
    To my knowledge there is nothing the git index can do that Jujutsu can't, in a more sensible fashion.
  - kazinator 2y ago
    You cannot "opt out" of the index. It's always sitting there. $ ls -l .git/index When it gets corrupt, though, you can blow it away. It gets rebuilt. The reason it can be casually rebuilt is that there is a copy of it in the HEAD commit. The git index is an intestinal appendix. It has no reason to exist. There is no need to "stage" changes and then move them to a commit. What is called staging should just create a new commit. The index creates duplicity. Many commands operate on both the work tree and index, or separately on either one. Your working tree can differ from the index, which differs from the HEAD commit, so then you have "git diff" (tree to index), "git diff --cached" (index to HEAD) and "git diff HEAD" (tree to HEAD). What's the point of staging a commit, when a commit can be amended? You need staging for something that cannot be easily fixed once it is deployed.
alkonaut 2y ago
There was a time when a VCS could just be a slightly better VCS and it could probably gain traction. But now, for both better and worse, git is no longer just an app or a tool, it’s just a fundamental library and protocol that IDE:s, Build systems and project/work management systems build on. It has become almost too late to change. The semantics of git are “ok”, but mostly it’s just a big leap ahead of cvs and Subversion. As always in any git thread we’ll see people (including me) expressing hope that Pijul will one day be successful enough to break the git monopoly.
- alephnerd 2y ago
  > There was a time when a VCS could just be a slightly better VCS and it could probably gain traction That was also a time when the entire software development industry numbered at most 50,000 globally and was still a nascent industry.
rob74 2y ago
Jujutsu tries to avoid that by being compatible with git. Quote from https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/essays/jj-init/: > I have been using the Git backend for the last seven months, full time, on every one of my personal repositories and all the open source projects I have contributed to. With the sole exception of someone watching me while we pair, no one has noticed, because the Git integration is that solid and robust. This interop means that adoption can be very low friction. Any individual can simply run jj git init --git-repo . in a given Git repository, and start doing their work with Jujutsu instead of Git, and all that work gets translated directly into operations on the Git repository. Well that sounds... pretty good actually! Makes me want to try it too...
- steveklabnik 2y ago
  It’s been about five months of the same for me.
  - stouset 2y ago
    Three or four for me. Or, however long since there was a jj introduction posted here that got some traction. The only person on my team who’s even aware is the one other person I converted. The interop is that smooth. I feel like you and I must have the same taste in technologies. I got into Rails (and Ruby itself) around 2007 then fell in love with Rust around 1.0. Now here I find out you’re a jj convert too! Please let me know the next thing in advance ;)
    - steveklabnik 2y ago
      Ha! <3 ... I want it to be buck2, but I'm still not quite sure how exactly stuff is shaking out. If the open source prelude was better, I'd use it over Cargo.

stevage 2y ago

Nah, git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. There is a lot of state that is not recorded anywhere - history lost forever. The rebase vs merge disaster. Etc etc.

pc86 2y ago
This will sound flippant but it's an honest question: who cares? I use git all day, every day. Sometimes CLI, sometimes a dedicated UI (e.g. GH desktop but have also used Tower and other dedicated tools), sometimes a UI in something else a la VSCode. I write code every day. Why should I care at all about rebase vs. merge, whether the internals of git are optimal, whether index needs to exist at all or what it even is? I think this is sort of what the other comment is getting at about a replacement needing to be much better and that git is good enough. I can count on one hand the number times I've ever needed to glean information out of old commit messages and when something got merged into something else. Arguing about git workflows and whether you should rebase, merge, squash merge, trunk deployment, gitflow, etc. all seems like ultimate bikeshedding to me. If you're shipping code and making money your git workflow is irrelevant. If your project is so convoluted and broken and you're gaining actual useful information from a 2-year old commit message that you couldn't get just by looking at the code it feels like something else is fundamentally broken that better git internals are not going to address.
- rob74 2y ago
  I would care if a new VCS would make my life easier. This quote from the linked article: > very few working developers have a good mental model for Git. Instead, they have a handful of commands they have learned over the years: enough to get by, and little more. ...pretty much describes me TBH. I know enough of git to get by day to day, but if I need to do more than that, I have to rely on StackOverflow et al. Which is always frustrating and feels like a waste of time.
  - stevage 2y ago
    I have used git for many years, have over 250 repos on GitHub and have written several blog posts about it. This is definitely me. I will never understand it.
  - pc86 2y ago
    I would try a new VCS if it made my life easier too, but I think my point is just that the quote you posted is not only accurate for most developers, but that there's nothing wrong with that. Having a perfect mental model of how git works is going to be a waste of time for anyone who doesn't want to actually work on git itself.
- steveklabnik 2y ago
  I mean, you can use this logic to favor the status quo in any given circumstance. Some people are of course happy with that, but some folks want to try and improve. Not everyone has to care, but not everyone has to not care, either. I swapped to jj because it’s both easier to use and more powerful than git. To me, anyway. And I was a “you can take git from my cold dead fingers” type person. A “the git cli is fine” type of person.
- stevage 2y ago
  That's all well and good if a) you almost always work in the same repo; or B) you are in charge of the repos you work in. Often these are not true for me. I have no deal with other people's repos, dealing with merge or rebase depending on their conventions etc.
packetlost 2y ago
> git has lots of bad design choices that are deeper than UI. The index doesn't need to exist. The index is a useful tool. You can opt out with `git commit -a` > There is a lot of state that is not recorded anywhere Examples? > The rebase vs merge disaster ??? How is this a disaster? They serve different purposes and have entirely different semantics. You can use rebase to force fast-forward merges (which do not create merge commits), but I fail to see how this is a disaster.
- steveklabnik 2y ago
  (Not your original parent, my take) > The index is a useful tool To be clear, jj retains the full power of the git index, without having one. To use git terms, the index is just a normal commit like any other. The index is one of my favorite features of git. I don’t miss it in jj. > Examples? For one… the index! It’s not part of your history. The working directory can contain dirty state that’s not tracked anywhere. Those are the big two off the top of my head. > how is this a disaster? I’m on your side with this one, and jj supports both just fine.
- CJefferson 2y ago
  My main issues with git are all about version control of branches. Which branches were commits originally created on. What commit was branch X on 2 weeks in the past? (My personal biggest issue) -- there is no way to delete a branch in a version-controlled way (that is, let me un-delete it later). 'reflogs' don't count, I want to be able to version-control my branch deletions. And if people (I'm not accusing you, person I'm replying to, but I get this a lot) say "git isn't for that", well then it's really annoying that git has become "the version control system for everything".
- sunshowers 2y ago
  To my knowledge there is nothing the git index can do that Jujutsu can't, in a more sensible fashion.
- kazinator 2y ago
  You cannot "opt out" of the index. It's always sitting there. $ ls -l .git/index When it gets corrupt, though, you can blow it away. It gets rebuilt. The reason it can be casually rebuilt is that there is a copy of it in the HEAD commit. The git index is an intestinal appendix. It has no reason to exist. There is no need to "stage" changes and then move them to a commit. What is called staging should just create a new commit. The index creates duplicity. Many commands operate on both the work tree and index, or separately on either one. Your working tree can differ from the index, which differs from the HEAD commit, so then you have "git diff" (tree to index), "git diff --cached" (index to HEAD) and "git diff HEAD" (tree to HEAD). What's the point of staging a commit, when a commit can be amended? You need staging for something that cannot be easily fixed once it is deployed.

alkonaut 2y ago

There was a time when a VCS could just be a slightly better VCS and it could probably gain traction. But now, for both better and worse, git is no longer just an app or a tool, it’s just a fundamental library and protocol that IDE:s, Build systems and project/work management systems build on. It has become almost too late to change. The semantics of git are “ok”, but mostly it’s just a big leap ahead of cvs and Subversion. As always in any git thread we’ll see people (including me) expressing hope that Pijul will one day be successful enough to break the git monopoly.

alephnerd 2y ago
> There was a time when a VCS could just be a slightly better VCS and it could probably gain traction That was also a time when the entire software development industry numbered at most 50,000 globally and was still a nascent industry.

rob74 2y ago

Jujutsu tries to avoid that by being compatible with git. Quote from https://v5.chriskrycho.com/essays/jj-init/ https://v5.chriskrycho.com/essays/jj-init/: > I have been using the Git backend for the last seven months, full time, on every one of my personal repositories and all the open source projects I have contributed to. With the sole exception of someone watching me while we pair, no one has noticed, because the Git integration is that solid and robust. This interop means that adoption can be very low friction. Any individual can simply run jj git init --git-repo . in a given Git repository, and start doing their work with Jujutsu instead of Git, and all that work gets translated directly into operations on the Git repository. Well that sounds... pretty good actually! Makes me want to try it too...

steveklabnik 2y ago
It’s been about five months of the same for me.
- stouset 2y ago
  Three or four for me. Or, however long since there was a jj introduction posted here that got some traction. The only person on my team who’s even aware is the one other person I converted. The interop is that smooth. I feel like you and I must have the same taste in technologies. I got into Rails (and Ruby itself) around 2007 then fell in love with Rust around 1.0. Now here I find out you’re a jj convert too! Please let me know the next thing in advance ;)
  - steveklabnik 2y ago
    Ha! <3 ... I want it to be buck2, but I'm still not quite sure how exactly stuff is shaking out. If the open source prelude was better, I'd use it over Cargo.