I personally factorize as soon as there are two copies, but do not hesitate to inline the code and redo the abstraction when there is a 3rd use if it doesn’t fit. I find it much easier to inline and re-abstact a bad abstraction, than check if two copies are indeed identical.

The exception is business logic. Usually I want all of them to be dupplicates because there is a very high chance that it’s just accidental that part of the logic is similar. I take great care to have good primitives but the actual business logic that glue those primitives together is written as many time as needed.

First experience with #jj #jujitsu

I tried the equivalent of git add -p (jj squash -i).

• I realize that it’s closer to git add --interactive (which I find much more complicated and less productive)
• I wasn’t able to edit a hunk (like the e key in git add -p) which I use a lot to split debug statements from real work

I generated a conflict (as I expected)

• I found no way to show the original diff
• jj undo did not worked (I have not been able to undo the jj squash that introduced the conflict

Very not impressed so far. Fortunately it was a test repo.

I never realised it was that simple to do. Thanks a lot to answer the OP question. I had the same for longer than I wish to admit given how easy the answer was!