5 ms·

One showstopper for me is that Jujutsu doesn’t support .gitattributes (https://jj-vcs.github.io/jj/latest/git-compatibility/ https://jj-vcs.github.io/jj/latest/

by layer8 1y ago

One showstopper for me is that Jujutsu doesn’t support .gitattributes (https://jj-vcs.github.io/jj/latest/git-compatibility/ https://jj-vcs.github.io/jj/latest/git-compatibility/).

verdverm 1y ago
or LFS, hooks, submodules, shallow clones
- odie5533 1y ago
  So it doesn't have most of the worst features git ever invented. Got it.
  - Cthulhu_ 1y ago
    I can understand the criticism to submodules but the rest of your comment feels like unwarranted snark.
    - odie5533 1y ago
      Hooks, submodules, and LFS all have huge followings of haters. I think just a week ago there was a big post on HN about how awful LFS is.
      - SAI_Peregrinus 1y ago
        LFS is pretty crap, but the problem it tries to solve is real: version control should be able to control all the sources of the application, not just the text-based sources. Even if it can't meaningfully "diff" between them.
  - wolvesechoes 1y ago
    [flagged]
    - lmm 1y ago
      I'm all for functionality, but git should never have been a smorgasbord of random bolt-on special cases. If you have to break the basic core functionality to make a feature work, it's not a good feature.
    - odie5533 1y ago
      I never said jj was awesome. I've never used it. I'm already adept at git, enough to have opinions on its advanced features, and the knowledge to avoid them, so I'm not sure if I'd gain all that much from jj.
mdaniel 1y ago
In every one of these threads I learn some new axis of git that JJ doesn't support, so I really do wonder if JJ should have squatted upon a different DVCS given how much it wants to do things the JJ way leading to folks with git experience being sad
- nchmy 1y ago
  nah, git was absolutely the right thing to squat on - its ubiquitous, so making it seamlessly powerful and easy to use makes for easy adoption. If it was built on pijul or whatever, I'd never have given it a try. to the extent that niche things might not be supported (yet), so be it. It suits the needs of the vast majority of people. Moreover, if you need those things, I BET you can just do it via git and then carry on working in jj, since jj sits on top of git
- sunshowers 1y ago
  Ehh these are mostly edge case features that are very important to some, but not relevant to most. I've been using Jujutsu full time with dozens of repos and the only one that's come close to mattering is submodules (which are easy to work around with a colocated repo + `git submodule update`). CRLF autoconversions especially shouldn't have been supported, imho. Git on Windows's default setup still converts LF to CRLF to this day, even though every program on Windows has understood LF for a number of years.
- digianarchist 1y ago
  Adoption probability without git squatting would be virtually zero.
odie5533 1y ago
.gitattributes has only caused me trouble, so I wouldn't really miss it. IMO it's a footgun.
- layer8 1y ago
  It's the only way to ensure proper cross-platform EOL handling when you can't rely on users configuring their local Git appropriately. Of course, it also requires users to use the official Git client, so that .gitattributes are actually observed. But that's more likely to be the case in practice.
  - sunshowers 1y ago
    The correct way to do cross-platform EOL handling is to use LF for all files on all platforms, and enforce that via hooks or CI. Every program on Windows, including the humble Notepad, understands LF these days. Git for Windows configures core.autocrlf to true by default. This is a terrible idea, imho. "input" is a bit more justifiable.
    - layer8 1y ago
      If you have to deploy or test with CRLF files, you can’t force LF for all files. This isn’t about editors, but about files to be deployed on customer systems, and/or to be used in tests, where the interfacing software has other requirements. You also have to use .gitattributes to reliably define which files to treat as text files in the first place. And you’d have to define your hooks and CI checks to be consistent with that. Note that Git always converts CRLF to LF upon check-in for defined-to-be-text files, even on Unix. I agree that the default on Windows is wrong. “Input” isn’t much better.
      - sunshowers 1y ago
        Tests that require CRLF should transform files as appropriate within a temporary directory. That way the costs of non-standard line endings are borne by the places that need it, as opposed to by all tooling in perpetuity.

by layer8 1y ago

One showstopper for me is that Jujutsu doesn’t support .gitattributes (https://jj-vcs.github.io/jj/latest/git-compatibility/ https://jj-vcs.github.io/jj/latest/git-compatibility/).

verdverm 1y ago

or LFS, hooks, submodules, shallow clones

odie5533 1y ago
So it doesn't have most of the worst features git ever invented. Got it.
- Cthulhu_ 1y ago
  I can understand the criticism to submodules but the rest of your comment feels like unwarranted snark.
  - odie5533 1y ago
    Hooks, submodules, and LFS all have huge followings of haters. I think just a week ago there was a big post on HN about how awful LFS is.
    - SAI_Peregrinus 1y ago
      LFS is pretty crap, but the problem it tries to solve is real: version control should be able to control all the sources of the application, not just the text-based sources. Even if it can't meaningfully "diff" between them.
- wolvesechoes 1y ago
  [flagged]
  - lmm 1y ago
    I'm all for functionality, but git should never have been a smorgasbord of random bolt-on special cases. If you have to break the basic core functionality to make a feature work, it's not a good feature.
  - odie5533 1y ago
    I never said jj was awesome. I've never used it. I'm already adept at git, enough to have opinions on its advanced features, and the knowledge to avoid them, so I'm not sure if I'd gain all that much from jj.

mdaniel 1y ago

In every one of these threads I learn some new axis of git that JJ doesn't support, so I really do wonder if JJ should have squatted upon a different DVCS given how much it wants to do things the JJ way leading to folks with git experience being sad

nchmy 1y ago
nah, git was absolutely the right thing to squat on - its ubiquitous, so making it seamlessly powerful and easy to use makes for easy adoption. If it was built on pijul or whatever, I'd never have given it a try. to the extent that niche things might not be supported (yet), so be it. It suits the needs of the vast majority of people. Moreover, if you need those things, I BET you can just do it via git and then carry on working in jj, since jj sits on top of git
sunshowers 1y ago
Ehh these are mostly edge case features that are very important to some, but not relevant to most. I've been using Jujutsu full time with dozens of repos and the only one that's come close to mattering is submodules (which are easy to work around with a colocated repo + `git submodule update`). CRLF autoconversions especially shouldn't have been supported, imho. Git on Windows's default setup still converts LF to CRLF to this day, even though every program on Windows has understood LF for a number of years.
digianarchist 1y ago
Adoption probability without git squatting would be virtually zero.

odie5533 1y ago

.gitattributes has only caused me trouble, so I wouldn't really miss it. IMO it's a footgun.

layer8 1y ago
It's the only way to ensure proper cross-platform EOL handling when you can't rely on users configuring their local Git appropriately. Of course, it also requires users to use the official Git client, so that .gitattributes are actually observed. But that's more likely to be the case in practice.
- sunshowers 1y ago
  The correct way to do cross-platform EOL handling is to use LF for all files on all platforms, and enforce that via hooks or CI. Every program on Windows, including the humble Notepad, understands LF these days. Git for Windows configures core.autocrlf to true by default. This is a terrible idea, imho. "input" is a bit more justifiable.
  - layer8 1y ago
    If you have to deploy or test with CRLF files, you can’t force LF for all files. This isn’t about editors, but about files to be deployed on customer systems, and/or to be used in tests, where the interfacing software has other requirements. You also have to use .gitattributes to reliably define which files to treat as text files in the first place. And you’d have to define your hooks and CI checks to be consistent with that. Note that Git always converts CRLF to LF upon check-in for defined-to-be-text files, even on Unix. I agree that the default on Windows is wrong. “Input” isn’t much better.
    - sunshowers 1y ago
      Tests that require CRLF should transform files as appropriate within a temporary directory. That way the costs of non-standard line endings are borne by the places that need it, as opposed to by all tooling in perpetuity.