71–80 of 117 posts
The extents people will go to, to avoid having to spend a morning learning git
I learned jj in one morning and will never go back to git.
I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my…
Earlier quoted context omitted.
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.
> 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…
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.
Earlier quoted context omitted.
> 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…
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.
Currently, sure. I was more thinking about it as a possible Git successor.
The extents people will go to, to avoid having to spend a morning learning git
Earlier quoted context omitted.
Merges were so, so painful in SVN, though. Maybe SVN improved towards the end of its life? I remember everyone went well out of their way to avoid needing to merge until git, because it could take hours to resolve a heavily-conflicted tree.
People complain constantly about how painful git is when their simple workflows break down. It is legendarily complicated and difficult to use. But when an alternative comes along and long-term git users try to tell people how much better it is? Everyone immediately forgets all their issues and frustrations. It’s honestly kind of bizarre.
My thought would be that most people are happy and it’s the <5% of people who complain the loudest that are heard.
Earlier quoted context omitted.
People complain constantly about how painful git is when their simple workflows break down. It is legendarily complicated and difficult to use. But when an alternative comes along and long-term git users try to tell people how much better it is? Everyone immediately forgets all their issues and frustrations. It’s honestly kind of bizarre.
Anecdata: I have no issues with my simple git workflow that I’ve used at the previous 3 companies I’ve worked for. As long as communication is solid across teams/people, merge conflicts and rebasing isn’t that big of a pain to introduce an un proven tool to an org. My thought would be that most people are happy and it’s the <5% of people who complain the loudest that are heard.
Your org doesn’t have to adopt the tool. Nobody on my team needs to know or care that I use jj instead of git. The only people who do know or care have themselves switched when I showed it off to them.
I’ve worked too many places where I’ve helped fix too many coworkers’ broken git repos to believe in a simple git workflow. Basically everyone uses the same fetch/branch/commit/merge-to-main approach and people still constantly run into problems. None of the people with some claimed simple workflow are doing anything meaningfully different than what everyone else is doing.
It’s just astonishingly easy to internalize all the fixes and band aids we’ve adopted to smooth the sharp edges and forget how often we have to work around them.
Broken link to GitHub (double dot). Second paragraph: https://github..com/martinvonz/jj
Earlier quoted context omitted.
Personally I usually stash if it's partial work I'm going to return to soon. But you can create a commit if you want. Just name it 'WIP' or 'temp' or something. When you come back and finish it you can write the proper commit message.
And then you have to remember which branch the each entry of the stash was on, deal with unstashing conflicts, remember to drop the latest stash after fixing those, etc. Tools like the stash are band aids that come with their own set of “fun” failure modes.
The easiest and by far most common thing to do of course is to just complete the commit you're working on before switching branches.
I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my…
It's written in Rust.