sgjennings

6 ms·

1. 1.▲
   by sgjennings 9mo ago

   I am quite comfortable with `git rebase -i` and I still prefer jj. Most importantly, I get in this situation less often in the first place. Because reodering and squashing commits can be done with an easy command[1], I tend to squash or reb
2. 2.▲
   by sgjennings 1y ago

   I’ll focus only on the syntax of the command. Why you might need it at all is important, of course, but it’s nuanced and specific to how some people work (I never need this command or anything like it, for example). > jj bookmark move Pr
3. 3.▲
   by sgjennings 1y ago

   You can work exactly this way using the “gitpatch” diff editor[1]. 1. Your working copy contains whatever mish-mash of changes you want. 2. When you’re ready to stage and commit these changes, run `jj commit --tool gitpatch` 3. The iterativ
4. 4.▲
   by sgjennings 1y ago

   I recently updated that FAQ so it preserves the original commit ID. It’s in the prerelease docs now and will move to “latest” with the release this week: https://jj-vcs.github.io/jj/prerelease/FAQ/#i-accidenta
5. 5.▲
   by sgjennings 1y ago

   I mostly solve this by putting a branch on the merge commit M, then the “real” change R is a child of that. The PR is targeted to merge R into M. As the parents of M are merged, I rebase the whole stack. When M has a single parent left, I a
6. 6.▲
   by sgjennings 2y ago

   The way I handle that with jj is to keep those changes in a commit “on the side” rather than making them “on top” of the working copy. The FAQ entry for this describes the process ( https://martinvonz.github.io/jj/latest
7. 7.▲
   by sgjennings 13y ago

   Authy's app works with Google Authenticator-compatible sites. Authy also has its own two-factor system, but you're not required to use it.