jj is a "unofficial" Google project that one has to sign a Google CLA to contribute to. I don't think it would be a good idea to trust/transition to a system like that from git.
It's not documented, but unfortunately neither of these re-signs the commits even if GPG signing is configured. They are based on `git replay`, and that doesn't sign either (at least yet).
I have always had this problem with hooks and new contributors: since hooks don't run by default if you just clone the repository, my open source projects get many PRs from new contributors that did not run the linting and commit hooks. I understand there's a security reason for this but what workflows have worked best for you to get everyone to run the hooks? And do you think the new config-based hooks can help new contributors?
While I understand the security concerns, too, wouldn't this be solved by including a `trust` command like in direnv and mise? (I.e. have the user review the hooks before executing them for the first time.)
Those new git history commands will save me an average of maybe a minute a day, but it's still definitely handy nonetheless! After 2 months, that's an hour back!
The git log -L change is nice to see as well. Anything that makes git more filterable gets my vote.
I do almost no direct git work myself these days. Using claude in Conductor. Working on a team. I'll tell claude what do do in git sometimes, but there doesn't seem to be much need to do it myself anymore, even with complicated rebases, reflogs, etc.
git history makes me think of git revise^1, which gives you a bunch of handy tools to changes your history, move commits around, remove some of them, cut them (which git history now does). I found it very handy in the past
Only a few days ago, I was just looking for some way to automatically check (and fail) if there are inactive hooks when I try to commit. I already use `advice.ignoredhook`, but it's easy to miss the warning if you commit through VSCode, and possibly through other IDEs.
With this, I can just write a simple script to perform that check, and add it to my global config
The per-repo config is in `.git/config`, so that can still not be checked into the repo itself, unless I'm missing something?
So not very useful at all...
I get the security implications, but there could be a checked in `$REPO/.githooks`, and a prompt asking to allow running those hooks , with an approval marker being stored inside `.git/`.
Though looks like `git history split` won't yet replace my typical workflow:
$ git rebase -i // with e on commit in question
$ git reset HEAD~
$ git add -p
As I can't edit the hunk.
`git history reword` will be handy once I wire up a script to pipe the log of recent commits through fzf for interactive selection (not sure if it's just me, but I prefer interactive selection over any other form of reference to a git hash).
And I bet I'll get some use out of `git rebase --trailer`.
git history is a genuinely welcome addition - rebase -i has always been a sledgehammer when sometimes you just need a scalpel, and it's nice to see git finally acknowledging that not every history edit needs to be a whole production
Is there any simple non-hacky way to "save" a snapshot of the working state, without clearing the working state like `stash` does?
I sometimes go in too far deep with a bunch of changes that should be committed separately but need to be worked on together, and I need to save it occasionally in case of data loss etc, and the only way I have/know is the good old "compress entire folder to a .zip"
22 comments
[ 1.9 ms ] story [ 61.2 ms ] threadhttps://www.jj-vcs.dev/latest/cli-reference/#jj-describe
https://www.jj-vcs.dev/latest/cli-reference/#jj-split
While I understand the security concerns, too, wouldn't this be solved by including a `trust` command like in direnv and mise? (I.e. have the user review the hooks before executing them for the first time.)
The git log -L change is nice to see as well. Anything that makes git more filterable gets my vote.
1: https://git-revise.readthedocs.io/en/latest/man.html
But what about local heads referred to only by a "soft" tag? Is their history rewritten, or is it left to refer to the old history?
Only a few days ago, I was just looking for some way to automatically check (and fail) if there are inactive hooks when I try to commit. I already use `advice.ignoredhook`, but it's easy to miss the warning if you commit through VSCode, and possibly through other IDEs.
With this, I can just write a simple script to perform that check, and add it to my global config
The per-repo config is in `.git/config`, so that can still not be checked into the repo itself, unless I'm missing something?
So not very useful at all...
I get the security implications, but there could be a checked in `$REPO/.githooks`, and a prompt asking to allow running those hooks , with an approval marker being stored inside `.git/`.
Though looks like `git history split` won't yet replace my typical workflow:
As I can't edit the hunk.`git history reword` will be handy once I wire up a script to pipe the log of recent commits through fzf for interactive selection (not sure if it's just me, but I prefer interactive selection over any other form of reference to a git hash).
And I bet I'll get some use out of `git rebase --trailer`.
I sometimes go in too far deep with a bunch of changes that should be committed separately but need to be worked on together, and I need to save it occasionally in case of data loss etc, and the only way I have/know is the good old "compress entire folder to a .zip"