_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
(HTM) Visit Hacker News on the Web
COMMENT PAGE FOR:
(HTM) Defeating Git Rigour Fatigue with Jujutsu
sevenseacat wrote 4 hours 5 min ago:
Every time I've tried to use jujutsu, or even read about jujutsu, it's
totally broken my brain.
I'm not a git expert by any means I don't think, but there's 15 years
of muscle memory there, and a few years of subversion before that...
sharts wrote 7 hours 34 min ago:
Maybe just not use git? It doesnât even make sense for like 95% of
projects.
nextlevelwizard wrote 22 hours 6 min ago:
New tools are cool, but from what I have seen jj is literally just git
with aliases
riwsky wrote 22 hours 19 min ago:
git let me make changes to local files without fear, since version
control let me undo those changes easily.
jj let me make changes to my git commits without fear, since version
control of the git state itself let me undo those changes easily, too.
binarin wrote 22 hours 36 min ago:
[1] - git got the remaining piece of the puzzle to make massaging
history relatively easy. "git history split", interactive rebase and
fixup/auto squash allow you to do anything in a more systematic way
than resetting/selectively staging/committing again and again.
(HTM) [1]: https://git-scm.com/docs/git-history
actinium226 wrote 23 hours 51 min ago:
I don't get how this is meaningfully different from doing something
like:
1. Squash all your commits in this branch to one
2. Move that commit to the working directory with the appropriate git
reset command
3. Commit hunks as appropriate.
jauco wrote 17 hours 14 min ago:
Itâs mostly the same. But if you realize you forgot to add
something to the dirst commit while youâre putting stuff in the
second commit then this avoids having to create a fixup commit and
then rebasing that afterwards.
danborn26 wrote 1 day ago:
Jujutsu's approach to treating the working copy as a commit solves so
many common friction points with Git rebase workflows. Great to see it
gaining more adoption.
luodaint wrote 1 day ago:
Agentic development transforms the scope of work. Once a session is
committed to having one topic from the get-go â one move, one
service, one abstraction â the diff generated from such a session is
atomic by construction. Committing happens at the session level, and
the commitment discipline problem solved by Jujutsu does not come into
play.
It is also true in reverse. Scopes set too broadly ("dark mode
implementation," "auth flow fixes") lead to un-readable diffs no matter
what tool you use for version control. Un-readable diff does not stem
from commitment discipline; it is a scope problem.
That said, this fact does not diminish the usefulness of Jujutsu. There
are valid use cases for the rebase and stacking operations. However,
the discussion about commit granularity takes on a whole new context
once the constraint of having readable commits is established at the
scope setting stage.
vaylian wrote 1 day ago:
> This allows reviewers to step through your pull request in small
bites, with each set of changes scoped to a single aspect of the
feature.
Is that a frequent way of reviewing? On GitHub you get shown all
changes together in the review tab. You can select individual commits
for closer inspection, but where is the benefit?
Yokohiii wrote 1 day ago:
I suspect there is some weird habit that some people even like to
overengineer their git history. Maybe it improves the pixel fame
ratio or something.
For me it's satire. There are reasons for varying effort in creating
PRs or patches, but attempts like this never seem to reason about
reality. If I have to review, I want to see the code, not a clever
story hidden in the commit history.
steveklabnik wrote 1 day ago:
See this gist (and the discussion)
(HTM) [1]: https://news.ycombinator.com/item?id=41505266
jeltz wrote 1 day ago:
Yes, it us common among people who use git and it makes reviews of
complex features much easier.
Balinares wrote 1 day ago:
A series of piecemeal self-contained changes is much easier to wrap
your brain around comprehensively enough to detect logic issues.
I started doing exactly this and it's been invaluable.
vaylian wrote 1 day ago:
How does this work for you UX-wise? Do you use github? Do you and
your collaborators select each commit individually inside a pull
request?
regularfry wrote 1 day ago:
So I'd have an immediate problem with the target sequence of commits
here. The thing about just getting a "define types" commit is that it
shows me nothing about why those types were chosen. I need to flit
backwards and forwards in history to see how they hook into the later
code. I lose the history of "this type was enough to get us to point A,
we needed this other thing to get to point B". But flitting back and
forth is exactly what we're trying to avoid here. It feels like we're
trying to optimise to One True Clean History, when that can't possibly
exist because no two people's idea of "clean" actually matches.
Just give me the PR, don't sweat the individual patches. But maybe also
work on not committing your first idea as finished work.
Zizizizz wrote 1 day ago:
I would imagine why the types were chosen could easily be explained
in the commit message. The goal presumably (at least how I do it) is
so that if I'm touching quite a lot of the code base, the reviewer
has the _option_ of being taken through the narrative of the change
like they might explain if they were talking to you. If you don't
want to be told what the changes are and how they tie together, then
just click on review changes and review it all at once. It's not
about the clean history, it's about making the reviewer's life easier
with larger features.
The commits might get squashed anyways so the history on main won't
necessarily match what's on the feature branch.
You can commit before you raise a pull request, I don't quite
understand that point but I might just be missing something about
your workflow that's different to mine.
skydhash wrote 1 day ago:
I work via tickets so I donât take care of the commits in my
branch (if I would there would only be one commit). So what I
expect the reviewer to do is review the whole diff. I help by
commenting the changes to explain the design and the
implementation.
Commits on a PR branch are usually my thinking outline, not for
someone else to step through.
Zizizizz wrote 1 day ago:
That's fair enough! I think the flow will be more universally
beneficial if things like this become more mainstream. [1]
because then big prs aren't necessary if they can be reviewed
incrementally so long as they can stand on their own.
(HTM) [1]: https://github.github.com/gh-stack/
oncallthrow wrote 1 day ago:
`git rebase -i` and `fixup`
a10c wrote 1 day ago:
This is roughly how Iâve found myself using jj naturally. I find it
hard to âtell the storyâ of a change ahead of time, because the
design often only becomes clear after some exploration. Itâs much
easier to land at an implementation Iâm happy with, then work
backwards and shape the commits into the story I wish Iâd taken.
gertburger wrote 1 day ago:
I'd like to give jj another go but I found the "all files must be
tracked/committed" approach to really break my workflow.
I have a lot of temporary uncommitted files, which are not ignored or
excluded. Some may eventually be committed but most won't.
Being then forced to commit these (but only some due to file size) just
gets in the way and impedes things like cross branch debugging
A checkout is a working space after all, why can't it be (temporarily)
dirty whilst you work?
simonmic wrote 19 hours 19 min ago:
(HTM) [1]: https://joyful.com/jj#Do+I+have+to+let+jj+auto-track+files+i...
jezzamon wrote 23 hours 20 min ago:
If you do want to solve this, here's two thoughts on how you can deal
with it. First: don't try to edit jj changes. Always work on a new
change and then squash that in to the parent. You think of that top
level change as your working space.
From there, the simplest way is to just always use 'jj commit -i' and
'jj squash -i' to create change ids with your work. Then if you want
to have your changes move around with you, just rebase your working
copy which contains your "uncommitted files" to the new branch.
A different idea is to put those changes in a separate change, and
then when you do work, always create your working space change as a
merge change like 'jj new . Then you should be able to do 'jj
absorb' instead of 'jj squash' to put changes into the right change.
Switching to a different branch is 'jj new .
As in typing this, I'm thinking for myself and what I actually do in
practice... I find moving / rebasing jj commits very easy (I have a
UI tool that literally lets you drag and drop them) so I usually just
commit these changes and then drag the commits around so it's not in
the chain of when I want to send it out for review
JimDabell wrote 1 day ago:
When you are ready to record a change, split your current working
changeset and pick the things you want to commit. Itâs equivalent
to staging then committing with Git.
arccy wrote 1 day ago:
auto add is nice for universal undo for changes made outside your
editor...
instead of adding changes to a new commit, i split/squash them into
the previous one so the current commit remains dirty
silon42 wrote 1 day ago:
Same here, auto-adding is a non-starter for me. Thankfully there's an
option to not do it, not sure how well it works, but I'll have it
enabled for the future when I try jj again.
maleldil wrote 1 day ago:
Why not add them to gitignore? If you don't want to change the
project's ignore, there's also a repository local ignore file,
.git/info/exclude, which jj will respect.
> why can't it be (temporarily) dirty whilst you work?
Because that would go completely against how jj changes work.
nvgrw wrote 1 day ago:
I like how jj allows me to essentially use the same workflow in my
personal projects (jj on git) as with my work stuff (jj on piper). That
alone is really neat!
everybodyknows wrote 1 day ago:
> A downside to this technique is that there's no guarantee that every
commit will compile, which might be a dealbreaker.
To some of us, that's an essential structural criterion. Passing
unit-level self-tests may be as well.
jadar wrote 1 day ago:
I tend to just commit whenever I see fit, then at the end I do a `git
reset âsoft` and write the history that makes sense before pushing.
ninkendo wrote 1 day ago:
I always tell people I use a âgit resetâ based workflow. I rarely
âcheckoutâ branches, I just stay on main, reset hard when
switching topics, reset soft when squashing, and I only name my
branches on the remote end via âgit push origin
HEAD:some-branchâ.
`git branch` is basically my bookmark tool. I commit for a while,
then when I want to remember where I am for later, `git branch
wip/topic-a-finally-compiles` or whatever. I can reset hard to it
when I want to revert back, or any other topic I need. If I forget to
name a branch for a commit, the reflog is right there. Nothingâs
lost.
And yeah, a soft reset is basically the ideal way to just say
âpretend all my changes werenât committed yet, starting from
$refâ and then I make my single commit for my PR. Easy peasy.
skydhash wrote 1 day ago:
I follow something similar, especially with the PR process and
squash-merge on remote. I do the first ticket push using explicit
ref, then just continue on the next one, while I wait for the
review process. When the first PR is merged, I rebase on top of the
remote branch and do the same for the second PR.
I do switch branch for long experiments and touch up on existing
PR.
It would be great if a PR was about distributing patches and not
having those automatically generated from a branch.
789-ha wrote 1 day ago:
I canât tell if this is satire. The fact that we have to memorize
soft and hard resets was a thing I and everyone else just have to
do. But that goes away if you only have commits, so no staging area
vs staged changes vs changes on disk, itâs just all a commit and
we have a myriad of tools that already know how to deal with
commits. Honestly, your workflow as described sounds incredibly
compatible with jujutsu, Iâd really recommend giving it a shot /
another go
BobbyTables2 wrote 1 day ago:
I donât understand. Are there people that try to use git without
ever invoking âgit rebase -iâ ?
BeetleB wrote 1 day ago:
I've done both the rebase and the merge flows in different jobs.
I just don't see the fuss about rebase. Merging just works fine.
Edit: OK, I realized later that I'm not really responding to the
usual git rebase -i use case.
Have you heard people say that because of magit they started using
more "advanced" git workflows, and how they emphasize having a better
UI makes a difference?
It's the same idea with jujutsu. I'm much more likely to use git's
power via jujutsu than directly with git. It's because jujutsu lets
you do it all with a much simpler interface - fewer commands, and
fewer concepts. And knowing that "jj undo" has your back.
As a sibling commenter said: Likely 99% of git users don't do "git
rebase -i". But the percentage who do similar with jujutsu is high -
perhaps over half[1] of jujutsu users do the equivalent of "git
rebase -i" all the time. Many of them didn't when they used git.
The interface matters.
[1] If you told me 80%, it wouldn't surprise me in the least.
NamlchakKhandro wrote 1 day ago:
Yes. almost the majority of git users do this. i would say that as an
expert commenter, 99.9% of people outside of California do this.
Yokohiii wrote 1 day ago:
TIL I am a minority.
christophilus wrote 1 day ago:
I don't rebase. I just merge and resolve the conflicts. Nowadays, I
just have an agent do that for me, and move on with my life.
nextaccountic wrote 1 day ago:
> Latter commits overwrite work that was done in earlier commits and
the story breaks.
> Some people prefer this, as it helps git bisect work better.
Debuggability versus reviewer convenience is the tradeoff, I guess.
Ideally we would have a VCS that made ergonomic to store both
history-as-it-happened for some purposes, and the cleaned up, squashed
and rebased history for other purposes, ensuring they match
Izkata wrote 1 day ago:
Force --no-ff merges in git. That's pretty much what you want.
gmueckl wrote 1 day ago:
I think that version control has reached a point where the next major
evolutionary steps will be based on making history totally shared and
immutable with history edits themselves being non-destructive
versioned operations that can be browsed as higher order history.
riwsky wrote 22 hours 25 min ago:
Thatâs, uh, exactly how jj works!
gmueckl wrote 10 hours 43 min ago:
I never absorbed that fact until now. Now, if it supported huge
repositories with large files and binary files well, it could
actually become a superstar.
paradox460 wrote 1 day ago:
Jj could do that; it stores an evolog of each change, but currently
that's kept local
bschwindHN wrote 1 day ago:
Just squash all the PR commits into one when it gets merged to main
or whatever your main branch is.
You can revisit the original PR to see the individual commits if you
really want.
drdrey wrote 1 day ago:
I have finally embraced squashing PRs and realized I wasted my youth
trying to write Good Commits.
wocram wrote 22 hours 44 min ago:
PRs very frequently contain more than 1 logical change.
vermilingua wrote 1 day ago:
These Good Commits are for the reviewâs benefit, not necessarily
trunk history.
EFLKumo wrote 1 day ago:
This remind me of [jj megamerge]( [1] ). jj allows concentrating on
developing while leaving things for vcs alone, as well as solving vcs
things (conflicts) at very beginning (megamerge). Really good.
(HTM) [1]: https://isaaccorbrey.com/notes/jujutsu-megamerges-for-fun-and-...
stouset wrote 1 day ago:
This seems like a lot more effort than the (to me) more natural jj
workflow of maintaining the idealized series of commits plus a working
commit on top. As you make tweaks and fixes you just squash the
relevant parts into the already-clean history.
Basically, if you donât get into that sort of situation with commits
containing parts they shouldnât in the first place, you donât need
to do any extra work to clean them up. The tip of your branch should be
the only âmessyâ part.
3eb7988a1663 wrote 1 day ago:
That is a lot of discipline up front. I am sure there are problems
which are nicely bucketed, but I usually have to go with the flow and
make changes as I see them. I want to keep working with the code, not
babysitting version control as I focus on getting the initial version
to work.
stouset wrote 1 day ago:
Itâs really not.
I start a new branch and begin work. When Iâm ready to start
organizing that work into a consistent narrative (or when bits are
âfinishedâ), I split it out into independent commits. As I keep
making fixes and tweaks, I continue squashing bits from my working
commit into the parent commits they belong on.
I donât bother making any independent commits until pieces of
what Iâm working on are becoming fully-formed. Until then, my
working commit just has everything.
surajrmal wrote 1 day ago:
I think it comes down to your ability to plan and understand how
the work can be broken down before you try solving it. I often know
what every commit will look like before I ever touch the code. I do
sometimes learn things and change my mind as I make changes but it
doesn't often change my commit structure. I tend to work on a
codebase I have 8+ years experience in though. I'm sure it doesn't
work in a variety of situations though.
singiamtel wrote 1 day ago:
The only thing that stops me from switching to jujutsu is that lazygit
already paves through all these paper cuts pretty well, and I'd miss
their custom patches feature.
I see there's a similar project for JJ, but it doesn't seem nearly as
polished
(HTM) [1]: https://github.com/Cretezy/lazyjj
nchmy wrote 1 day ago:
Jjui is the best tui for jj
sswatson wrote 1 day ago:
What does jjui have on lazyjj? Sincere question; I tried it, and I
want to get it, and so far I donât.
nozzlegear wrote 1 day ago:
As a git rebase enjoyer, I've completely switched over to jujutsu. The
whole experience is more ergonomic in my opinion, and the default
workflow which I use (using `jj new` to create a new change that
clearly delineates work on a different "thing" before I start working
on it) fits my mental model much better than the traditional
write-then-commit workflow we all grew up with.
xyzsparetimexyz wrote 1 day ago:
With jj I mostly just `jj split -B @`. Nice interactive ui for picking
the changes I want into a commit. So many times better than 'git add
-p'
fragmede wrote 1 day ago:
The elephant in the room is that I haven't had to do something
complicated and manual in git by hand in a long while. I'm using AI to
generate code, and further, having it commit to git and pushing and
pulling and managing branches and merging for me. So for people new to
software development, they can also just ask AI to deal with git, which
papers over the harder parts of its UX.
jezzamon wrote 23 hours 13 min ago:
You can definitely get stuck in a weird place with git that I haven't
run into in the same extent with jj. The ability to undo anything
with the one 'jj undo' command is awesome in the agent coding world
when it makes a mistake.
hu3 wrote 1 day ago:
This. I feel jj is some years too late.
It tries to solve a human problem in an LLM era.
LLMs are destined to overcome humans in code merging and change
versioning (already did for me).
There's little point to introducing yet another layer of indirection
when LLMs just cut to the chase.
nemo1618 wrote 1 day ago:
Good git hygiene is also less important post-LLMs, as the LLM can
make sense of even a messy history.
surajrmal wrote 1 day ago:
A lot of humans don't currently trust agents to touch VCS today. I
also find that my agent tends to be much better about dealing with
jj than it is with git.
muixoozie wrote 1 day ago:
I'm one of those people. I don't really use jj, but want to give
it another try. Think I'd feel more comfortable letting ai mess
with jj because of its excellent ability to undo/redo (op log).
hu3 wrote 1 day ago:
Culture change is hard.
A lot of humans still don't use git too.
Many do only when they are forced.
And it's much easier for a professional to be forced to use LLMs
than jj when it comes to versioning assist (not even comparable
in mindshare but the obvious needs to be said sometimes).
So unfortunately I'm afraid jj is not going to achieve critical
mass before 99.99% of merges are done by AI which don't need jj.
surajrmal wrote 20 hours 40 min ago:
That's the beauty of jj. It doesn't need critical mass. If the
community remains small it's fine. If it blows up in adoption
that's also fine.
Also there are many ways to use llms. Some people control it at
code review, but others control it as the VCS.
hu3 wrote 11 hours 12 min ago:
Sure just like any non-critical tool. It's optional.
LLMs will do most of the work anyways. And they don't need
jj. Like I said, jj helps solving a human problem in an LLM
era.
It's hardly worth using more of the precious LLM context with
jj instructions when git does the job and is mandatory
anyways.
surajrmal wrote 18 min ago:
jj is in the training data for at least Gemini these days.
My experience is it uses less tokens to do similar
workflows with jj vs git because they are simpler.
Also, remember that humans aren't going away. The touch
points are changing but they still exist. The VCS is a
common touch point for many and my preferred one. For
others I'm sure it's online code review tools. If an agent
is operating under my name in my workspace I want to manage
it within the confines of my workspace. Once it becomes
more agentic and operates as it's own entity I'm sure I'll
change my mind but that's not the case today.
einpoklum wrote 1 day ago:
> For large features, I find this workflow far easier than having to
maintain strict git rigour for the lifecycle of the feature's
development.
I don't know about all that. All sorts of ex-post-facto automated
cut-up-and-splice commits sounds to me like a recipe for an every
larger mess. I say maintain git rigor, always. Now, you could say "You
only say that because you know git rather than jujutsu" or "if you use
git absorb more you'll get it", and theoretically you might be right,
but... meh, I kind of doubt it.
einpoklum wrote 1 day ago:
s/every larger mess/even larger mess/
sorry about that.
mcookly wrote 1 day ago:
I'm not an expert in Magit by any means, but I bet there's a way to
accomplish this in only a few keystrokes.
winterqt wrote 1 day ago:
> `absorb` assigns the changes based on whichever previous commit most
recently touched those files, which sometimes doesn't actually
correspond to which commit should own these particular changes.
Iâm pretty sure `jj absorb` (and its predecessors, `git-absorb` [0]
and `hg absorb`) are smarter than this, instead looking at the actual
diffs.
[0]:
(HTM) [1]: https://github.com/tummychow/git-absorb
oefrha wrote 1 day ago:
Yeah itâs smarter than that, but as a daily user of git absorb it
still gets things wrong fairly often thoughâlike a couple times a
week often for me. Plus the changes it canât absorb automatically
(e.g. a lone doc change it canât find peers for).
ikesau wrote 1 day ago:
Ah yeah, you're right, that's a misrepresentation on my part - it's
based on lines, not the file:
> [absorb] splits changes in the source revision and moves each
change to the closest mutable ancestor where the corresponding lines
were modified last. If the destination revision cannot be determined
unambiguously, the change will be left in the source revision.
I use absorb fairly often, fwiw. It's great for when I want to make a
patch to a commit that will easily absorb into its right place. And I
also, sometimes, prefer the more intentional approach where I decide
exactly where each hunk will go.
jolux wrote 1 day ago:
Also `sl absorb`.
mi_lk wrote 1 day ago:
So: Squash everything together then pick each component out by squash
-i to an empty commit.
Seems straightforward, wouldnât call it special
nomel wrote 1 day ago:
I think jj will never gain momentum because people only have a git
mental model at this point, so won't be able to effectively reason
about jj.
Macha wrote 1 day ago:
Having been often called by coworkers to assist them with their git
problems, I can assure you they donât have a git mental model.
incognito124 wrote 1 day ago:
I spoke about this before, but jj has the Blub Paradox problem,
from the pg's essay Beating the Averages ( [1] ).
Yes, you can do most commit manipulations with git just like with
jj. But, users of jj know they're "looking down the power
continuum" (to reuse pg's terminology) when they look at git,
whereas git users cannot fathom what's exactly the deal with jj.
Unfortunately, the only way to get it is to spend a week with it,
with an open mind. It's close to impossible to describe it except
"it's really neat" and "wow it removes all git's friction I didn't
know existed".
And, apparently, there's a pattern of having to try at least two
times before it becomes intuitive!
(HTM) [1]: https://paulgraham.com/avg.html
bsder wrote 1 day ago:
> I spoke about this before, but jj has the Blub Paradox problem
It's not relevant. Don't try to convert git users--you don't
need to. They're fine doing what they do, and the git backend
store is acceptable. People who understand how broken git is
will gravitate to jj with the lightest of prodding--give them a
light poke and then don't harass them further.
The main difference is that I can teach jj (like I could teach
hg) to normal people. And, because jj is based on the git store,
they can operate in a Github world.
So, just teach jj to people who haven't yet broken their brain
with git. Running on the git backend already gains most of the
network effect, so don't proselytize the git people.
hooper wrote 1 day ago:
It's interesting that even clear advantages like `jj undo` are
hard to communicate because of this.
ruszki wrote 1 day ago:
The problem with this mindset, that there is zero reason to move
away from Git. I can do effortlessly everything with it. There is
no incentive. I never said "it would be so good that I would be
able to X"... and I didn't find a solution for it quickly. As
under this post is obvious as much as under other previous posts,
you can do the same things effortlessly with Git. The effort is
not that I need to use 2 commands less, but to separate the code
(in this specific case), which takes about a 100-1000x more time
than typing those 2 extra commands, or really the need to think
what kind of commands need to be used in any VCS.
The same problem with vi for example. Which I learned, deeply and
for a long time. Maybe I will be break even in a decade or two.
And for example, I can code faster than anybody who I know and
use vi all the time (or some vi keyset in Emacs or something),
not because I type faster, but because I don't need to rewrite my
code that many times than them.
The same with jj. I'm happy that it clicks better than Git for
some. But I know Git from inside and out. Git was never the
bottleneck for me. And really any VCS in the past. If I learn jj,
then I don't expect that the effort pays off in a decade or less
in the best case. My work's result would be the exact same thing,
just with different commands, commands which takes almost no time
compared to my other tasks.
skydhash wrote 1 day ago:
> Unfortunately, the only way to get it is to spend a week with
it, with an open mind
We do get it. But have you ever thought that git inflexible
nature and full control is what some people people like?
Having three different state for your work (working tree,
staging, and committed) is nice for reviewing code. Picking lines
and chunk give me an additional mental state to think about the
design of the code.
And once upon a time, I preferred history log like the one in the
article. But this days (mostly inspired by mailing list
development style) I wants the commit in my main log to be either
features or bug fixes. Everything else is âwipâ, which I will
squash. It makes it easier when rewriting history, cherry
picking, or just browsing the log.
jolux wrote 1 day ago:
Thereâs nothing stopping you from using separate changes to
emulate the staging area if you want.
skydhash wrote 1 day ago:
I can, but I donât need to.
jj has nothing I need, so it would be changes for the sake of
changes. Iâm not saying itâs bad, but people do need to
realize that their struggles are theirs, not the whole world.
sswatson wrote 1 day ago:
Not trying to tell you how to live your life, obviously,
but I think âchanges for the sake of changesâ
overstates it. For example, `jj undo` is a pure ergonomics
win.
Itâs been said a million times but it is really true that
jujutsuâs appeal is something you feel (or donât) after
giving it a proper go. It doesnât survive compression
into the feature list.
Actually I think that property is a much bigger obstacle to
adoption than what it does or doesnât offer to the rare
true git wizard.
skydhash wrote 1 day ago:
I use magit on a daily basis. And I do use tig
occasionally (I don't like lazygit). Most of my magit
workflows only requires a handful of keys (most are only
two keys). If you've not tried Magit before, it's like
vim for a git repo. tig is more barebones, but I could
quickly configure it to be able to do most of the magit
tricks I need.
Git cli is tedious. But like all cli operations the goal
is always to script your workflow or alias the most used
commands in something shorter. I'm sure that jj may have
an easier learning curve. But some people do know how git
works and like the level of control over commits.
sswatson wrote 18 hours 54 min ago:
Iâve never used magit but my impression is that
itâs similar to jj in the sense that it smooths out
gitâs rough edges in an elegant way and in the sense
that itâs hard to properly appreciate without using
it.
That being said, I also much prefer a UI layer (lazygit
originally, now lazyjj), and personally I find the
benefits of jj to be partly complementary to the UI
ones.
That is, after getting used to jj, my problems with git
are (1) the CLI ergonomics, and (2) the model is
actually more complex than it needs to be, in a way
that materially diminishes my experience. Only the
first is addressed by lazygit (though maybe magit does
both; not sure).
One other point: jj doesnât actually impose a
level-of-control tradeoff on the curation of commits.
You can mimic the git workflow by modeling the working
copy and staging area as commits (changes, in jj
parlance), or you can experiment with any number of
alternatives. What git gives you is the opinionated
support for the working-copy-staging-area-commit
approach.
jolux wrote 1 day ago:
Totally fair :) personally I used to be a git wizard and I
am relieved at how much about it Iâve been able to forget
since learning jj, but I understand not everyone has the
same experience.
entrope wrote 1 day ago:
That is, in essence, the "squash workflow": [1] The big
differences are that the jj approach gives you a commit
message for the staging change, and lets you jump to some
other commit without extra steps.
(HTM) [1]: https://steveklabnik.github.io/jujutsu-tutorial/real...
jonathanyc wrote 1 day ago:
I have been walking some newer programmers through Git recently, so
this topic is fresh on my mind. The commands in the blog post do not
look friendlier or even different.
diath wrote 1 day ago:
So... git rebase -i?
idoubtit wrote 1 day ago:
No, more like:
git rebase -i
# squash all the commits (e.g. in vim with ctrl-v)
git reset HEAD^
git add -p
# interactively pickup the RED hunks
git ci -m RED
The main difference to jj is that the RED commit is created later
with git.
nine_k wrote 1 day ago:
But isn't the flow nearly identical with jj, because the key part,
the moving of hunks, is interactive (aka manual) anyway?
9029 wrote 1 day ago:
I'd recommend reading the post, it's not that long
raincole wrote 1 day ago:
As someone who doesn't know jj and read this article, it does sound
like `git rebase -i` to me. I'm sure that if I actually spent time
learning jj I'd know the difference though.
ai_slop_hater wrote 1 day ago:
git rebase -i kinda sucks once you tried jj.
nomel wrote 1 day ago:
Definitely not. Switch to a previous commit, make edits, changes
propagate into the future commits (including into a git repo if you
wish [1])
Jj is not git and is not a git tool, it just (thankfully) uses git as
a backend, so you can still carry on with the rest of the world.
(HTM) [1]: https://news.ycombinator.com/item?id=47765759
ahepp wrote 1 day ago:
> Switch to a previous commit, make edits, changes propagate into
the future commits
In what way is that different from using `git rebase -i` to edit a
commit?
stouset wrote 1 day ago:
You can literally jump into a commit and edit its contents
directly, and everything is auto-rebased on top.
There are no modal âsorry rebase failed, best of luckâ
gotchas. There are no âoops I put the wrong thing in the wrong
part of the rebase and now I have to abort and start all overâ
gotchas.
Itâs rebase, but without all the extra work, mental overhead,
failure cases, and effort.
matheusmoreira wrote 1 day ago:
How does it just auto-rebase everything without failing though?
If you edit something later commits depend on, then you get
merge conflicts. Are you implying that jj just automatically
handles all this?
steveklabnik wrote 1 day ago:
jj allows your commits to stay in a conflicted state until
you choose to resolve them. I wrote about this a month ago:
(HTM) [1]: https://news.ycombinator.com/item?id=47767292
matheusmoreira wrote 1 day ago:
I see. It doesn't deal with the conflict, it just proceeds
regardless. I'm curious about how it works internally. Does
it do something like commit the conflict and soft reset
later?
stouset wrote 1 day ago:
The conflict markers are a first-class citizen in the
repo. jj tells you when a commit has a conflict, and you
can go edit it at your leisure. It also does prevent you
from doing some things with branches in a conflicted
state, like pushing them.
You might not think this is that big a deal, but this
also means you donât have to resolve the entire thing
in one go. Plenty of times with complicated rebases in
git, Iâve not been 100% certain about the path towards
resolving it. But jumping around to view various commits
when youâre in the rebase-conflict state is painful. In
jj you can just switch to an earlier commit, tweak it
there, jump to a later commit, see how it looks, etc. It
removes 98% of the pain.
It also dovetails nicely with other aspects of jj. Since
rebases happen automatically and constantly, they are
usually tiny. If thereâs a conflict, itâs caught
right when you do the thing and not four hours later when
that part is no longer fresh in mind. And the op log lets
you restore and undo actions atomically, which makes
undoing a fuck-up a no-op.
bentcorner wrote 1 day ago:
I've come to the opinion that conflicts should be
committed and merge fixes should be in another commit
afterwards. Arguably even if the merge fix is trivial.
stouset wrote 1 day ago:
Thatâs almost definitionally what a merge is.
A merge conflict means that some automated tool
couldnât figure it out. But all a merge is is a
commit with two parents and an accompanying diff that
shows the process of combining them. A merge conflict
isnât really in any way special. It just means
whatever algorithm was used couldnât do it
unambiguously without human help.
y1n0 wrote 1 day ago:
I don't get why people like jujutsu. I tried it for a while but I work
with a quite a few people in the same repo and I need easy named
branches that keep up with commits. For all the many problems in git,
branches are dead easy. That was the big innovation over svn at the
time.
Last time I tried jj, branches were an extremely laborious process to
keep up to date. I don't see how people that aren't working alone can
work with that. I have numerous branches in flight at any given time,
and my colleagues do as well. The idea of manually keeping them
pointed at the right commit is just nuts.
Maybe they've fixed that astonishing choice since then, and I'd give
things another go if they did. But branches and worktrees are how I
operate.
Regarding the article, I have no idea what is going on as I'm red-green
color deficient.
wocram wrote 22 hours 51 min ago:
jujutsu presents the same amount of power with fewer ideas, eg. There
is no staging area. It adds new features, like jj undo.
The un-learning curve is steep if you already know git very well. [1]
lets you enable automatically advancing bookmarks.
(HTM) [1]: https://github.com/jj-vcs/jj/discussions/3549
LtWorf wrote 1 day ago:
I've worked in places where they didn't know about git branches. They
only had master.
Review was done by having someone sit next to you and scrolling
through the code telling what you had changed.
arccy wrote 1 day ago:
i too work with worktrees (jj workspaces) and prs (requires
branches). it's easier if you give up choosing the name of your
branch, and instead rely on finding things by description or your
workspace name.
for prs, I usually start with a single commit, so `jj git push -c`
will auto create a named branch based on the change id.
And i have template like the following to push to the same branch if
i decided to stack commits rather than rewrite:
branch-push = ["util", "exec", "--", "sh", "-c", """
name="$(jj log --no-graph --no-pager --color=never -r
'fork_point(@ | trunk())+ & fork_point(@ | trunk())..@' -T '"push-"
++ change_id.short()')"
jj bookmark set -r @- "${name}"
jj git push -b "${name}"
"""]
you could probably write a similar alias that used your workspace
name as the branch name to push to.
and descriptions are slightly nicer than branch names, since they can
be longer.
BeetleB wrote 1 day ago:
I think much of the problem with this thread is people trying to
convince one way is superior/inferior.
There are just multiple different ways of working. Some ways fit some
people's mental models better.
You're not going to get a definitive "jujutsu is better than git" or
vice versa. You should accept that some people have no problems with
what you've described using jujutsu, and likewise jujutsu users
should understand that not everyone can handle jj as well as they
can.
Imagine a different thread where jj users take your exact scenario,
and complain about solving the problem with git. You wouldn't
understand their pain, because it's not painful for you. This thread
is the same, just with jj and git reversed.
Personally, I don't see the pain you have. Back when I used git a
lot, if I left a branch for a few weeks, I'd forget the name of the
branch and would have to list all the branches (and set an alias to
sort by and list the last commit dates of each) to discover the
appropriate branch name. It's really not all that different from
looking at all (recent) heads. Once you get used to this, you stop
naming branches - other than to share with others. And when you do
share with them, you cannot push (newer) changes because only
bookmarked nodes and their parents can be pushed - so just prior to
pushing, you advance the bookmark. With the shells I use, it's a few
keystrokes before autocomplete/fzf produces the command for me - no
mental effort at all.
You definitely wouldn't advance the bookmark with each commit. Only
when you need to push.
And oh man, it's so nice not to have to manage all the branches. With
git, I'd routinely go and delete old branches to declutter. With jj,
there's simply no need to. The same with stashes. It's really nice
not having to do that labor, and simultaneously not dealing with long
lists.
If this doesn't appeal to you - that's fine. You're not deficient.
But understand, nor are those for whom your workflow sucks.
theamk wrote 11 hours 59 min ago:
> With git, I'd routinely go and delete old branches to declutter.
With jj, there's simply no need to. The same with stashes. It's
really nice not having to do that labor, and simultaneously not
dealing with long lists.
wait what? how does this work?
Many of my stashes are tiny changes that need checked later -
effectively, each stash entry is a quick TODO list. At some moment,
for example once a major feature is done, I'll go a check every
stash'ed entry and decide - maybe it's no longer relevant, maybe I
should make a PR out of it, or maybe I should convert them to the
branch if it's useful but needs more work. The branches are
similar, but on longer scale.
The idea that you don't need to declutter your old stashes/branches
seems absurd to me - it's like getting a huge box labeled "misc",
and throwing every single thing in there. Sure, it's quick, but
that's how you lose the important things you need to do, and find
the useless junk instead of the actual thing you were looking for.
dzaima wrote 22 hours 7 min ago:
How different people approach workflows is fascinating.
For example, your "not all that different from looking at all
(recent) heads" implies that the number of (recent) heads isn't far
off from number of (would-be-)branches (i.e. no random offshoot
experiments, stashed-away debug sessions; whereas I make many of
such continuously (were stashes on git (with occasional grumbles
about not being able to stack stashes), regular commits now on jj
(maybe with a special-format description, if I bother)));
and that you (even if subconsciously) try to ensure that the head
of a branch is always identifiably-representative of the branch
(i.e. don't put some random unrelated change at the tip with the
idea of "I'll put this in a more proper place when I get back to
this").
Effectively, using the full commit graph not as a place where
anything potentially-useful can stay, but rather by itself a
complete picture, with things not fitting into it going into.. idk,
just being abandoned, to be found by looking through the op log?
commit IDs saved in an external file? wading through evolog /
scanning through `jj show -r xyz/2` etc?
jaredklewis wrote 1 day ago:
Itâs only natural to want to defend oneâs preferences with
these things. Because unlike with some other preferences, such as
what IDE, operating system, or terminal emulator you use, version
control systems must be shared.
If it is like you say and different people are just inherently more
or less suited to different paradigms, then not everyone can be
happy.
BeetleB wrote 1 day ago:
> version control systems must be shared.
This whole thread is about working with git coworkers while using
jujutsu, and it was in that context that I wrote my comment:
Namely that most who prefer jujutsu happily work with their
colleagues who use git in precisely the scenario the OP mentions
and don't see why the OP finds it painful. The OP and others
should accept that reality.
> If it is like you say and different people are just inherently
more or less suited to different paradigms, then not everyone can
be happy.
If you force everyone to use git, of course not everyone will be
happy.
If you force everyone to use jj, of course not everyone will be
happy.
Thankfully, the whole point is git and jj users can interoperate
without needing to care what the other is using. So yes, not only
can everyone be happy, but everyone is happy! This isn't a
hypothetical - it's a reality. It's the reason so many use
jujutsu at work.
sakompella wrote 1 day ago:
i had this exact friction trying to use jj this weekend. can't fathom
for the life of me why i have to run another command that updates the
branch to the next commit.
wocram wrote 22 hours 49 min ago:
[1] let's you change this behavior.
I think the idea is that branches/bookmarks aren't as necessary as
they are with git.
(HTM) [1]: https://github.com/jj-vcs/jj/discussions/3549
kaladin-jasnah wrote 1 day ago:
I like jujutsu simply because (despite my annoyances, which might be
because I started using it 2 weeks ago) it's still faster than git.
I dislike this as well. I find it easier to keep track of branches
with bookmarks, but my workflow still makes things cumbersome. I am
usually working with the "megamerge" branches, and I usually want to
add commits to my current branch instead of squashing my edits.
However, adding commits means I have to add my commit, move my
bookmark up to the branch tip (jj tug?), and then rebase the
megamerge branch, versus doing nothing for squashing. I also find
that when I mess up, I don't really love using `jj op log` to fix it.
I want to not be in an environment where it's this easy to destroy
history (I feel like git was on the other end of it).
oscillonoscope wrote 1 day ago:
If I need to move a 'branch bookmark' around a lot, I usually just
tie it to an empty commit and then rebase changes before the
bookmark.
NamlchakKhandro wrote 1 day ago:
Feel the same way about JJ.
It feels like Apple vs Linux. Apple being different ... just because
(it gives them an artificial moat)
kccqzy wrote 1 day ago:
You donât need easy named branches. Naming branches is a chore:
since you already spend time writing commit messages, branch names
are just a summarization of your commit messages but with more
character restrictions.
Thatâs why I always use jjâs automatic commit identifiers. They
are short and I donât waste brain cycles naming things that are
ephemeral. When I push, I let jj automatically creates, updates, and
deletes remote git branches (`jj git push -c` for creation, plain `jj
git push` for updates, `jj git push --deleted` for deletions). I do
not ever have to think about branch names and it is great!
krackers wrote 1 day ago:
>You donât need easy named branches.
You can't possibly see a use-case for long-lived branches? Say what
you will of git, at least it exposes enough knobs that it can
mostly accomodate every workflow (possibly with a heavy porcelain
layer to hide the plumbing). JJ seems to swing too far in the other
direction, great for a "live on head" mentality but less ideal for
other setups.
(The fact that all edits are automatically recorded is my personal
peeve with JJ. I'm ok with lack of staging area like in Mercurial,
but mercurial doesn't try to automatically amend the commit with my
pending changes. Sure I can pretend that "@" is my staging commit
then squash as needed, but then I also need to remember that
checking out a commit is "jj new" which feels like absurd mental
gymnastics to me.)
simonmic wrote 1 day ago:
You can turn off auto-tracking.
krackers wrote 17 hours 5 min ago:
Last i checked that only disables tracking of new files, it
doesn't do anything to prevent the "auto-amend" behavior for
modified files.
kccqzy wrote 14 hours 12 min ago:
Honestly it took me about two days before I just got used to
it. You can change `git checkout blah` into `jj new blah`.
rixed wrote 1 day ago:
branch names are just a summarization of your commit messages
What kind of dev workflow leads to this surprising opinion?
cpeterso wrote 1 day ago:
I name my branches for the overall task. The description of the
branchâs head commit in jj status doesnât tell the whole story.
kccqzy wrote 21 hours 39 min ago:
Ah but then I reword the commit message as I make changes to the
commit. If the commit message does not tell the whole story, I
change the commit message. It's much more convenient to change a
commit message in git than to rename branches, so branch names
tend to be more out of date than commit messages.
dzaima wrote 1 day ago:
But you probably haven't spent time writing commit messages before
a branch is finished. Or, if you have, you've quite potentially
just wasted time writing something that will be rewritten anyway as
things change; replacing a chore with a much bigger chore.
Restricted and summarized is good - easier to find/remember, less
fluff in a list. And easier to recognize a short identifier from a
list of the 2-3 most recent branches, than scanning through 50
commits, when trying to remember where some work last was, and
which is the proper end-point instead of some failed attempt or
unrelated change.
Unnamed branches are quite neat - I certainly have a lot more of
such than named ones in jj - but as such named branches are, if
anything, more important as a result, for separating sequences of
changes striving towards a goal, from the sea of smaller
experiments.
kccqzy wrote 1 day ago:
> But you probably haven't spent time writing commit messages
before a branch is finished.
Wrong. With jj, I use `jj describe` before I start work. It is
like writing out a plan for what I want to do.
> Or, if you have, you've quite potentially just wasted time
writing something that will be rewritten anyway as things change.
Rewriting it is not wasted time. It is an opportunity to look at
what I have written in the plan and check whether I have really
executed them, and then rephrase things to be more easily
understandable.
> Restricted and summarized is good - easier to find/remember,
less fluff in a list.
The first line of a commit message is already a summary of the
work done. And you can use actual English instead of trying to
awkwardly avoid spaces in your words.
dzaima wrote 1 day ago:
> It is like writing out a plan for what I want to do.
I usually don't have a plan for the end; certainly not what any
specific commit would be; sure, I could make one (and either
make my future self have to do extra work to figure out what
commits with lies in their descriptions actually do, or
continuously update the commit message marking what actually
exists), but as I said that's basically a waste of time. (if
you like comparing with past thoughts, sure, but that's
definitely not a necessity for a workflow to be reasonable)
"is/isn't an ancestor of the bookmark" is also just a pretty
damn good short-hand for denoting a separation between what's
been considered the best attempt at the goal, vs things with
known problems or just unrelated to the task.
At the core, this if all of course just a question of workflow;
if you go into a thing with a plan, meaningful outlook of a
non-vague destination, and without expecting continuous
switching back&forth between a dozen other things over the time
span the branch is alive, caring less about branches or branch
names can perhaps work.
> The first line of a commit message is already a summary of
the work done.
But you can't (sanely) use it to reference the branch in a
revset, can't find it anywhere other than the full log (that's
interleaved and mixed with a bunch of other things that you
won't ever need to search for), and actual English just gets in
the way for finding it, remembering it, and identifying it in a
list.
This alone means that, even if I found interest in
massively-ahead-of-time-describing commits, having a sane
branch reference is still simply just necessary.
y1n0 wrote 1 day ago:
Yeah, I don't get it. I'm sure it's because we work differently
and that's fine.
But when I'm picking up something someone on the team has left
behind because they got pulled on to something else, or are sick,
or 5 million other reasons, having a branch, with a ticket in the
name, explaining what the purpose of the branch is, why it exists,
what it's current state is, that all matters. I can't help but
think that everyone that likes JJ isn't really doing collaboration.
Macha wrote 1 day ago:
When its MR time I use jj push -c and Iâve set my config to
auto generate a branch name from the commit message by extracting
the ticket ID from the commit message since we have a standard
format into something like PROJ-1234-nzytopmn . Since the company
I work at enforces squash merge since many coworkers would
otherwise have 20 merge, fixup, lint or ci fix commits per MR,
auto advancing isnât relevant. Addressing comments is just
squash into that change and repush. We donât really do long
lived branches so the ticket number is enough to find the branch
and the commit message explains the change if I need to hand over
work.
kccqzy wrote 1 day ago:
I collaborate a whole lot. In fact for solo development I use git
because jj is overkill for it. Also by default jj prevents you
from overwriting commits that exists on the main branch on the
remote, but this is what I often do on solo projects.
> having a branch, with a ticket in the name, explaining what the
purpose of the branch is, why it exists, what it's current state
is, that all matters
In my view, all the above information exists not in the branch
name, but either in the ticket, or in the commit message. The
branch name is purely a superfluous thing that does not convey
any information. Many of my colleagues already use a tool to
automatically name their branches from the first line of their
commit messages, and jj just makes this awkward process
straightforward.
rmwaite wrote 1 day ago:
I remember being the big innovation over svn being merging. There
were others things, obviously, but the distributed model + easy
merges is what I remember.
kccqzy wrote 1 day ago:
If the big innovation over svn is merging for git, then the big
innovation here is conflicts. I hate the fact that git requires you
to stop everything and fix the merge conflict when you merge. I
especially hate the fact that when rebasing in git sometimes it
requires you to solve conflicts one by one. The big innovation here
is jj does not require you to resolve merge conflicts in a timely
manner; it simply records the fact that there are conflicts in the
file and you go about your ways. You don't ever have to abort like
`git rebase --abort` or `git merge --abort`.
y1n0 wrote 1 day ago:
Yes, that's true, merging. Which is what made branching a
reasonable thing to do.
throawayonthe wrote 1 day ago:
tbh i never actually learned git, but peope working on the same repos
with git seem to be ahme ones struggling with named branches... i
just do jj rebase and it just works idk
stouset wrote 1 day ago:
Iâll be honest, as a long-time jj user, I actually havenât the
foggiest what youâre talking about with branches being laborious to
keep up to date. Can you elaborate?
y1n0 wrote 1 day ago:
I make a commit and the branch doesn't follow it. Bookmark,
whatever. That is never a behavior I would want. What purpose
does it serve?
stouset wrote 1 day ago:
Of all the things I was imagining it might be, this was down at
the bottom.
Personally Iâm a huge fan of this approach. If you arenât,
itâs literally just a one-liner (that is trivially made into an
alias) to advance a branch name to the most recent revision. And
now thereâs a feature to do auto-advancing if you want it.
Why is it this way? Because jj is designed around revisions being
constantly mutated.
In git, when I make a commit, I am typically signaling that that
a chunk of work is complete. Not always, but usually. In most jj
workflows, revisions are mutated constantly during development. A
revision being made on the tip of a branch is rarely a signal
that that unit of work is finished. Itâs even incredibly common
to have multiple revisions in a row that are works in progress.
Hell, the article weâre all commenting on discusses just such a
workflow. If I make five revisions on top of some branch, there
is no reason to assume that any of them are ready to be shared,
much less all of them.
Because of that difference, it makes sense to have an explicit
act to move a branch name forward.
paradox460 wrote 1 day ago:
They added auto advance bookmarks a while ago. You configure
which revset bookmarks you want to advance or not, and then it
just keeps them at the "head" of a branch
cpeterso wrote 1 day ago:
Having to list all the bookmarks you would list to auto-advance
in your jj config.toml is a hassle and easy to forget.
em-bee wrote 1 day ago:
ideally this should be done automatically when you create the
bookmark, maybe with a commandline option: jj bookmark create
-a/--auto-advance ...
LoganDark wrote 1 day ago:
I don't try to reimplement the git workflow on top of Jujutsu. I like
it because I can let go of a bunch of annoying noise that I needed in
Git. I like it because rebases don't have to be synchronous and
modal. I like it because I can easily edit history, rearrange the
commit graph, change commit descriptions, duplicate, and so much
more, and even remotely (without having to checkout first). There's
so much to love that I never could've even dreamed of under Git.
I like Jujutsu so much that I've been working on massive refactors to
my tooling in order to support it (example: [1] )
(HTM) [1]: https://github.com/LoganDark/get-shit-done
y1n0 wrote 1 day ago:
That's great that it has things you like. I don't do rebasing,
except on MRs where I've come to prefer squashing the branch being
committed.
But I don't rewrite history. It's history. While I can understand
people have reasons to do it, the reasons have never resonated with
me. I'd rather spend my time getting new work done and not
polishing work I've already done.
LoganDark wrote 1 day ago:
Using jj is easier when your whole team uses jj. When the rest of
your team uses Git, it's understandable that the pains of keeping
up with Git-isms (e.g. constantly updating branches) start to
become quite inconvenient. Though once you get used to jj they're
not much of an inconvenience at all, they are still extra steps
compared to raw Git. So if jj doesn't have any other inherent
value to you it makes sense not to make the jump.
To me, jj has inherent value because I do a lot of things raw Git
makes difficult or impossible. For example, [1] supports every
point release of Minecraft since 1.14, and mods like [2] derive
from it. I often rewrite the history of the template with
configuration improvements and then rebase the histories of each
mod on top of it.
This keeps my project setup consistent throughout versions, and
consistent between mods, and allows all my mods, across all
supported versions, to benefit trivially from all improvements I
make to my global template. This workflow is either not possible
with git or would require slow, ugly and fragile scripts.
(HTM) [1]: https://github.com/LoganDark/fabric-template
(HTM) [2]: https://github.com/LoganDark/debrand
RobotCaleb wrote 1 day ago:
I'm excited for your delayed comment. I'm sure going to take note
that you delayed it and come back later to read it because I'm
super interested in what it is that you've delayed. You know, you
can just write the comment instead of holding your place in line
jwiz wrote 1 day ago:
The delay is on HN side, when people reply too quickly.
RobotCaleb wrote 1 day ago:
Oooh, my apologies, then! I misunderstood
jolux wrote 1 day ago:
I assume you mean named branches (bookmarks in jj)? Because anonymous
branches in jj are trivial: you just `jj new ` and you have a new
branch.
Bookmarks arenât that bad either IMO, especially with the recent
addition of `jj bookmark advance`. Curious if you can say more about
the particular difficulties you found keeping them up to date?
y1n0 wrote 1 day ago:
I think I said named branches, but that is definitely what I mean.
I find it strange that people want to work on anonymous branches,
but to each their own. I don't so that has no appeal to me.
I often work on something and then switch away to something else.
it might be a week before i get back to it, and the name of the
branch is a clue as to what the heck I was doing.
Other people often need to check out a branch I'm working on to
help. How does anonymous branching help anyone except a solo
developer?
jolux wrote 1 day ago:
> I think I said named branches, but that is definitely what I
mean
I think I misread you, because you were talking about git vs svn
in a way that made it sound like jj was a step backward from git
as regards branching, and I got confused.
> I often work on something and then switch away to something
else. it might be a week before i get back to it, and the name of
the branch is a clue as to what the heck I was doing.
Right, but you can still name your branches with bookmarks,
youâre just not required to. Personally, I tend to use commit
descriptions more than bookmarks to keep track of what Iâm
working on, but this is a personal choice.
> Other people often need to check out a branch I'm working on to
help. How does anonymous branching help anyone except a solo
developer?
Itâs just nicer as a local workflow, to me at least? I can
create throwaway branches without having to come up with a name
for them. I end up creating many, many more branches than I did
in git as a result, which helps me keep my work better organized
and my changes more focused when I submit them for others to
review (which at least on GitHub, requires a bookmark of course).
This is ultimately psychological because obviously I could just
make up a name for the git branch, right? But it makes a big
difference for me!
justinpombrio wrote 1 day ago:
> it might be a week before i get back to it, and the name of the
branch is a clue as to what the heck I was doing.
Ah, this is what the description (what git would call the commit
message) is for. You can set the description even before you've
made any changes.
em-bee wrote 1 day ago:
that doesn't make sense because when i am working on a feature,
i create a branch, name the branch after the feature and then
each commit has a description of what is in that commit. the
feature has multiple commits, and while i carefully work out
what goes in each commit i don't squash them.
so with jj i could use a bookmark, ok, but having to manually
update that bookmark feels wrong.
igor47 wrote 1 day ago:
When I'm working in git, I always start work by creating a
new branch with a name. Sometimes the branch becomes
something different as I work and then I might rename it or
more often just keep a stale name around. But in git commit
descriptions come later.
In jj, it's the opposite. I start with a change, and I often
describe it right away. Branches (bookmarks) come at the end.
You could, in jj, tag a new empty change with a bookmark as
soon as you create it. You don't have to advance the bookmark
-- that the first change in a sequence of changes is tagged
with a bookmark is probably as much information as you need?
em-bee wrote 1 day ago:
that the first change in a sequence of changes is tagged
with a bookmark is probably as much information as you
need?
i was actually wondering about that. it might. i'll have to
see it in action...
nine_k wrote 1 day ago:
Imagine that you use jj, while everyone else who works on the repo
along with you uses regular git.
Is it easy?
Balinares wrote 1 day ago:
Yeah, trivial. Only difference my teammates see is that my
commits are much tidier and scoped in a way that's easy to review
and think about.
Macha wrote 1 day ago:
The biggest issue is my git knowledge is atrophying while my
coworkers still know me as âthe git wranglerâ (mostly because
most devs have never actually learned git, so any knowledge looks
10x more than theirs). So when a coworker comes to me with a
problem like their local main now has 2000 commits that theyâve
(or rather Claude Code hasâ¦) somehow accidentally re-signed
locally and then the 20 commits that actually contain their work,
Iâm thinking this would be easy to fix with jj rebase but the
best advice I can give them for git is to reset their local main
to origin/main, create a new branch and then cherry pick their 20
commits to their new branch. Since thatâs too time consuming
they just checked out the repo again and copied their working
copy over, which is the level of avoiding actually using git that
the git CLI routinely inspires.
Some later googling revealed `git rebase --onto origin/main
theirbranch main` was probably what they needed. Which Iâm sure
would have come to me quicker if I hadnât dropped the git cli
for jj 2+ years ago.
igor47 wrote 1 day ago:
Are you me? I do feel like I'm starting to forget git as a
result of my happy jj use. Thankfully some repos use git
submodules, which keeps me at least a little connected
tiltowait wrote 1 day ago:
I do this all the time at my job, without issue. I think it's
honestly easier than using plain git.
rtpg wrote 1 day ago:
yeah nobody "has to know", especially if everyone else is also
rebasing etc constantly.
stouset wrote 1 day ago:
Yes, that is the case for almost every repo Iâve ever used jj
for. It is a complete non-issue. There is virtually zero
friction.
jgtrosh wrote 1 day ago:
I believe this is the most common scenario, yes. If you're used
to actively pushing and pulling from the same branche as your
colleagues, you need to learn how to manipulate diverging changes
and conflicting bookmarks, but other than that all the jj magic
is limited to your local activity.
jolux wrote 1 day ago:
Yes, that describes me at both jobs Iâve had since learning jj.
Hence why I asked for specifics: Iâm genuinely curious what
other people struggle with, partially because Iâd like to help
them if I can, and partially because it gives me a better
understanding of common pitfalls which helps when teaching other
people.
LoganDark wrote 1 day ago:
I use jj all the time for pull requests, in fact I don't use
regular git at all anymore, and it's perfectly easy. Not only can
I easily keep all my pull requests properly synced to their base
branches, but I can easily and very quickly address review
comments, keeping the commit stack clean without having to
manually squash or amend or anything of that sort. Honestly it's
a lot easier and more efficient than git for me because of how
much naturally follows rather than requiring explicit imperative
fixups.
(DIR) <- back to front page