4 ms·

> Every time you run a `jj` command a snapshot of your local changes is made. I think that's going to be pretty divisive. For projects where your input is here

> Every time you run a `jj` command a snapshot of your local changes is made. I think that's going to be pretty divisive. For projects where your input is here, your output is there, and that's that I imagine it's fine. Getting people to implement one of the workarounds to avoid junking up the repo feels like a huge ask.

deleted 2y ago
[deleted]
steveklabnik 2y ago
I’ve found most modern codebase have good gitignore discipline, but it’s true that there are codebases that are not. There are also some tools that by default write files to the current directory. The auto add feature is configurable these days though, so if you don’t like it, you can turn it off.
- dsissitka 2y ago
  > The auto add feature is configurable these days though, so if you don’t like it, you can turn it off. That's one of the workarounds I had in mind. :) This week I've had to work with CSVs, SQLite databases, and video in... six... different formats. Some goes in the repo, some doesn't. It seems like my choices are: - Disable it in the repo's .jj/repo/config.toml. - Get people that don't like it to turn it off. - Get people to do their exploratory coding in a gitignored directory. It feels like any choice I make is going to be met with resistance.
  - stouset 2y ago
    You don’t have to convert your team to use jj. So there’s nobody to resist but yourself. For me, writing temporary output to a gitignored tmp directory has been trivial. And I do exploratory coding in a separate branch. Just because it’s part of the repo doesn’t mean it needs to get pushed.
    - dsissitka 2y ago
      > You don’t have to convert your team to use jj. So there’s nobody to resist but yourself. Currently, sure. I was more thinking about it as a possible Git successor.
- eikenberry 2y ago
  Auto-adding your changes to existing files sounds like a great feature, auto-adding any random files it finds in the project is a terrible one. I can't imagine why the author decided that was a good idea. Can someone explain the reasoning behind it? I can understand someone wanting it as some point so it makes a certain amount of sense to add as an option, but not as the default. Makes me wonder about what other bad decisions have gone into the project.
  - steveklabnik 2y ago
    It’s consistent and convenient. I was skeptical until I tried it.
    - eikenberry 2y ago
      I'm a bit more than skeptical. Right now, for a project at work, looking at files in the repo (for testing, etc) I have 294 files untracked and 10 ignored. Using jj all but the ignored files would be committed to the repo and I'd have to something akin to git's filter-branch to clean them out again to avoid that bloat. I guess I should ask... is that final step made super easy? That is does jj make it easy to completely remove all traces from the repo of those auto-added files (like filter-branch)?
      - stouset 2y ago
        You live with those files showing up as untracked because it was easy and convenient to do so with git. If git auto-added them from the get go, you would have used a pattern in your personal or project gitignore to skip them, or you would have put them into an ignored tmpdir, or you would keep them on a separate branch if you intend to make them part of the repo. None of these steps would have felt painful or out of place. You see files you don’t intend to include in `jj status` and you’d do whatever is appropriate to exclude them. I’m with Steve here. I too was skeptical, and it’s turned out to be a complete non-issue. > and I'd have to something akin to git's filter-branch to clean them out again to avoid that bloat It’s even more trivial than you might imagine. If you have a commit that added files you don’t want to include you `jj edit` that commit, remove them however is appropriate (rm, mv, add to gitignore, whatever), and… there is no step 3. Later commits are instantaneously and automatically rebased so as to not include those files. Tools like filter-branch are completely unnecessary.

deleted 2y ago

[deleted]

steveklabnik 2y ago

I’ve found most modern codebase have good gitignore discipline, but it’s true that there are codebases that are not. There are also some tools that by default write files to the current directory. The auto add feature is configurable these days though, so if you don’t like it, you can turn it off.

dsissitka 2y ago
> The auto add feature is configurable these days though, so if you don’t like it, you can turn it off. That's one of the workarounds I had in mind. :) This week I've had to work with CSVs, SQLite databases, and video in... six... different formats. Some goes in the repo, some doesn't. It seems like my choices are: - Disable it in the repo's .jj/repo/config.toml. - Get people that don't like it to turn it off. - Get people to do their exploratory coding in a gitignored directory. It feels like any choice I make is going to be met with resistance.
- stouset 2y ago
  You don’t have to convert your team to use jj. So there’s nobody to resist but yourself. For me, writing temporary output to a gitignored tmp directory has been trivial. And I do exploratory coding in a separate branch. Just because it’s part of the repo doesn’t mean it needs to get pushed.
  - dsissitka 2y ago
    > You don’t have to convert your team to use jj. So there’s nobody to resist but yourself. Currently, sure. I was more thinking about it as a possible Git successor.
eikenberry 2y ago
Auto-adding your changes to existing files sounds like a great feature, auto-adding any random files it finds in the project is a terrible one. I can't imagine why the author decided that was a good idea. Can someone explain the reasoning behind it? I can understand someone wanting it as some point so it makes a certain amount of sense to add as an option, but not as the default. Makes me wonder about what other bad decisions have gone into the project.
- steveklabnik 2y ago
  It’s consistent and convenient. I was skeptical until I tried it.
  - eikenberry 2y ago
    I'm a bit more than skeptical. Right now, for a project at work, looking at files in the repo (for testing, etc) I have 294 files untracked and 10 ignored. Using jj all but the ignored files would be committed to the repo and I'd have to something akin to git's filter-branch to clean them out again to avoid that bloat. I guess I should ask... is that final step made super easy? That is does jj make it easy to completely remove all traces from the repo of those auto-added files (like filter-branch)?
    - stouset 2y ago
      You live with those files showing up as untracked because it was easy and convenient to do so with git. If git auto-added them from the get go, you would have used a pattern in your personal or project gitignore to skip them, or you would have put them into an ignored tmpdir, or you would keep them on a separate branch if you intend to make them part of the repo. None of these steps would have felt painful or out of place. You see files you don’t intend to include in `jj status` and you’d do whatever is appropriate to exclude them. I’m with Steve here. I too was skeptical, and it’s turned out to be a complete non-issue. > and I'd have to something akin to git's filter-branch to clean them out again to avoid that bloat It’s even more trivial than you might imagine. If you have a commit that added files you don’t want to include you `jj edit` that commit, remove them however is appropriate (rm, mv, add to gitignore, whatever), and… there is no step 3. Later commits are instantaneously and automatically rebased so as to not include those files. Tools like filter-branch are completely unnecessary.