I’ve heard so much about jj recently, I might give it a try

[ellie@hachyderm.io]

I’ve heard so much about jj recently, I might give it a try

[endocrimes@toot.cat]

@ellie i gave it a quick look but it kinda breaks the bits i like about git, in exchange for marginally less typing, so i gave up p quickly

[rain@hachyderm.io]

@endocrimes @ellie what did you have in mind here? if it's the index/staging area then jj gives you all of the power in a different way

[endocrimes@toot.cat]

@rain @ellie Different isn't always _better_ though (and i didn't like mapping that workflow to jj)

[rain@hachyderm.io]

@endocrimes @ellie (fwiw I have a lot of data to show that the JJ approach is strongly preferred by most people — I worked on source control at FB for many years, where we did a lot of the things jj does. The data was stark, over 90% of engineers , most of which had only used git before, preferred it to the git workflow)

[endocrimes@toot.cat]

@rain @ellie there are things i (used to) prefer over git (former mercurial fan, begrudging perforce + svn + tfs user), but replacing a decade+ of muscle memory is rarely actively worth it (and I don't think jj is, for me, and the projects I work on)

[recursive@hachyderm.io]

@endocrimes @rain @ellie That's mostly my feeling, having casually looked at jj tutorials
I think https://github.com/martinvonz/jj/blob/main/docs/git-comparison.md finally explains a lot in a way that's meaningful to me

The "everything is already committed" approach makes me feel uneasy, I guess "jj split" mostly achieves my usual workflow, but I often have more changes than I'm ready to put in a particular commit as I sort out what I'm doing

[danderson@hachyderm.io]

@recursive @endocrimes @rain @ellie fwiw, I found the "commit everything" model jarring as a git power user, but after about a day of getting used to it, git now feels like a severe regression in workflow compared to what jj does with a combination of new, split, rebase, and edit. Not to mention experimentation is super fearless because 'jj undo' just works, always.

I'm sure it's not for everyone, but for me at least it's been amazingly good.

[danderson@hachyderm.io]

@recursive @endocrimes @rain @ellie also for your workflow of incrementally adding stuff to commits as you sort through pending changes, I think you want 'jj squash --to <change identifier> -i', which lets you pick out patch hunks interactively and adds them to the specified rev. That's a frequent flyer for me along with jj split when turning a pile of flow hacking into a clean patch series.

(edit: oops, --to not -r, -r specifies a revision to squash into its parent. 'jj undo' is your friend!)